REPUBLIQUE ISLAMIC DE MAURITANIE Modernisation des Infrastructures du System National de Paiement De La Banque Central De Mauritanie Spécification Technique et Fonctionnelle d’un Système de Transfert Automatisé multidevise (ATS) et d’un Dépositaire Central des Titres (CSD) Septembre 2017 TABLE DE MATIERES TABLEAU 1 : ABRÉVIATIONS ET DÉFINITIONS ................................................................................................................... 4 1. INTRODUCTION ET CONTEXTE ...................................................................................................................................... 5 1.1. ELEMENTS DEMOGRAPHIQUES ET MACRO-ECONOMIQUES ........................................................................................ 6 1.2 CONTEXTE ......................................................................................................................................................................... 8 2. SITUATION ACTUELLE .................................................................................................................................................10 2.1. STRUCTURE INSTITUTIONNELLE, PAYSAGE DU SYSTEME NATIONAL DE PAIEMENT EN MAURITANIE ................. 10 3. LE PRÉSENT APPEL D’OFFRE ...................................................................................................................................25 4. OBJET DU PRÉSENT APPEL D’OFFRE .............................................................................................................................27 4.1. COMPENSATION ET REGLEMENT .................................................................................................................................. 27 4.2. PARTICIPANTS.......................................................................................................................................................... 28 4.3. INTEGRATION ET LIENS............................................................................................................................................... 29 4.4. ENVIRONNEMENT TECHNIQUE .................................................................................................................................... 30 4.5. SERVICES ................................................................................................................................................................ 30 5. EXIGENCES GÉNÉRALES DES SYSTÈMES ATS ET CSD .....................................................................................................31 5.1. PRINCIPES ............................................................................................................................................................... 31 5.2. SPECIFICATIONS OPERATIONNELLES .............................................................................................................................. 32 5.3. INTEGRITE ............................................................................................................................................................... 32 5.4. TRANSACTION ET COMMANDES DE TRAITEMENT DE FICHIER .............................................................................................. 33 5.5. CONTROLES DE VALIDATION....................................................................................................................................... 33 5.6. INTEGRITE ET NON-REPUDIATION DES MESSAGES ............................................................................................................ 34 5.7. EXPLOITATION DU SYSTEME ....................................................................................................................................... 35 5.8. REQUETES ET REPORTING ................................................................................................................................... 36 5.9. SECURITE ............................................................................................................................................................. 36 5.10. EXIGENCES DE TRAITEMENT ........................................................................................................................................ 38 5.11. EXIGENCES OPERATIONNELLES ........................................................................................................................... 39 5.12. L'INFORMATION DE FACTURATION ..................................................................................................................... 40 6. EXIGENCES FONCTIONNELLES SPÉCIFIQUES DE L’ATS ..................................................................................................41 6.1. OBJECTIFS ............................................................................................................................................................... 41 6.2. COMPOSANTE ACH - FONCTIONNALITE DE COMPENSATION ............................................................................................. 42 6.3. COMPOSANTE RTGS ................................................................................................................................................ 45 6.4. GESTION DE LIQUIDITE ET INTERFAÇAGE AU SYSTEME COMPTABLE DE LA BCM ...................................................................... 48 6.5. EMISSION ET RECYCLAGE DE LA MONNAIE ..................................................................................................................... 50 6.6. GESTION DES TRANSACTIONS DU GOUVERNEMENT .......................................................................................................... 50 6.7. INTERFAÇAGES AVEC LES SYSTEMES DES BANQUES ........................................................................................................... 51 6.8. CONTROLE ET REPORTING .......................................................................................................................................... 52 6.9. GESTION ET SUIVI DU COMPTE..................................................................................................................................... 54 6.10. CONNEXIONS AUX SYSTEMES EXTERNES ......................................................................................................................... 55 6.11. VOLUMES ET PERFORMANCE ...................................................................................................................................... 56 7. EXIGENCES FONCTIONNELLES POUR LE DÉPOSITAIRE CENTRAL DES TITRES (DCT OU CSD) ..........................................57 7.1. OBJECTIFS ............................................................................................................................................................... 57 7.2. CARACTERISTIQUES FONCTIONNELLES .................................................................................................................................. 57 7.3. LA LIVRAISON CONTRE PAIEMENT (DELIVERY VERSUS PAYMENT, (DVP)) ............................................................ 58 7.4. GENERALITES ....................................................................................................................................................... 59 7.5. INFORMATIONS SUR LE PROPRIETAIRE BENEFICIAIRE ET LE DETENTEUR ................................................................................. 61 7.6. MODULE D’ADJUDICATION/ENCHERES SUR LE MARCHE PRIMAIRE ...................................................................................... 62 7.7. CONNEXIONS A LA COMPOSANTE RTGS DU SYSTEME ATS ................................................................................................ 64 8. EXIGENCES FONCTIONNELLES ET TECHNIQUE DU RÉSEAUX CENTRAL / INTERBANCAIRE (BCM) ..................................65 8.1. LES EQUIPEMENTS ...................................................................................................................................................... 65 8.2. LE DEPLOIEMENT ........................................................................................................................................................ 66 8.3. SPECIFICATIONS TECHNIQUES .................................................................................................................................... 66 8.3.2. SCHÉMA ARCHITECTURE CIBLE .................................................................................................................68 8.4. BESOINS DETAILLES .......................................................................................................................................................... 69 8.5. AU NIVEAU DE LA BCM..................................................................................................................................................... 70 8.6. L’ADMINISTRATION ET LA SUPERVISION ................................................................................................................................ 70 9. IMPLÉMENTATION ET SUPPORT ..................................................................................................................................74 9.1. NIVEAU DE CONSULTANCE METIER............................................................................................................................. 74 9.2. PLAN DE GESTION DU PROJET ..................................................................................................................................... 74 9.3. LE PERSONNEL DU SOUMISSIONNAIRE RETENU ......................................................................................................... 75 9.4. GESTION DE PROJET .................................................................................................................................................... 76 9.5. RECEPTION DES SYSTEMES ................................................................................................................................................. 77 9.6. PARAMETRAGE ET DEPLOIEMENT ........................................................................................................................................ 79 9.7. TRANSFERT DE CONNAISSANCE ET FORMATION....................................................................................................................... 79 9.8. DOCUMENTATIONS .......................................................................................................................................................... 80 9.9. GARANTIE ...................................................................................................................................................................... 80 9.10. SUPPORT CONTINU ........................................................................................................................................................ 80 9.11. LA MAINTENANCE DES MATERIELS, PROGICIELS ET LOGICIELS ................................................................................................... 82 9.12. CALENDRIER.................................................................................................................................................................. 84 10. RÈGLES DE PRÉSENTATION DES OFFRES TECHNIQUES ...............................................................................................85 10.1. DESCRIPTION DES TECHNOLOGIES DE L’INFORMATION, DOCUMENTS ET AUTRES PRODUITS ET SERVICES.......................................... 85 10.2. COMMENTAIRE POINT PAR POINT SUR LES SPECIFICATIONS TECHNIQUES ................................................................................... 85 10.3. PLAN DE PROJET PRELIMINAIRE ......................................................................................................................................... 85 10.4. CONFIRMATION DE RESPONSABILITE POUR L’INTEGRATION ET L’INTEROPERABILITE DES TECHNOLOGIES DE L’INFORMATION................. 86 TABLEAU 1 : ABREVIATIONS ET DEFINITIONS ACH Chambre de compensation automatise - Automated Clearing House. ATM / DAB / Automated Teller Machine / Distributeur Automatique de GAB Billets de banque / Guichet Automatique de Banque ATS Système de transfert automatise - Automated Transfer System. APBM Association professionnelle des banques mauritaniennes BBCM Banque Centrale de Mauritanie BCM Banque Centrale de la Mauritanie. BRI Banque des Règlements Internationaux. BT Bon du Trésor CNP Conseil National des Paiements CBB Central Bank Bill. CBS Système Bancaire - Core Banking System. CPSS Comité sur les systèmes de paiement et de règlement, CSD Central Securities Depository. DAO Dossier d’appel d’offres DBMS Database Management System. DCT Depositaire Central de titres DSP Direction des Systèmes de Paiement DVP Règlement livraison (Delivery versus Payment) EMF Etablissement de micro finance EFTPOS Electronic Funds Transfer at Point of Sale. FIP Fichier des Incidents de Paiement GIMTEL Groupement Interbancaire Mauritanien de Transaction Electroniques GL General Ledger. GUI Graphical User Interface. ILF Intraday Liquidity Facility ICT Information and Communications Technology. IMF Infrastructure de marche financier IT services du département informatique IOSCO International Organisation of Securities Commissions. ISP Internet Service Provider. Kbps Kilobyte par seconde LAN Local Area Network. MAN Metropolitan Area Network MRO Ouguiya mauritanienne (MRO) Mbps Megabyte par seconde NBFI Non-Bank Financial Institution. RIM Republique Islamique de Mauritanie SLA Service Level Agreement. SNP Système National de Paiement. STP Straight-Through Processing. RTGS Règlement brut en temps réel UM Ouguiya WAN Wide Area Network 1. INTRODUCTION ET CONTEXTE 1.1. ELEMENTS DEMOGRAPHIQUES ET MACRO-ECONOMIQUES 1.1.1. Facteurs environnementaux La Mauritanie est un pays du nord-ouest de l’Afrique, limitrophe de l’Algérie et du Sahara occidental au nord, du Mali à l’est, et du Sénégal au sud, avec lequel il partage le fleuve Sénégal. Il est bordé à l’ouest par l’océan Atlantique, le long d’une côte de plus de 700 kilomètres de long. Sa richesse repose en grande partie sur ses ressources minières (fer, cuivre et or notamment), exploitées principalement au nord du pays ; les cultures, concentrées au sud au bord du fleuve Sénégal ; la pêche sur la côte atlantique. Du pétrole a été découvert au large des côtes, et l’exploitation a commencé en 2006 La démographie Mauritanienne affiche un dynamisme particulier attesté par l’augmentation quantitative du nombre de la population totale suivant un taux de croissance moyenne de l’ordre de 3%. La population continue de croître à un rythme élevé, environ +2,32 % par an actuellement (2016). L’argument démographique offre des possibilités à la Mauritanie en termes de développement du système national de paiement. Il ressort de ces informations démographiques plusieurs facteurs positifs pour favoriser le développement du système national de paiement : - La croissance de la population totale résidente laisse présager un besoin important de transactions de paiement de détails dans les années à venir ; - La moyenne de salariés qui peuvent être routés vers le système bancaire afin d’améliorer le taux de bancarisation. Ils peuvent également adopter des instruments de paiement nouveaux et modernes tels que la carte bancaire et le mobile Banking; 1.1.2. Stratégie de la BCM La nouvelle orientation stratégique mise en place par le Gouvernement de la Banque Centrale accorde une importance majeure au projet de modernisation du système national de paiement (SNP) en Mauritanie. En effet, la forte croissance du secteur bancaire (le nombre de banques commerciales a doublé au cours des 10 dernières années) et l’augmentation des volumes de transactions qui s’en est suivie ainsi que l’émergence de nouveaux établissements financiers non bancaires intervenant dans les domaines du paiement mobile et du transfert de fonds posent des défis majeurs à la Banque Centrale en tant que régulateur du système financier qui doit entreprendre les actions suivantes dans les meilleurs délais: ➢ Révision du cadre juridique et réglementaire, notamment pour l’intégration des nouveaux établissements de paiement non bancaires dans le système financier et la prise en charge des nouveaux moyens de paiement électroniques, ➢ Mise en place d’un mécanisme de surveillance adéquat, ➢ Mise en place d’un système ATS (RTGS et ACH) totalement automatisé utilisant les dernières technologies et répondant aux normes internationales en vigueur, ➢ Développement des paiements électroniques �e-commerce, mobile-payement, etc.) particulièrement aux populations non bancarisées (le taux de bancarisation ne dépassant pas 15% en Mauritanie). De plus, la modernisation du système national de paiement permettra d’atteindre les objectifs suivants : ➢ Réduire les paiements en espèces et, par conséquent, réduire les frais fiduciaires, en favorisant l’utilisation de moyens de paiement scripturaux et électroniques, ➢ Améliorer l’efficacité et la sécurité des systèmes de paiement en réduisant les délais et coûts de traitement, ➢ Faciliter l’accès des populations défavorisées aux services financiers ainsi que les échanges commerciaux entre les opérateurs économiques, ➢ Renforcer l’efficacité et la sécurité des instruments de la politique monétaire basées sur les échanges interbancaires. 1.1.3 Facteurs Juridiques A l’initiative de la Banque Centrale de la Mauritanie, un projet de loi dédié au système national de paiement est sur le point d’être promulgué. Ce projet de loi aborde les innovations ci-après : - Base légale pour les nouveaux instruments tels que le virement, la carte bancaire et le prélèvement ; - Pouvoir règlementaire reconnu à la BCM en vue d’assurer la Mission de surveillance des systèmes et des instruments de paiement ; - Reconnaissance juridique de la preuve électronique, du traitement électronique des paiements et des accords de compensation multilatérale ; - Obligation faite aux participants de constituer les garanties financières nécessaires à l’exécution de leurs obligations financières ; - Réalisation des garanties financières constituées par les participants sans mise en demeure et sans intervention d’un juge; - Irrévocabilité de la garantie ; - Transfert momentané de propriété de la garantie (pension livrée); - Dématérialisation des instruments de paiement ; - Dérogation à la règle de zéro heure ; - Dépénalisation partielle de l’émission de chèque sans provision et des autres effets tirés sans droit, - Insaisissabilité de la garantie par la justice sauf par l’agent de règlement ou par l’opérateur du système de paiement; - Insaisissabilité des comptes de règlement logés auprès des agents de règlement et le cantonnement du montant de la créance par l’agent de règlement ou par l’opérateur du système de paiement; - Promotion des instruments de paiement à travers, notamment le droit à toute personne possédant un revenu régulier, le droit au service bancaire minium, obligations d’utilisation de la monnaie scripturale, etc. 1.1.4. Programme De Modernisation du système National de Paiement La Banque Centrale du Mauritanie (BCM), est chargée de définir et de mettre en œuvre la politique monétaire du pays. Elle est indépendante dans la réalisation de cet objectif. Dans le cadre du Système National de Paiement, la loi précitée stipule que la Banque Centrale a pour mission de promouvoir le bon fonctionnement des systèmes de compensation et de paiement. Elle accomplit également d’autres missions de banque centrale, notamment : • Emettre des billets et pièces de monnaie ayant cours légal sur le territoire national ; • Détenir et gérer les réserves officielles de la République ; • Edicter les normes et règlements concernant les opérations sur les devises étrangères ; • Participer à la négociation de tout accord international comportant des modalités de paiement et en assure l’exécution ; • Elaborer la réglementation et contrôler les établissements de crédit, les institutions de micro- finance et les autres intermédiaires ; • Superviser tous les établissements de crédits. Outre le siège, le réseau d’exploitation de la Banque Centrale compte 3 agences autonomes, les agences répondent essentiellement au besoin des opérations financières de l’Etat. La Banque Centrale peut également remplir les fonctions de caissier des entités administratives décentralisées et des organismes publics en application des conventions spéciales conclues entre elle, d’une part, les entités et organismes intéressés, d’autre part. La Banque Centrale tient en ses livres le compte général du Trésor Public ainsi que celui des autres administrations publiques. Dans le cadre de l’exécution des dépenses de l’Etat, la Banque Centrale intervient dans la chaîne de la dépense qui est un circuit informatisé pour l’exécution des dépenses publiques ordonnancées par le Trésor Public. La domiciliation est utilisée également dans le paiement de salaires des fonctionnaires et de soldes des militaires qui s’effectue actuellement auprès des banques commerciales, sur base des listings de l’Administration Publique. A l’intérieur du pays, l’ordonnancement s’effectue encore sur support papier. 1.2 CONTEXTE La Banque Centrale de Mauritanie (BCM) a adopté une approche stratégique pour la réforme des systèmes de paiement en Mauritanie, dans le but de mettre en place un Système National de Paiement sûr et efficace qui contribue à la stabilité financière et à la croissance économique du pays. De ce fait, elle a l'intention d'exercer efficacement les fonctions d'exploitation des systèmes de paiement, ainsi que celles de surveillance, conformément aux missions spécifiques qui lui sont confiées. Le Système National de Paiement (SNP) est défini en termes de systèmes, de mécanismes, d'institutions, d'accords, de procédures, de règles et de lois qui entrent en jeu dès qu'un utilisateur final, en utilisant un instrument de paiement, émet une instruction de payer une autre personne ou une entreprise, jusqu'au règlement interbancaire final de la transaction dans les livres de la banque du règlement. Le SNP permet donc aux parties prenantes d'échanger de la valeur pour mener leurs affaires efficacement. Pour faciliter ces processus, la BCM envisage de mettre en œuvre un Système de Transfert Automatisé (ATS) et un système Dépositaire Central de Titres (CSD). Considérant l'importance des systèmes de paiement et de règlement pour assurer le bon fonctionnement de l'économie, une des missions statutaires de la BCM est de promouvoir les systèmes de paiement et de règlement de titres fiables et efficaces. En même temps, les systèmes de paiement sont par nature dynamiques et évoluent rapidement, et sont confrontés à des défis à l'échelle nationale et internationale. En outre, les systèmes de paiement et de règlement ont une importance stratégique pour les fonctions de la Banque Centrale en matière de sécurité et de stabilité financière. Ainsi, la dotation en effectif suffisant et qualifié pour mettre en œuvre les nouvelles missions devrait être abordée de façon proactive, au-delà de la mise en œuvre du projet. Les compétences développées lors de l'implémentation du système peuvent naturellement passer à des fonctions permanentes lorsque le système sera en production. Ces fonctions sont les suivantes : 1. la mise en place du Département des Systèmes de Paiement (DSP). 2. la restructuration du département des opérations bancaires et marchés. En effet, la fonction opérationnelle du CSD sera affectée aux agents de ce département. 3. la mise en œuvre de l'ATS / CSD nécessitera également l’implication des services du département informatique (IT) pour le support des plateformes d'application, y compris le service d'assistance technique et d'administration technique des réseaux. Bien que les fonctions d'assistance applicative soient intégrées dans les fonctions actuelles du service informatique, il est nécessaire qu'un personnel professionnel assure un support réseau à temps plein. L'équipe chargée de l'implémentation du projet assumera son rôle de manière intégrale, la responsabilité principale des unités et le support de l'équipe IT seront nécessaires pour mettre en place le système avant qu’il ne soit mis en service. 2. SITUATION ACTUELLE 2.1. Structure Institutionnelle, Paysage du Système National De Paiement en Mauritanie Le secteur bancaire en Mauritanie est composé de la Banque Centrale de Mauritanie (BCM) et de dix- huit (18) banques commerciales et de leurs Succursales. Il est prévu que le nombre de banques commerciales augmente dans un proche avenir. Les Sièges des banques commerciales sont reliés à la BCM via le réseau privé de la GIMTEL (Groupement Interbancaire Monétique). Il s’agit d’un anneau en fibres optiques reliant l’ensemble des sièges sociaux des membres et la banque centrale. Ce réseau permet le transport de toutes les informations échangées entre le Réseaux Gimtel et ses membres d’une part et entre le réseau et les points d’accès au réseau monétique national (Banque, DAB/GAB et TPE)) et aux réseaux internationaux (Visa, MasterCard) dans le cadre de l’activité monétique. Toutes les banques (sauf une) ont mis en place un système bancaire de base moderne. La plupart d'entre elles (banques) externalisent leurs services Swift. La BCM est située Avenue de l’indépendance Nouakchott Mauritanie. Les bâtiments sont reliés par une connexion (LAN). La BCM dispose d'une connexion Internet de 8 Mbps et d'une connexion VPN avec de 2,0 Mbps. La BCM utilise le système bancaire de base pour la gestion des opérations et le grand livre général, ainsi que pour la comptabilité des soldes des banques commerciales dans leurs livres. Le système bancaire de base comprend une base de données centralisée et aucun site de redondance. Tableau 2 -Données sur les banques participantes en Mauritanie Item Participant Type de Core Banking utilisé (précisé) No. Agence No. Nom Banque Bank Version SWIFT utilisée Banque des NA 1. Financements Islamiques (Non NA NA NA (BFI) disponible) Banque Qatar National Bank Misys 2. 1 avec Swift Alliance Mauritanie(QNBM) Equation succursales Path Banque Islamique de Banque à 3. 4 Solution Mauritanie (BIM) succursales Imal 12.4 Sopra Nouvelle Banque de Banque à 4. 11 Banking Swift Lite 2 Mauritanie(NBM) succursales Sopra V10.1 Banque Muamelat As Banque à IMAL Path 5. 16 Swift Lite 2 Sahiha(BMS) succursales Solutions Banque Populaire de 6. NA NA NA NA Mauritanie (BPM) Item Participant Type de Core Banking utilisé (précisé) No. Agence No. Nom Banque Bank Version SWIFT utilisée Attijari Bank Mauritanie Banque à 7. (ABM) succursales Société Générale Banque à Sopra Banking Sopra V10Swift 8. 13 Mauritanie (SGM) succursales Alliance Entry Global Chinguitty Bank Banque à Swift Alliance 9. 4 Banking (CHINGUITTY Bank) succursales Entry Orion V2.1 Sopra Banque à Swift Alliance 10. OraBank Mauritanie 9 Amplitude V succursales Access 10.1.50 Capital Banque à 11. Banque El Amana (BEA) 8 Banking ND succursales Orion Banque Al Wava Sopra Banque à 12. Mauritanienne Islamique 10 Banking Swift Access succursales (BAMIS) Sopra V9.1 Sopra Générale de Banque de Banque à 13. 2 Banking Swift FIN Mauritanie (GBM) succursales Sopra V9 Banque pour le Orion Banque à 14. Commerce et l'Industrie 16 Finance Alliance Entry succursales (BCI) CBS V2.3 Banque Mauritanienne Sopra pour le Commerce Swift Alliance Banque à Banking 15. International (BMCI) 39 Via Bureau (AEG succursales Amplitude Liban) V :10 Banque Mauritanienne Banques à 16. pour l’Investissement (BMI) 2 NA NA succursales Banque Nationale Banques à Temenos 17. de Mauritanie (BNM) 29 NA succursales T24 Caisse d'Epargne et de Orion 18. Développement (CDD) NA Finance Actuellement, toutes les banques sont dotées d’un système bancaire (Core Banking System) et sont connectées à SWIFT (Alliance Access ou entry via un service bureau ou une connexion directe). Elles disposent également des moyens de télécommunication (VSAT et/ou VPN/Gimtel) qui leurs permettent de relier leurs sièges à l’ensemble des agences implantées sur toute l’étendue du territoire nationale et a la Banque Central. 2.1.1. Systèmes de paiements de gros montants et de masse La BCM utilise le système bancaire de base pour la gestion des opérations et le grand livre général, ainsi que pour la comptabilité des soldes des banques commerciales dans leurs livres. Le système bancaire de base comprend une base de données centralisée et aucun site de redondance. La BCM a aussi implémenté un système de règlement interbancaire développé en interne qui fournit un règlement semi manuel pour la compensation des transactions interbancaires. L’échange physique des chèques se fait encore tous les jours avec la participation de toutes les banques commerciales à la chambre de compensation de la BCM. Actuellement, tous les paiements de gros montants et/ou urgents sont traités manuellement à travers l’échange d’instruments papier et sont réglés par écriture manuelle sur les comptes de règlement (comptes courants) des banques commerciales logés à la BCM. La compensation de Nouakchott est semi-automatisée dans la mesure où les banques saisissent électroniquement et visualisent les valeurs qui vont être présentées à la compensation de la séance en cours mais l'échange physique des chèques est toujours obligatoire. La date de valeur pour le crédit des chèques est de J+2 après la présentation en compensation. A Nouadhibou, la compensation est semi manuel. Bien que l’instruction de la BCM relative à la normalisation du chèque ait été publiée, cette normalisation n’est que très partiellement mise en œuvre. Le bon de virement, quant à lui, n’est même pas règlementé par le Code du Commerce. Par ailleurs, il n’y a pas de direction ou département en charge spécifiquement des systèmes et moyens de paiement au sein de la banque centrale. Le nombre et le montant moyen quotidien des valeurs compensées (chèques, traites et bons de virement) sont très limités (345 valeurs, pour un montant moyen quotidien de UM 2.4 milliards, soit USD 7.7 millions). Tableau 3.1 : valeurs traitées en compensation (*montant en million UM) Source : BCM, juin 2017 Valeurs traitées en règlements intérieurs (montant en millions MRO) 2014 2015 2016 Valeur Nombre Montant Nombre Montant Nombre Montant Chèque 101,601 676,542.3422 103,614 711,324.3739 108,776 717,487.2667 Traite 760 39,759.1173 725 39,065.3874 719 49,238.1682 Bon de 23,571 166,686.2521 21,420 161,074.7510 19,095 158,944.1930 virement Tableau 3.2 : Valeurs Traitées en hors compense Valeurs traitées en règlements intérieurs (montant en millions MRO) 2014 2015 2016 Valeur Nombre Montant Nombre Montant Nombre Montant Chèque/BV 5,884 539,690.1319 7,794 427,808.4857 6,347 438,318.6779 Le flux d’information en provenance, des établissements publics d’une part et du système bancaire d’autre part, est traité à deux niveaux : ▪ Les règlements sur les comptes courants ▪ La compensation 2.1.2. Gestion actuelle des virements de la BCM La BCM est dotée d’une application informatique (développée en interne) qui permet, d'une part, le traitement des virements interbancaires, et d'autre part les règlements des dépenses publiques ordonnées par le Trésor (essentiellement les salaires des fonctionnaires et les règlements de fournisseurs) et les Etablissements Publics et Administratifs (EPA). Concernant les virements interbancaires, les banques introduisent, à travers une interface web les ordres de virements et envoient, en parallèle, les documents physiques. L’interface offre également la possibilité aux banques de consulter la situation journalière de leurs ordres de virements. Quant aux règlements des dépenses publiques, les services du Trésor saisissent également les bordereaux de dépenses à travers une interface web. Les services des règlements de la BCM récupèrent ces bordereaux qui sont traités automatiquement. L’envoi des supports physiques relatifs à ces règlements est toujours requis en l’absence de la dématérialisation des documents. Les ordres de paiement émis par les EPA sont envoyés en format papier et sont saisis directement sur l’application au niveau de la BCM. Enfin, toutes les opérations règlements sont automatiquement comptabilisées. 2.1.3. Gestion de la chambre de compensation La chambre de compensation de Nouakchott est organisée par la Banque Centrale et régie par la Convention de Place de la Chambre de Compensation et son règlement annexe. La BCM est dotée d’une application informatique (développée en interne) de gestion semi-automatique de la chambre de compensation. Actuellement, l’échange des valeurs (chèques, bons de virements et traites) entre les banques commerciales se fait lors de la séance quotidienne de compensation gérée par la BCM. Au cours de chacune de ces séances, chaque banque reçoit des autres banques, membres de la chambre, les chèques tirés sur ses comptes et faisant l’objet d’une présentation à la compensation, ainsi que les chèques qui ont fait l’objet d’un rejet au cours de la période autorisée à cet effet (2 jours pour le moment). A l’ouverture de la séance la position nette de chaque banque est introduite et affichée par le système. Ouverture de la séance BCM DROB Traitement des valeurs ➢Saisie ➢Modification ➢ Annulation ➢Rejet Représentants des banques Contrôle ➢Impression des états ➢Contrôle des valeurs ➢ Pointage ➢Constatation rejets Balance tirée et signée Génération des pièces BCM DROB Clôture de la séance Les flux échangés au niveau de ce système sont de deux sortes : Flux entrant : les banques (y compris la BCM) déclarent sur une interface web l’ensemble des chèques et des ordres de virement déposés par leurs clients. Flux sortant : A l’issue du dénouement de la compensation, les soldes nets multilatéraux sont calculés par le système et sont automatiquement comptabilisés. L’application offre également la possibilité aux banques de consulter leurs situations de compensation par rapport à une séance. Actuellement les données de la compensation d’une banque peuvent être intégrées automatiquement au système de compensation BCM grâce au module d’import. Les valeurs présentées par le Trésor, sur les banques, sont importées automatiquement à travers l’interface Trésor. L’application de compensation permet, également, de gérer les oppositions de chèque et les rejets. Les positions nette de la compensation monétiques sont envoyées par le GIMTEL sous forme de bordereau physique et sont comptabilisées directement par la BCM. Figure : 2 Schéma de fonctionnement du système (Règlements et compensation) La Compensation à Nouadhibou La chambre de compensation de Nouadhibou est organisée par la Banque Centrale (Agence Régionale de Nouadhibou) et régie par la Convention de Place de la Chambre de Compensation. L’Agence Régionale de Nouadhibou est dotée d’une application informatique (développée en interne. Il s’agit d’une installation de l’application utilisée déjà à Nouakchott et d’une ’adaptation à l’agence de Nouadhibou. Actuellement la situation de la compensation de Nouadhibou peut être visualisée à partir du siège à Nouakchott, grâce à l’adaptation de l’application de compensation développée au siège. 2.1.4. Paiements de détails Les instruments actuellement utilisés pour les paiements de détails sont les chèques, les virements, les effets de commerce, la carte bancaire. Les principes structurants de la conception du système de compensation cible sont les suivants : • L’automatisation et la dématérialisation des échanges. Cela implique d’accorder une attention particulière à la qualité des liaisons de télécommunications intra et interbancaires ; • La définition des délais de règlement interbancaires qui tiennent compte des délais de rejet et qui assurent de cette façon l’irrévocabilité des règlements ; • Le principe de la centralisation des comptes pour le règlement de la compensation à partir d’un seul compte de règlement par devise pour chaque banque gérée dans le système de règlement ; • Autoprotection du règlement de la compensation par des mécanismes pouvant faire intervenir la BCM, ou par la mise en place d'un fonds de garantie ou de mécanismes d'avances intra journalières 2.1.5. Paiements de Gros Montant Il s’agit des paiements interbancaires de gros montants (marché monétaire, opérations de politique budgétaire ou monétaire etc…) ou de paiements dont le règlement à temps est critique pour le fonctionnement du secteur bancaire, comme le règlement des soldes de compensation. Les principes structurants d’un tel système sont les suivants : • Mise en place d’un système de règlement brut (RTGS) multidevises qui gère un compte unique par devise par banque où sont regroupées toutes ses liquidités dans cette devise ; • Au démarrage du système, les avoirs existant sur les comptes locaux des banques dans les agences de la BCM seront rapatriés sur leur compte unique de règlement géré par la BCM en MRO (Ouguiya Mauritanienne) et ces comptes locaux seront clôturés ; • Ce système fonctionne en temps réel, ce qui permet aux banques de connaître à tout moment la position de leurs comptes de règlement ; • La BCM assure le rôle de gestionnaire opérationnel et technique et de surveillance du RTGS ; • Ce système est destiné au traitement des opérations de politique monétaire et du marché monétaire, des opérations de paiement de gros montant (y compris les retraits et versements fiduciaires en MRO) et des opérations qui ont un caractère d’urgence. • Les modalités de participation au nouveau système seront précisées lors de l’élaboration de la Convention d’adhésion au système ; • Pour le réseau, un schéma de fonctionnement en V ou en Y sera élaboré pour la connexion au réseau Swift. 2.1.6. Instruments de paiement a. Chèques Les chèques peuvent être des chèques ordinaires barrés, des chèques non barrés, des chèques de banque ou chèques certifiés. Le Chèque dans sa présentation actuelle a peu de succès, principalement pour les raisons suivantes : L’absence d'un cadre réglementaire adéquat pour la présentation sous forme électronique, la dématérialisation et la numérisation des chèques b. Espèces Du fait de la faible bancarisation de l’économie nationale et de la prédominance de l’économie informelle, l’essentiel des transactions dans les grandes agglomérations urbaines et dans les centres ruraux se dénoue en espèces, en Ouguiya Mauritanien. c. Cartes Bancaires Actuellement presque toutes les banques commerciales émettent des cartes et fournissent des services de paiement à cartes. Indépendamment de l'acceptation des cartes internationales (Mastercard et visa), il y a une interopérabilité entre les bornes de carte (ATMs et TPE) des banques à travers le Gimtel. d. Internet Banking Un certain nombre de banques offrent des opérations bancaires par Internet mais seulement pour des transactions privatives. e. Paiements Mobiles L'utilisation du téléphone mobile comme moyen d'accéder à certains services d'opérations bancaires et de paiement est à une première étape de développement et de mise en œuvre en Mauritanie, avec seulement un nombre limité d’opérateurs de téléphonie mobile. Il s’agit de: Mauritel avec MobiCash f. Normalisation des Chèques Pour automatiser et sécuriser le traitement des chèques, il est nécessaire de normaliser les vignettes papiers. En effet, en fonction des caractéristiques de fabrication des chéquiers, il conviendrait d'améliorer la qualité et la lisibilité des images produites, réduire les risques de fraude physique, optimiser l’enregistrement des données et faciliter les contrôles d’usage sur les chèques. Dans le cadre de la réforme du système de paiement, la Banque Centrale de Mauritanie doit va élaborer des textes visant à prendre en compte la protection du consommateur favorisé par l’avènement des systèmes de paiement envisagés, surtout le système de télé-compensation. 2.2 Marché des Titres 2.2.1. Le Marché des Titres en Mauritanie Actuellement le Marché des Titres en Mauritanie se trouve à l’état embryonnaire. Dans le passé, le gouvernement émettait les Titres publics pour financer son déficit de Trésor. Actuellement ce marché connait un certain déclin. Pour ce qui concerne les Titres privés, il n’existe pas encore un marché organisé de ces Titres. 2.2.2 Processus d’émission des titres publics Les modalités du fonctionnement du marché des titres d’Etat sont régies par la circulaire n° 003/GR/2007 de la BCM. Le document décrit les caractéristiques des titres d’État pouvant être émis, la procédure de leur émission, les types d’opération d’achat et de vente permis sur les titres sur le marché secondaire. Il contient également les procédures d’émission des bons BCM pouvant être émis dans le cadre de la mise en œuvre de la politique monétaire ainsi que les procédures d’émission des certificats de dépôt et des billets de trésorerie par les banques commerciales. Les BT représentent environ 4% de l’encours de la dette publique et sont principalement détenus par les entités publiques (environ 90% à fin juin 2017). Les autres investisseurs sont constitués des banques mauritaniennes. Les autres instruments de dette sont principalement composés des prêts du secteur officiel contractés à des conditions concessionnelles et dans des monnaies liées au dollar américain. L’encours de la dette publique de l’administration centrale est estimé à environ 72% du PIB à fin décembre 2016. Les titres sont émis par voie d’adjudication à prix multiples. Les adjudications sont semi -ouvertes : les investisseurs qui n’ont pas de compte de règlement auprès de la BCM doivent passer par une banque pour présenter leurs soumissions. Les deux types de BT pouvant être émis sont : les bons du Trésor à court terme (BTC) et les bons du Trésor annuels (BTA). Les BTC sont à intérêts précomptés et ont une échéance inférieure à un an. Les échéances pouvant être émises sont de 4 semaines, 13 semaines, 26 semaines et 50 semaines. Les BTA sont émis pour des échéances supérieures à un an et versent des intérêts périodiques. Jusqu’à présent les émissions ont principalement porté sur les BTC. Le calendrier est publié sur le site de la BCM. Il est assez détaillé et donne de l’information sur les quatre prochaines émissions (échéance et montant indicatif du BT à émettre). Les caractéristiques finales des BT sont indiquées dans le communiqué d’appel d’offres publié la veille de l’adjudication. Les adjudications de BT sont hebdomadaires et ont lieu chaque mardi à 14 heures. Quatre échéances sont offertes : 4, 13, 26 et 50 semaines. Le volume global à émettre est indiqué dans le communiqué d’appel d’offres. Les investisseurs font des propositions pour chaque échéance sur la base de leur intérêt. Le processus de dépouillement et d’allocation des offres est supervisé par le comité d’adjudication présidé par le DGTCP ou son représentant. Le comité peut décider d’allouer un montant de titres de plus de 30% du montant indiqué dans le communiqué d’appel d’offres. Au-delà de 30%, la décision du Ministre de l’Economie et des Finances est requise. Si le comité juge les taux désavantageux pour l’Etat, il peut limiter le montant d’émission à 70% du montant indiqué dans le communiqué d’appel d’offres. Les demandes de BT dont les taux sont les plus bas sont satisfaites en premier lieu, indépendamment de leur échéance, jusqu'à concurrence du volume global annoncé. Les soumissions sont présentées par tranche maximale de 200 millions d’Ouguiyas et le taux proposé par échéance différencié au moins de 2 points de base (0,02%). Les BT ne sont pas codifié. 2.3. Switch Monétique Interbancaire GIMTEL Conformément à sa vision et sa stratégie, la BCM (Banque Centrale de Mauritanie) requiert que toutes les installations du système de paiement du pays soient conformes aux standards ouverts, pour atteindre l'interopérabilité. Le but de l’implémentation du GIMTEL (Groupement Interbancaire de Monétique et des Transactions Electroniques) est de fournir un système de paiement monétique centralisé de manière à répondre aux besoins de l’économie et être conforme aux meilleures pratiques et standards internationaux. Le GIMTEL est un Groupement d’Intérêt Economique crée en Mai 2005, constitué sous l’égide de la BCM. Dix banques et Mauripost y adhèrent. Le GIMTEL a pour objectif de promouvoir le développement et l’utilisation de la carte de paiement en Mauritanie. A cette fin, le GIMTEL conduit les actions pour: • Permettre l’acceptation de cartes émises par les réseaux internationaux : Visa, MasterCard, American Express, Diner’s Club, JCB, … ; • Créer une interbancarité Mauritanienne pour le paiement et le retrait ; • Permettre l’émission en Mauritanie de cartes adossées à des produits des réseaux internationaux ; • Mettre en œuvre les infrastructures techniques nécessaires ; • Acquérir et mettre à disposition les équipements supportant l’activité monétique ; • Mobiliser les moyens humains, pour prendre en charge des fonctions déléguées par les banques. Les missions du GIMTEL se résument comme suit : • Développer de manière efficace des moyens modernes de paiement afin d’augmenter leur productivité interne, d’apporter des nouveaux services à la clientèle, et de promouvoir l’utilisation des moyens de paiement modernes ; • Mutualiser les moyens nécessaires pour le traitement des opérations monétiques, et ainsi éviter la multiplication des investissements, aussi bien humains que matériels; • Promouvoir et développer un système central de compensation électronique interbancaire ; • Développer un réseau d’échanges sécurisés de données informatiques relatives aux valeurs compensées entre les banques et le groupement et mettre en place un archivage électronique des valeurs compensées ; • Promouvoir l’acceptation des cartes en Mauritanie émises par les grands organismes internationaux : Visa, MasterCard, American-Express, Eurochèques, Diner’s Club, etc. ; • Mettre en œuvre l’ensemble des actions qui régissent le fonctionnement des systèmes monétiques dans ses diverses composantes : marketing, maîtrise des technologies, automatisation des procédures bancaires, rapidité des transactions, économie des flux financiers, etc. 2.3.1 Le cœur réseau Le cœur du réseau est réalisé sous forme d’un réseau en fibres optiques en boucle synchrone reliant tous les sièges (BCM, Banques Primaires, CDD, Mauripost ; trésor public et le GIMTEL) au nœud central (GIMTEL) situé dans les locaux de la BCM. Avec cette boucle empruntant des chemins d’un réseau privé sécurisé et fiable avec des swichs redondants dans chaque siège. Les sièges des membres du GIMTEL sont interconnectés par un câble à fibre optique monomode à travers des commutateurs Catalyst muni de l’option VPN. Le nœud principal est connecté sur un Catalyst de niveau 3 muni des options VPN, cryptage et firewall. Cette topologie est faite pour fournir une redondance dans le cas où l’un des tronçons de l’anneau est non opérationnel. 2.3.2 Sécurité La sécurisation de l’échange des données est assurée par la mise en place de: • VLAN au siège connectés sur l’anneau fibre optique (déjà un pas important de sécurisation des trames). chaque siège de l’anneau appartient à un VLAN. La sécurité est assurée par des listes de contrôle d’accès (ACL) sur tous les VLAN pour empêcher des flux de données non autorisées au sein des VLANs. • Le mécanisme de switchport Security au niveau des ports • L’utilisation de la solution de contrôle et d’authentification Secure ACS pour l’ensemble des composants (catalyst, routeur, etc) du réseau GIMTEL. • L’utilisation du Protocol SPF (spanning tree protocol) • L’utilisation de la notion VPN • Le paramétrage spécifique combiné entre les VLANs d’une part et des ports dédiés de l’autre part. • Plan d’adressage IP : un plan d’adressage est bien arrêté par le comité technique permettant d’élargir ce réseau au plus grand niveau (étendue) • Routage : le routage dynamique utilisé pour éviter le changement de la table de routage en cas de modification de la topologie réseau. Conformément à la norme PCI-DSS le cloisonnement réseaux est comme suit : 2.4 Environnement informatique et télécommunication 2.4.1 Système information de la BCM Le système d’information (SI) de la BCM est pour l’essentiel construit autour d’applications développées en interne notamment la comptabilité, la gestion des recettes etc. L’application de la comptabilité gère tout ce qui est comptabilité générale au niveau de la BCM. Des interfaces de saisie des pièces comptables sont générées pour chaque service. Le système est également interfacé avec les applications Swift. Le SI de la BCM interagit également avec des systèmes exogènes. Ces systèmes sont, les SI des banques commerciales à travers le portail d’échange de données et l’interface BCM-Banques pour tout ce qui est ordres de virement, celui du trésor public pour les ordres de transferts et les chèques trésor, le système de compensation ainsi que le système Swift. 2.4.2 L ’application de compensation Une application de compensation est opérationnelle sur le système d’informations de la BCM. La limitation majeure de cette application est que les effets sont saisis manuellement au niveau de chaque banque. Le dénouement se fait au niveau de la salle de compense de la BCM sur présentation des effets saisis. A la fin de la séance les pièces comptables sont automatiquement générées sur l’application de la comptabilité. Il est important de préciser que l’application actuelle de compensation ne fait aucune discrimination sur le montant (gros ou petit). Les utilisateurs des banques accèdent à l’application par user id/mot de passe. Aucune autre mesure de sécurité n’est mise en œuvre. 2.4.3 la connectivité Swift Le système d’information de la BCM, dispose également d’une infrastructure Swift composée de : - Alliance Access (version 7.1.30) : plate-forme d’accès aux services Swift, - Alliance Web Platform : client léger permettant de contourner le recours au client lourd, La connexion au réseau Swift se fait à travers une connexion service bureau(AEG) qui dispose de deux sites : l’un au Liban et l’autre en Chypre. Pour leur part, les Banques agréées se connectent indépendamment à Swift. La plupart de ces connexions se font par Internet (service bureau). 2.4.4 Infrastructures de télécommunication et des Datacenter 2.4.4.1 Infrastructures de télécommunication de la BCM En plus du siège principal, la BCM dispose de trois (3) agences à travers le pays : l’agence de Nouadhibou, l’agence de Zoueratt et l’agence de Rosso. Une liaison Fibre Optique de l’opérateur Mauritel assure l’interconnexion entre le siège de la BCM et son agence située à Nouadhibou. L’agence de Zoueratt est réliée au siège par une LS 256Kbs. L’agence de Rosso n’est pas interconnectée au siège central. Le trésor public est relié au siège à travers le réseau Gimtel. 2.4.4.2 Infrastructures de télécommunication entre la BCM et les banques commerciales. A ce jour, les banques commerciales accèdent au système d’information de la BCM à travers la boucle de GIMTEL. 2.4.5 Le réseau de données Le réseau LAN de la BCM est bâti autour d’un Switch HP 2424Mqui se charge du routage de tout le réseau. Le réseau n’est pas segmenté. Une dizaine locaux techniques dotés chacun en moyenne de 3 commutateurs de niveau 2d’interconnecter les postes de travail (sous Windows 10 essentiellement). La sécurité de niveau réseau est garantie par deux pare-feu matériel Cyberoam CR200iNG-XP. Toutefois la BCM a entrepris une refonte de son réseau informatique. A terme le réseau sera organisé autour de 2 switch cœur redondant.(Cisco Cat 6500), des commutateurs de distribution cisco 3750X et des switchs d’accès niveau 2 cisco 2960X 2.4.6 Centre d’hébergement La BCM dispose à ce jour de deux sites d’hébergement qui sont en train d’être mis aux normes. 2.4.7 Les Serveurs L’essentiel des serveurs de la BCM tournent sous Windows 2008 R2 et Windows 2012. Par ailleurs la BCM a une solide expérience avec le matériel IBM et HP. Il s’agit essentiellement des serveurs ci-après : 1. OS serveurs : Windows Server 2008 R2 ; 2. Marque : IBM et HP 3. Bases de Données Oracle 12c Entreprise Edition, Sql Server 2008R2 et Sql Server 2012 Entreprise Edition 4. Mail : Microsoft Exchange 2010 ; 5. Serveur Web : Apache et Glashfish 6. Antivirus : PandaAdaptative 360 7. Environnement de développement: Oracle Apex, J2EE, PHP; 8. Logiciel de gestion d’accès (lecteur de badges d’accès): Protecsys 2 suite; 9. Gestion du domaine : AD Windows 2008 R2 ; 10. Autorité de certification : bull ; 11. Terminal Server: Microsoft Terminal Server. 1. Liste des applications métiers LISTE DES APPLICATIONS DEPLOYEES SUR LE SI DE LA BCM Nombre N° Logiciel/Application Fonctionnalités Editeur d’utilisat eurs 1 Comptabilité Gestion de la comptabilité générale de la BCM BCM NA 2 Portail Des Banques Espace d’échange de données avec les Banques BCM NA BCM-Tresor Ordres de Transfert et Chèque Trésor ST2I/GTI/BC 3 NA M 4 Application change Salle des marchés BCM 120 Bloomberg Source d’informations financières et boursières Bloomberg 5 1 (salle des marchés) 6 Centrale de Risque Supervision bancaire BCM NA FX Trade Trading et Forex Thomson 7 2 Reuters compense Saisie des effets de compense à distance BCM BCM/ 8 Banques 9 Justif Application de suivi de l’utilisation des devises BCM NA 10 SmartMatch Application de Rapprochement comptable SmartTech NA BCM-BANQUES Interface de gestion des Bons de virements et BCM 11 NA des chèques 12 Statistiques Monétaires Application de suivi des statistiques monétaires BCM NA MidSys Application d’interfaçage entre le SI de la BCM AEG 13 NA et Swift 14 FinInform Application de reporting des transactions Swift AEG NA 2.4.8 ARCHITECTURE ACTUELLE L’architecture réseau interbancaire est organisée autour d’un anneau en fibre optique de Gimtel. Les banques y sont connectées derrières des firewalls StoneGate 1035-C1. Un cluster de firewall de même type sépare le réseau Gimtel du LAN de la BCM. Le LAN héberge l’ensemble des applications interbancaires et l’interface avec le trésor public : Portail d’échange, Application Compense, Interface Tresor-BCM. En plus de ces applications, il y’a les Serveurs qui héberge les applications Swifts (Alliance Access, Reporting etc.). Firewall StoneGate Serveur de Management WAN GIMTEL Commutateur DLINK Cluster de FireWall StoneGate IPS StoneSoft Serveur Proxy Firewall StoneGate Interface Tresor-BCM Application Compense Serveurs Swift Routeur Cisco860 Series Portail des banques Serveur de Base de données LIAISON FO SwiftNet Serveur Swift DR 3. LE PRESENT APPEL D’OFFRE La BCM, dans le cadre du projet de modernisation du système national de paiements (SNP) compte acquérir et mettre en œuvre une plateforme clefs en main prix-fixe de transfert automatisé (Automated Transfer System ATS) multidevise, qui sera l’élément fondamental de tout le SNP. L'ATS (RTGS, ACH) et le CSD se conformera à la meilleure pratique en vigueur et aux principes et recommandations internationales, en particulier aux principes de noyau de CPSS pour les systèmes de paiement d’importance systémique et (si applicable) aux recommandations de CPSS-IOSCO pour des systèmes de règlement de titres. L'ATS fournira les fonctionnalités pour la compensation et le règlement de tous les paiements électroniques interbancaires, de grande et petite valeur, dans un même progiciel intégré. Il aura deux fonctions principales : (i) Une fonction de règlement brut en temps réel (RTGS) pour des paiements critiques ou de grande valeur ; (ii) Une fonction de chambre de compensation automatisée (ACH), qui fournira des outils de compensation pour tous les paiements électroniques de détail comprenant les prélèvements automatiques (débits directs), des virements (crédits directs), des chèques, les billets à ordre, les lettres de change et des transferts de masse (par exemple pour des salaires et des allocations et avantages sociaux). Les deux éléments seront étroitement intégrés dans un seul système hybride (l'ATS) afin d'assurer la compensation et le règlement de tous les paiements électroniques interbancaires domestiques sur une base de même jour avec la finalité et l'irrévocabilité. L'ATS sera connecté aux noyaux des systèmes d’informations des banques commerciales, au switch monétique national et à tout autre système exogène, pour fournir un Straight-Through Processing (STP) complètement automatisé. Au sein de la BCM, il sera intégré à son système d’informations notamment le système de gestion comptable et financière. La plateforme doit être basée sur un progiciel pour le règlement brut en temps réel, qui va gérer le règlement des opérations suivantes : 1. Paiements de montants élevés ou prioritaires entre les participants au système ; 2. Retraits et versements d’espèces aux guichets de la BCM ; 2. Soldes nets multilatéraux du système de compensation ACH, composante de l'ATS ; 3. Solde du système net interbancaire découlant de la compensation des opérations monétiques ; 4. Transactions impliquant l'achat et la vente des titres (sur les marchés primaires et secondaires) selon les principes de Livraison contre Paiement (DvP) et de STP ; 5. Règlement des transactions des marchés de change et monétaires. La plateforme fournira un système simple et unifié pour le traitement de tous les types de paiement, indépendamment de leurs caractéristiques. Il fournira les fonctions qui, dans certains pays, ont été fournies par les différents systèmes logiciels (RTGS et ACH) qui ont dû être installés avec des interfaces pour réaliser ce que l'ATS réalisera dans un seul système intégré. En outre l'ATS supportera des interfaces à un certain nombre de systèmes exploités par les agences du Gouvernement, y compris le département de trésor du ministère des finances, de l'administration fiscale et du service des douanes. Dans le futur, la Banque s’attend à la connexion de ce système de base avec le système des marchés boursiers, de change et monétaire interbancaire. Ce DAO est donc publié pour la fourniture et l'implémentation sur une base clés en main, d'un ATS et d’un CSD.Des offres sont demandées aux compagnies qualifiées pour : 1. la fourniture d’un package de logiciel d'application d'ATS ; 2. la fourniture de tous les matériel, logiciel système, logiciel de gestion de base de données, logiciel personnalisé et composants de gestion de réseau nécessaires pour faire fonctionner l'ATS à deux centres de traitement (site de secours et site nominal); 3. l’Implémentation des liens automatisés entre l'ATS et une gamme d'autres systèmes d'information de la BCM et des organismes externes comprenant les banques commerciales et les entités gouvernementales ; 4. La gamme complète des services requis comprenant la gestion de projet et les spécifications fonctionnelles, techniques et opérationnelles la personnalisation du logiciel, l’installation, l’exécution, le test, la formation, la documentation et le support continu du système installé. 4. OBJET DU PRESENT APPEL D’OFFRE Cette section récapitule brièvement les produits et les services exigés qui font l’objet de cet appel d’offre. La solution requise doit proposer une application clés en main à prix fixe et couvrir tous les éléments suivants : 1. Package de logiciel d'application ; 2. Tout le matériel et tout autre logiciel (par exemple logiciel système, système de gestion de bases de données, etc.) nécessaire pour faire fonctionner l'ATS et du Dépositaire Central des Titres CSD à tous les points de connexion du projet, qui doit être compatible avec l'infrastructure Informatique existante de la BCM; 3. Les outils de numérisation des opérations de paiement et de dématérialisation des chèques et des effets pour les flux propres à la Banque Centrale de Mauritanie (BCM) ; 4. Un niveau élevé des services de conseil pour assister la BCM dans les aspects métiers dans la mise en œuvre de l'ATS et du CSD. Ces services incluront les aspects tels que l’élaboration des règles et procédures de fonctionnement et la politique de tarification pour l'utilisation du système, et le fournisseur retenu devra produire des versions provisoires de ces documents ; 5. Toutes personnalisations et intégrations requises du logiciel d'application, y compris l'analyse de conditions, les spécifications, le développement des modules spéciaux de logiciel et l’implémentation ; 6. L’interpréteur comptable destiné aux échanges aux échanges entre l’ATS et le système comptable de la BCM ; 7. La reprise des données de l’application actuelle de la BCM afin d’initialiser la base de données du système CSD ; 8. L’implémentation complète des services comprenant l'installation, le test, la documentation, la formation, la mise en service et la recette, et l’intégration à l’environnement Informatique existant; 9. Le support continu (post-acceptante). 4.1. COMPENSATION ET REGLEMENT L'ATS fournira les fonctionnalités modernes à la fois d’un système de règlement brut en temps réel (RTGS) et d’un système de Télécompensation automatisée (ACH) pour le règlement et la compensation, dans un seul et même système intégré, de tous les paiements électroniques interbancaires. La BCM souhaite que l'ATS soit basé sur un progiciel pour le règlement brut en temps réel, qui va gérer le règlement des opérations suivantes : 1. Paiements de montants élevés ou prioritaires entre les participants au système ; 2. Retraits et versements d’espèces aux guichets de la BCM ; 2. Soldes nets multilatéraux du système compensation ACH, composante de l'ATS ; 3. Soldes du système net interbancaire découlant de l’interbancarité monétique ; 4. Transactions impliquant l'achat et la vente des titres (sur les marchés primaires et secondaires) selon les principes de Livraison contre Paiement (DvP) et de STP ; 5. Règlement des transactions des marchés de change et monétaires. En plus des fonctionnalités du RTGS, l'ATS contiendra également la fonctionnalité de compensation (ACH) pour effectuer le traitement de différents flux de paiement de détail (de petit montant). Ceux-ci incluront : 1. Instructions de paiement sous forme de virements par lot ou au fil de l’eau ; 2. Fichiers d’instruction de prélèvements automatiques ; 3. Lot d’instructions de paiement en bloc, par exemple le paiement des salaires et les avantages sociaux ; et 4. D'autres flux de paiements de masse de petits montants mais de moindre priorité dont les chèques et les effets de commerce. L'ATS fournira un système simple et unifié pour le traitement de tous les types de paiement, indépendamment de leurs caractéristiques. Il fournira les fonctions qui dans certains pays ont été fournies par les différents systèmes logiciels (RTGS et ACH) qui ont dû être installés avec des interfaces pour réaliser ce que l'ATS réalisera dans un seul système intégré. Afin d’accélérer les contrôles nécessaires à la détermination du sort d’une opération (payable ou à rejeter), le système recherché véhiculera également les images digitalisées des chèques et des effets de commerce en même temps. Ainsi, il est attendu du fournisseur d’équiper les 4 agences de la BCM en postes de numérisation. 4.2. PARTICIPANTS En sus de la BCM, les participants directs à l'ATS seront les 18 banques commerciales. Toute autre nouvelle banque ou institution éligible pourra participer au système ATS. Par ailleurs les participants indirects pourront accéder au système ATS par l'intermédiaire des participants directs. Toutes les banques commerciales ont leur siège social à Nouakchott. Environ 80 pour cent d’agence des banques commerciales sont situées à Nouakchott. Le reste des agences est concentré principalement dans les villes principales à travers le pays ; leur présence dans les secteurs ruraux est très limitée. Aussi, le Gouvernement, Ministère de Finance (Trésor, l’administration fiscale, service des douanes) et les IMF, les émetteurs de monnaie électronique participeront au système afin de recevoir les informations sur leurs opérations de paiement. L’ATS se connectera uniquement aux sièges des banques ou à leurs représentations à Nouakchott. Les banques ont donc la responsabilité de ramener à Nouakchott, à travers leurs réseaux internes, l’ensemble des opérations effectuées par leurs agences afin de gérer ainsi leur back office. 4.2.1. Modes de participation Le système à fournir doit gérer différents types de participants : Participants Directs : Un participant direct tient son propre compte de règlement dans le système et dispose de son propre accès technique aux systèmes. La liquidité entière du participant est donc sous sa propre responsabilité. Participants Indirects Un participant indirect ne détient pas de compte de règlement dans le système ATS. Ses opérations sont réglées par le biais du compte de règlement du participant direct.. Sous-Participant (Participant Technique) Un sous-participant ne tient aucun compte dans le système. Il a son propre accès technique pour introduire un certain type d'ordres durant des périodes prédéfinies pendant la journée d’échange du RTGS (par exemple CSD, ACH, le switch monétique etc…) 4.3. INTEGRATION ET LIENS Des liens seront développés avec: 1. Le Dépositaire central des titres (Central Securities Dépositoire, CSD) pour permettre le règlement irrévocable des transactions de titres suivant le principe de livraison contre paiement et fournir le collatéral aux opérations d’apport en liquidité intra-journalière aux participants directs à l'ATS ; 2. le système d’information de la BCM ; 3. Les systèmes d’informations des banques participantes ; 4. Le Switch monétique interbancaire ; 5. Le système comptable et financier du trésor public ; 6. Le système comptable et financier de l'administration fiscale ; 7. Le système comptable et financier de service des douanes ; 8. La plate-forme de micro-finance. 9. La plateforme des émetteurs de monnaie électronique La BCM participe aussi aux projets d’intégration régionale aux systèmes régionaux de paiement ; le soumissionnaire retenu devra envisager la connexion à ces systèmes. 4.4. ENVIRONNEMENT TECHNIQUE 4.4.1. Sécurité et intégrité L'ATS sera développé et implémenté avec un niveau de sécurité le plus élevé et répondra aux attentes de tous les participants en terme de confidentialité, d'intégrité, et de disponibilité. L'intégrité opérationnelle sera mise en application à travers la possibilité de traitement du système sur le site nominal et de secours avec la redondance des composants clés et une étroite intégration entre les deux sites pour s’assurer que le système fonctionne à un niveau de performance et de fiabilité en rapport avec son rôle critique qu’il a dans l’économie nationale de la Mauritanie. 4.4.2. Matériel et logiciel associé Les offres doivent inclure les spécifications de tous les matériels nécessaires et de composants associés. Tous les équipements et logiciels à fournir devraient être compatibles avec l'infrastructure informatique existante de la BCM. Le fournisseur retenu devra donner des assurances contractuelles que toute la configuration convenue (matériel, gestion de réseau et logiciel) va supporter l'ATS dans des charges de travail prévues pendant au moins trois années après réception définitive. Les équipements et solutions proposées, notamment les serveurs ne seront pas des équipements d’entrée de gamme ni ne seront en fin de vie. 4.4.3. Communications La transmission et la réception des messages sécurisés est essentielle pour tous les éléments de l'ATS. Le système exigera les niveaux les plus élevés de disponibilité, de fiabilité et de performance. L’ATS étant hébergé à la BCM, le moyen de télécommunication entre la BCM et les autres participant se fera pour : - Les flux RTGS, à travers le réseau prive de la Gimtel avec une redondance sécurisée. Il faudrait aussi noter que le réseau Swift sera aussi considéré comme un backup ; - Les flux ACH, à travers le réseau privé Gimtel avec une redondance sécurisée. Le réseau Swift sera considéré comme un backup. 4.5. SERVICES La BCM comprend que le succès du projet ATS/CSD dépend particulièrement de la fourniture d'une gamme complète des services de haute qualité par le fournisseur retenu. Les offres doivent donc contenir les détails complets des services à fournir, comme indiqué dans la section 6. Les composantes des services des offres auront une pondération importante dans le processus d'évaluation des offres et les critères généraux. 5. EXIGENCES GENERALES DES SYSTEMES ATS ET CSD Les offres doivent considérer tous les aspects du système comprenant : 1. Les facilités et fonctionnalités fournies à tous les participants du système ; 2. Le niveau de performance du système ; 3. La facturation; 4. Les opérations, la maintenance et le support; 5. Le développement et l’amélioration; 6. La capacité, la montée en charge et la mise à niveau du système. Sauf mention précise ou caractère inapplicable, les caractéristiques ci –après s’appliquent taux systèmes ATS et CSD. 5.1. PRINCIPES Tous les composants logiciels doivent être basés sur la meilleure pratique internationale et être conformes aux principes suivants : 1. Avoir un niveau élevé de convivialité avec un système commun "look and feel" atteint grâce à une interface utilisateur graphique standard (GUI) ; 2. Etre conformes aux conventions standards de l'industrie et disposer des outils qui permettent au système d'être interfacé facilement avec d'autres systèmes, et / ou l’environnement doit être évolutif soit par les fonctionnalités des différents modules, soit par l’accroissement de la volumétrie 3. Offrir des connexions techniques à faible coût et facilement mises en œuvre pour les sites des participants externes soit sur un terminal distant ou hôte-à-hôte pour l'ensemble du trafic du système ; 4. Permettre aux opérateurs du système de la BCM d'ajouter, de supprimer ou suspendre facilement des participants ; 5. Le cas échéant permettre une utilisation optimale de tout équipement qui est déjà installé au sein de la BCM ou chez les participants; 6. Fournir les pistes d’audit complètes pour toutes les activités dans le système, y compris les accès au système ainsi que les messages envoyés et reçus ; 7. Avoir des niveaux élevés de fiabilité avec un accent particulier sur l’intégrité des données et la sécurité, en particulier la prévention d'accès non autorisé et d’assurer à 100% la fidélité de données; 8. Avoir des niveaux très élevés de disponibilité de service qui seront assurés par la démonstration, le test rigoureux et un accord robuste de niveau de service (SLA) ; 9. Offrir une automatisation du traitement quotidien et des synthèses de rapport de contrôle à la BCM ainsi qu’aux participants ; 10. Fournir les outils complets de gestion d'événement et d’incidents; 11. Etre configuré de manière à gérer la charge de travail attendue en termes de capacité de traitement et temps de réponse, en tenant dûment compte des pics des volumes de transaction et l’évolution attendue de la volumétrie de transaction. 5.2. SPECIFICATIONS OPERATIONNELLES Le système devrait: 1. Permettre une personnalisation facile pour s’ajuster aux nouvelles règles, des modifications ou changements des règles qui régissent les différentes fonctions, par exemple créer un nouveau type de message, créer un nouveau type d’instrument, etc. ; 2. Permettre au personnel autorisé de modifier le flux des processus métiers à travers le réglage des paramètres dans les tables de contrôle de processus ; 3. Fournir un accès en ligne et un système de reporting des enregistrements archivés - couvrant une période d'au moins dix (10) ans, plus l'année en cours - sans compromettre les temps de réponse ; 4. Fournir une aide en ligne contextuelle pour les fonctions d’utilisateur et d'opérateur ; 5. Activer l'automatisation du traitement quotidien notamment en lançant des connexions vers des systèmes directement interfacés en utilisant des procédures de sécurité appropriées et d'exception ainsi que les synthèses des rapports de contrôle ; 6. Etre résilient de manière effective, avec des niveaux élevés de reprise après sinistre pris en charge par une installation de sauvegarde correctement configurée et un bon basculement entre le site nominal et de secours et vice-versa. 5.3. INTEGRITE Le système devrait fournir : 1. Les contrôles de l'intégrité financière pour s’assurer que la «valeur entrée correspond à la valeur sortie » de manière qu’en tout temps la réconciliation au niveau de l’ATS présente un solde nul ; 2. les contrôles de l'intégrité de traitement de message pour s'assurer que la valeur nominale totale de tous les instruments dans tous les registres correspond et est égale aux totaux de contrôle pour tous les résultats enregistrés ; 3. Les contrôles de l'intégrité de traitement pour s’assurer que « le nombre d’articles financiers entrés = au nombre d’articles financiers sortis » à tout moment et que chaque site de traitement peut réconcilier vers une position «pas d’article manquant » à n’importe quel moment; 4. Un reporting cohérent et régulier du traitement financier, les logs de sécurité, les positions de règlement calculés, les valeurs de règlements brut et net, le nombre de lots et des fichiers traités, etc. qui peuvent être rapportés à la fois localement et centralement pour prouver l’intégrité du système et la réconciliation complète à l’échelle du système ; 5. Enregistrement local de tous les messages envoyés, en attente et reçus chaque jour ; 6. Cryptage de tous les flux de données ; 7. Audit de fin de journée et rapport d’activités ; 8. Résilience sur site (capacité de reprise après défaillance sur le site nominal ou de secours); 9. Sécurité des messages avec un niveau élevé d'authentification de messages, d’intégrité des données, et de confidentialité ; 10. Un niveau très élevé de disponibilité et de fiabilité ; 11. Garantie de non perte de données ni lors de la transmission ni après une défaillance. Les fonctions de gestion du système doivent être entièrement intégrées. Par exemple, le réglage de n'importe quel paramètre qui peut être applicable à tous les composants du système doit être exécuté en une fois. 5.4. TRANSACTION ET COMMANDES DE TRAITEMENT DE FICHIER Les transactions et les fichiers entrants doivent être contrôlés pour s’assurer entre autre que : 1. le type et le format sont corrects ; 2. la source est autorisée ; 3. l'identification, la date et, pour les fichiers, les totaux de contrôle sont corrects ; 4. le message n'est pas dupliqué ; Les transactions et les fichiers sortants doivent être contrôlés pour s’assurer entre autre que : 1. aucune transaction ou fichier ne sera laissé non livré ; 2. Si la livraison n'est pas possible, les alertes doivent être notifiées ; 3. Il ne doit pas être possible de livrer deux fois, excepté selon les procédures de reprise quand les deux parties sont averties de la possibilité que le message peut être dupliqué. 5.5. CONTROLES DE VALIDATION Les contrôles de validation doivent inclure : 1. la validation des instructions de paiements de tous les types, par lots et au fil de l’eau; 2. la validation de champs obligatoires et optionnels dans les instructions de règlement de valeurs; 3. L’authentification de l'expéditeur du message ; 4. La confirmation et de la validité de message à l'expéditeur ; 5. Les procédures de validation flexibles et adaptables. Les offres doivent décrire des options de validation offertes par leur solution proposée et dans quelle mesure celles-ci peuvent être adaptées à la BCM, et quels peuvent en être les inconvénients pour la BCM. 5.6. INTEGRITE ET NON-REPUDIATION DES MESSAGES Les contrôles doivent inclure ce qui suit : 1. Chaque enregistrement d'instruction de changement ou instruction de paiement, et les fichiers contenant de telles instructions, doivent être identifiés de façon unique par sa source physique, identification de l'utilisateur la date et l'heure d'entrée dans le système; 2. Chaque instruction doit être exécutée selon les niveaux d'autorisation unique ou multiple (suivant le principe de : deux yeux, quatre ou six yeux) imposées par l'administrateur et / ou les participants; 3. Une séquence de numérotation de message et une procédure de contrôle doivent être implémentées pour s'assurer qu’il n'y a aucune perte, duplication ou insertion non autorisée des messages ; 4. La non répudiation est exigée pour tous les messages des participants ; 5. La reconnaissance de niveau d'application de message est exigée comme composant obligatoire de la gestion de messages ; 6. Lorsqu’un opérateur a la possibilité d'apporter n’importe quelle modification à n'importe quel message (par exemple des messages qui contiennent des instructions pour effectuer des paiements ou le transfert de titres ou des paramètres critiques du système), le système doit requérir des autorisations multiples; 7. Il doit être possible que la gestion opérationnelle retrace automatiquement n'importe quelle transaction du point d'entrée dans le système jusqu'à la destination finale avec des informations complètes sur le temps où le message a été reçu et transmis, et le traitement qui s'est produit à chaque étape manipulant la transaction/ le fichier. L'information à cette fin doit être gardée en ligne pendant un certain nombre de jours qui peuvent être définis par la BCM, après quoi les données doivent être archivées au stockage hors ligne permanent ; 8. Il devrait être possible de suspendre le traitement des éléments du système (par exemple les files d'attente ou les flux choisis de paiement) au cours de la journée d’échange et de reprendre l’opération sans perte ou duplication des messages ; 9. En cas de défaillance conduisant à une indisponibilité du site principal, la reprise du service sur le site de secours doit être effectuée dans un délai maximum de dix minutes avec une intervention minimale de l'exploitant. 5.7. EXPLOITATION DU SYSTEME 1. Pour réduire au minimum la possibilité pour qu’une erreur humaine provoque des ruptures de service, le fonctionnement du logiciel devrait être automatisée le plus possible, avec des contrôles pour assurer l’exécution réussie de chaque tâche comme condition pour le déclenchement des tâches suivantes ; 2. Le logiciel devrait offrir une interface utilisateur graphique cohérente (GUI) pour permettre à la BCM de contrôler tout son environnement. Ceci devrait fournir une gamme complète des paramètres définis par l’utilisateur qui doivent être amplement décrits dans les offres ; 3. Pour aider à l'exécution de la politique monétaire, le système devrait pouvoir montrer en ligne des synthèses concises de la BCM sur la situation globale de liquidité du système, situations en cours, antérieures ainsi que les situations comparatives (heures, jours, et semaines) ; 4. Tous les aspects du système doivent être contrôlés par l'intermédiaire d’une seule interface graphique utilisateur (GUI) ; 5. Des besoins d’interventions techniques doivent être réduits au minimum. Il est particulièrement important que tous les messages d'erreur soient simplement présentés pour le personnel opérationnel comprendre et de réagir aisément; 6. Le système devrait exiger une intervention minimale de l’équipe technique de la technologie de l’information (de préférence aucune) pour ce qui concerne les opérations normales de telles que le démarrage du système, les opérations quotidiennes et l’arrêt du système. 7. Le système devrait fournir une série d’alarmes et d’alertes avec des options pour : a. Différents niveaux d’alertes (par exemple critique, sérieux, l'information- seulement) b. La nature des alertes disponibles (par exemple message clignotant au poste de travail d'opérateur, un avertissement audible, un email, SMS à un téléphone portable) ; c. Destinataires des alertes (par exemple les opérationnels de la Direction du Système de Paiement de la BCM, les autres directions participantes, les utilisateurs finaux des banques participantes, etc.) ; 8. Les mesures de certification auront lieu en utilisant l'environnement de test qui doit être établi en tant qu'élément de cette offre. Elles doivent être effectuées en utilisant un ensemble standard de messages de test qui seront développés en tant qu'élément de l'implémentation du système global et doivent inclure : a. le test et la certification de nouveau logiciel)/mise à niveau préalables à l’utilisation ; b. le test et la certification des systèmes de nouveaux participants en ce qui concerne le matériel, le logiciel, les télécommunications et les procédures. 5.8. REQUETES ET REPORTING L'ATS fournira un reporting complet et les outils de requête en ligne permettant à tous les participants de faire une large gamme de requête afin de surveiller leurs positions, améliorer les fonctionnalités du système, gérer la liquidité intra-journalière, faire des requêtes pour la file d'attente et ainsi de suite. 5.8.1. Rapports Les offres doivent contenir une liste complète de toutes les requêtes et rapports standards disponibles dans le logiciel proposé, pour tous les types d'utilisateurs. Elles doivent également inclure un échantillon représentatif (des listes et des captures d’écran) d'instructions et de rapports suffisants pour que la BCM puisse avoir une bonne compréhension de ce qui est fourni. Ces échantillons doivent démontrer la compréhensibilité, l’utilité et la globalité d'informations contenues dans des écrans de requêtes et de reporting. Les offres doivent contenir des détails surs : i. comment le personnel de la BCM peut adapter/personnaliser les reportings standards comme désiré ; ii. les outils proposés de rédaction d’autres rapports (non standard ou ad-hoc) ; et iii. les propositions de formation /transfert de connaissance pour s'assurer que le personnel de la BCM serait capable de créer de nouveaux rapports. 5.8.2. Tableau de bord La BCM souhaite implémenter un tableau de bord consolidé pour permettre aux administrateurs de systèmes de gérer tout l’ATS. Ceci va requérir l’utilisation d’un grand écran localisé dans la zone d'opérations pour fournir au personnel de la BCM une vue globale de l’état de tous les éléments critiques et importants du système. Les soumissionnaires doivent décrire comment leur système répondrait à ce concept, avec des recommandations quant aux données élémentaires qui seraient présentées. 5.9. SECURITE 5.9.1. Monitoring et mesure 1. Tous les accès au système doit se faire à travers (e-tocken – certificat digital), les transactions gérées par le système et les changements affectant les contrôles d'accès, les paramètres système, les répertoires et les fonctions similaires de contrôle et d'intégrité doivent être consignés et rapportés aux opérateurs BCM, et doivent être accessibles pour la récupération et les analyses autorisées, sur une base quotidienne. Il ne doit pas être possible de modifier en aucun cas le contenu d'un journal d'audit; 2. Les renseignements suivants doivent être fournis: a. Totaux de contrôle pour une journée de traitement dans un lieu; b. Gestion de tous les utilisateurs du système (à la fois de la BCM et les autres participants) et leurs privilèges d'accès; c. Les tentatives d'accès non valides à des postes de travail; d. Le nombre, la fréquence et la source de transactions et les fichiers invalides; e. Tous les comportements inhabituels par un utilisateur autorisé, indiquant un risque accru et / ou tentative de fraude. 5.9.2. Contrôles d'accès 1. L'accès à toutes les parties du système doit être limité au personnel ou aux systèmes autorisés au moyen d’un système et d’équipement d’authentification forte des utilisateurs. Les possibilités d'authentification d'utilisateur doivent inclure l'authentification par deux facteurs, et les offres doivent contenir les solutions et matériels pour 100 utilisateurs. Le vendeur doit prévoir l’utilisation des e-Tocken 2. Le système devrait supporter une structure hiérarchique d’utilisateurs, telle qu'à chaque participant (et également dans la zone opérationnelle de la BCM) il peut y avoir un administrateur local avec certains droits additionnels (par exemple pour la réinitialisation de mot de passe) ; 3. La séparation des fonctions doit être strictement applicable pour tous les programmes et fonctions sensibles ; 4. Tous les accès doivent être notés pour inclure l'identification système ou l’équipement physique, l'identification d'utilisateur et la durée de chaque accès afin de fournir des pistes d’audit pour la revue en cas de violation accidentelle ou délibérée des contrôles de sécurité ; 5. Les procédures système d’ouverture de journée doivent inclure l’initiation des systèmes directement interfacés et la confirmation de l'authenticité de chaque système interfacé ; 6. Les utilisateurs ne doivent pas voir les options de menu pour les fonctions qu'ils ne sont pas autorisés à utiliser ; 7. Le système doit imposer la gestion forte de mot de passe. Cela inclut: 1. utilisation des mots de passe « forts »; 2. expiration obligatoire des mots de passe à intervalles définis; 3. désactivation des comptes après un nombre de tentatives d'accès non réussies; 4. et interdiction de la réutilisation d'un nombre défini de mots de passe précédemment utilisés ; 8. Des postes de travail de l'application doivent être automatiquement déconnectés s’ils ne sont pas utilisés sur une période indiquée (mais variable), pour empêcher l'accès par les tiers non autorisés. 5.9.3. Fiabilité 1. Le système doit fournir le niveau le plus élevé de disponibilité. Le système devrait donc être configuré pour pouvoir reprendre automatiquement son fonctionnement à partir de n'importe quelle défaillance simple, et sans interruption de service ; 2. De toute façon, le système doit pouvoir terminer le traitement de toutes les transactions du jour dans un maximum de deux heures après la fermeture normale de la journée. 5.10. EXIGENCES DE TRAITEMENT La BCM exige le niveau le plus élevé de performance, de disponibilité et de fiabilité du système. Le système sera donc implémenté pour fonctionner sur deux sites. Une copie supplémentaire du système pour le test et la formation sera également déployée sur le site principal En outre, la BCM va régulièrement copier toutes les données sur des supports de back-up quotidiennement, par semaine et mensuellement et va les stocker dans un endroit hors site. 5.10.1. Résilience Opérationnelle Tous les éléments de système doivent être conçus et configurés pour fournir un niveau très élevé de fiabilité, de résilience et de disponibilité. Le système du site principal devrait se synchroniser avec le système sur le site de secours (et vice versa) de manière que, en cas de panne sur l’un des sites, l'autre site puisse continuer de fonctionner automatiquement (ou avec une intervention manuelle minimale). Les fournisseurs doivent décrire soigneusement ces cas, et faire des recommandations appropriées pour réaliser le niveau le plus élevé de performance et de fiabilité. Les offres doivent contenir des spécifications détaillées de tout le matériel proposé, des logiciels et de tous les autres composants nécessaires pour réaliser les niveaux exigés des délais de fiabilité et de basculement. Ils doivent également inclure le cas des pires scénarios exigeant un basculement complet du site principal vers celui de secours. 5.10.2. Environnement de test Un environnement de test devrait être disponible à tout moment pour permettre le test des changements système planifiés, ou des tests d'interface de participant. Les fournisseurs doivent décrire comment ils accompliront les tâches principales suivantes : 1. Gestion des changements impliquant le matériel, le logiciel système et le logiciel d'application, couvrant tous les participants ; 2. Opération des composants système ci-dessus ; 3. Test des changements de paramètre faits par l'opérateur du système. Il est attendu que l’implémentation du système initial suive ce processus. 5.11. EXIGENCES OPERATIONNELLES 5.11.1. Chronologie de la journée d’échange La BCM publiera un programme annuel donnant le cycle de traitement journalier du système. La synchronisation et la durée de différentes fenêtres de traitement seront convenues entre la BCM et les participants. Ainsi, le cycle de traitement journalier de la composante RTGS pourra être différent de celui de la composante ACH. Le temps d'exploitation de système sera flexible et capable d'ajustement pour s’adapter aux circonstances anormales. Pour certains types de paiements (files d'attente) il doit être possible de suspendre l'opération journalière et la relancer un autre jour tout en maintenant la même date de valeur. 5.11.2. Début/Fin de journée Excepté des dispositions sécuritaires, toutes les procédures liées à l'activité de début/fin de journée doivent être actionnées automatiquement. 5.11.3. Monitoring de performance La performance de tous les composants du système sera surveillée et pilotée de manière continue, et des rapports d'exception appropriés seront produits avec des pics appropriés toutes les fois que les performances du système diminuent par rapport aux standards de rendement acceptables. Les offres doivent inclure des détails des recommandations des fournisseurs couvrant au moins ce qui suit : 1. Un système de monitoring de performance, y compris un moniteur d'événements intégré avec le tableau de bord, qui dépeint des événements critiques opérationnels et de sécurité comprenant le statut opérationnel de tous les utilisateurs autorisés et les tentatives d'accéder au système par les utilisateurs non autorisés ; 2. Introduction d'un système de reporting qui peut être employé pour surveiller la qualité de service et pour fournir des informations appropriées à tous les participants. Les fournisseurs doivent décrire comment les différentes mesures doivent être monitorées et, le cas échéant, donneront également une indication des niveaux de performance qu’ils comptent typiquement réaliser. Les mesures doivent inclure ce qui suit : Disponibilité du Système La disponibilité du système devrait pouvoir être mesurée (par exemple, par le taux de disponibilité de chaque composant pendant les heures ouvrables, indépendamment des sources de dysfonctionnement (par exemple, logiciel, réseau, puissance, erreur humaine). Comptage des messages Un comptage doit être réalisé concernant les messages en fonction les paramètres suivants : 1. Le nombre et la valeur de messages par jour et par type de paiement, flux (file d'attente) par participant et le total ; 2. Le nombre et la valeur de messages traités pendant l'heure de pointe ; 3. Temps moyen des messages dans la file d'attente, par participant et le total par jour. D’autres possibilités de paramétrage doivent également être proposées pour réaliser des comptages ou des statistiques de performance. Les offres doivent décrire tous les outils disponibles pour la collecte et l’élaboration des statistiques par la BCM et les participants. 5.11.4. Règles et procédures opérationnelles Il est attendu que les soumissionnaires conseillent et aident la BCM dans l’élaboration et l’implémentation des règles et des procédures « métier » en ce qui concerne le fonctionnement du système (pour la BCM et les participants). Ceci doit inclure la fourniture de modèles de documents appropriés que la BCM pourrait adapter. 5.12. L'INFORMATION DE FACTURATION Le système doit inclure un mécanisme flexible de facturation qui calculera automatiquement des frais pour chaque participant, et qui devrait avoir les fonctionnalités suivantes : 1. Calculer des frais périodiques fixes (par exemple frais annuels ou mensuels d'adhésion) d'être prélevés ; 2. Calculer les frais d'utilisation basés sur le message ou le type d'instruction ; 3. Appliquer les coefficients de modification de tarif par message pendant des tranches horaires au cours de la journée ; 4. Appliquer les coefficients de modification de tarif pour différents flux de paiement (files d'attente) ; 5. Appliquer les coefficients de modification de tarif pour des volumes de transactions ; 6. Tenir compte de différents frais selon le participant ; 7. Appliquer les frais directement, sans l'intervention manuelle autre qu'autoriser la transaction ; 8. Etablir automatiquement les factures à envoyer à tous les participants directs et indirects. Des périodes/cycles de tarification et de facturation doivent être flexibles et fixés par la BCM. Les soumissionnaires doivent expliquer en détail les options et les possibilités de la fonctionnalité de tarification et de facturation, y compris la génération automatique des messages de paiement appropriés. Il est attendu que le soumissionnaire retenu conseille et aide la BCM à élaborer et mettre en place une politique de tarification et de facturation appropriée. 6. EXIGENCES FONCTIONNELLES SPECIFIQUES DE L’ATS Le système de transfert automatisé (ATS) proposé, permettra le traitement et le règlement de tous les paiements interbancaires, gros et petits montants. Il n'y aura aucune limite définie des valeurs (élevées et basses) pour les paiements admis au traitement. 6.1. OBJECTIFS Les objectifs de l'ATS sont : 1. Réduire les risques systémiques de règlement auprès de la BCM et des participants au système de paiement en fournissant la possibilité d’un règlement en temps réel de gros montant sur les comptes actuellement hébergés à la BCM ; 2. Améliorer l’efficacité et le service aux participants ; 3. Permettre l’intégration des futurs services ; 4. Se conformer aux meilleures pratiques internationales telles qu’éditées par la Banque des Règlements Internationaux (BRI) ; 5. Fournir des possibilités efficaces et rentables de compensation et de règlement pour tous les paiements interbancaires, avec la possibilité de faire face à la croissance attendue des volumes de transactions ; 6. Réaliser le règlement en temps réel des paiements entre ses participants en les livres de la BCM suivant le principe d’irrévocabilité et de finalité des paiements ; 7. Fournir les outils pour augmenter l'efficacité de la gestion quotidienne de la liquidité des participants en fournissant le monitoring et le reporting en temps réel sur la situation de compte de règlement des banques; 8. Minimiser le risque systémique de paiements à travers la gestion de la liquidité par banque et au niveau de tout le système ; 10. Améliorer les instruments pour permettre à la BCM de mettre en œuvre sa politique monétaire ; 11. Intégrer la compensation et le règlement des transactions sur titre du gouvernement et de la BCM suivant le principe de la livraison contre le paiement (Delivery versus Payment, DvP) ; 12. Mettre en place un système de règlement et de paiement fiable, sûr, et intégré pour satisfaire les besoins d'une économie en pleine croissance, avec la possibilité de couverture de nouveaux instruments et systèmes de paiement qui pourraient naitre. Comme expliqué précédemment, la BCM souhaite acquérir une solution intégrée moderne, capable de compenser et régler tous les types d'instruments électroniques dans un système électronique unique. Le Système de Transfert Automatisé (ATS) devrait offrir différentes modalités de traitement pour des paiements de valeur élevée, prioritaires ou urgents (traités par la composante RTGS) et de paiements de petits montants /détail (traités par la composante ACH) et du CSD, mais ceux-ci doivent être intégrés de façon à fournir une seule interface utilisateur cohérente. Les soumissionnaires doivent donc décrire tous les types d’instruments de paiement et les situations que leur solution proposée pourra gérer. L'ATS sera étroitement couplé au système de gestion des titres : i. pour assurer la livraison contre le paiement (Delivery versus Payment, DvP) pour des transactions sur titres par le gouvernement et la BCM ; et ii. pour supporter le processus de gestion de liquidité intra-journalière dans l'ATS. 6.2. COMPOSANTE ACH - FONCTIONNALITE DE COMPENSATION Au démarrage du système, les catégories d’opérations admises dans la composante ACH de l’ATS sont : ✓ Les présentations de chèques ordinaires, chèques garantis, chèques de banque et chèques certifiés ; ✓ Les présentations d’effets de commerce échus : lettres de change et billets à ordre ; ✓ Les présentations de virements de clientèle ordinaires, virements de mise à disposition, virements à date d’échéance garantie, virements de régularisation et virements en provenance de l’étranger; ✓ Les présentations de prélèvements échus et pré-autorisés ; ✓ Les annulations de chèques, d’effets de commerce et de prélèvements ; ✓ Les rejets de chèques, d’effets de commerce, de virements et de prélèvements; ✓ Les messages non financiers adressés à la Banque Centrale ou à un autre participant. La BCM peut être amenée à autoriser à l’avenir d’autres moyens de paiement. Par conséquent les types d’instruments admis dans le système, les formats d’enregistrement, contrôles et délais de règlement correspondants doivent faire l’objet de paramétrages dans le système. Les offres doivent contenir les détails de toutes les options fournies par la composante ACH pour la compensation des flux antérieur de paiement (par exemple, calcul de solde différé et continu) et comment les soldes obtenus sont réglés dans la composante RTGS. 6.2.1. Virements Les offres doivent contenir des détails sur la façon dont les opérations de virements seront gérées dans la composante ACH, s'ils sont soumis par lot ou au fil de l’eau. 6.2.2. Prélèvements Les offres doivent décrire en détail comment les prélèvements seront gérés dans la solution proposée 6.2.3. Gestion des chèques Comme précédemment décrit, l'utilisation des chèques en Mauritanie est relativement limitée, et un des objectifs principaux de la composante ACH de l'ATS est de promouvoir et de faciliter une large et plus efficace utilisation des instruments électroniques plus rentables et plus sûrs. Néanmoins les chèques restent un moyen de paiement important et on peut prévoir que leur utilisation puisse continuer et probablement même se développer tandis que l'ATS est établi et de nouveaux instruments de paiement sont utilisés. Afin de rendre le traitement des chèques plus efficace, la composante ACH de l'ATS doit donc posséder des fonctionnalités pour compenser les fichiers des enregistrements électroniques des chèques dont les images ont été capturées à l'aide des scanners. Les offres devraient contenir des détails et des recommandations, sur la procédure et la technique, de la façon dont l'ATS proposé gérera et compensera ces enregistrements, y compris le logiciel facultatif que les banques peuvent utiliser pour capturer les enregistrements des chèques. L'introduction des fonctionnalités de traitement automatisé des chèques exigera l'accord des banques sur la standardisation des chèques et le manuel d’utilisation avant de finaliser les détails sur la fonctionnalité associée d'ATS. Ceci sera fait avec la participation du fournisseur. La BCM s’attend à ce que les offres financières prévoient le support nécessaire et tout éventuel développement de logiciel requis pour répondre à ce besoin. 6.2.4. Paiement en bloc La solution proposée doit fournir les fonctionnalités pour que l’ATS puisse gérer les paiements en bloc, qui comportent différents paiements multiples dans une unique instruction composée de paiements, par exemple pour le règlement des salaires des fonctionnaires, des pensions, etc. Les soumissionnaires devraient décrire en détail comment leur solution va prendre en charge cette disposition. La BCM s’attend à ce que les paiements en bloc puissent être gérés de différentes manières, et les soumissionnaires sont priés de décrire tous les équipements offerts par leurs solutions pour le traitement des paiements en bloc et, si applicable, de recommander l’option préférée. 6.2.5. Compensation Les offres doivent contenir des détails sur toutes les options que contiennent la composante ACH pour la compensation des flux de paiements (par exemple le calcul du solde net en continu ou différé) et la façon dont les soldes qui en résultent seront réglés dans la composante RTGS. 6.2.6. Solution de numérisation (scanners) Les soumissionnaires devront fournir au moins 20 postes de numérisation (scanners) des chèques et effets de commerce normalisés pour la BCM lors du lancement du projet. Les soumissionnaires devront donner les détails techniques de leurs scanners afin de permettre aux participants de s’équiper pour traiter leurs propres opérations. Le présent cahier des charges ne traite pas des solutions de numérisation pour les banques commerciales. Celles-ci s’équiperont des solutions de numérisation qui leur conviennent et au moment de leur choix jusqu’à une date limite fixée par la BCM à laquelle tous les échanges doivent être dématérialisés. Les postes de numérisation seront composés d’un scanner de chèques (et effets de commerce) d’une capacité de 100 chèques, capable de lire la ligne CMC7 et produire les images recto/verso des chèques et des effets de commerce. Le scanner devra avoir une résolution minimale de 200dpi et un format à 256 niveaux de gris compressés en JPEG. Il est relié à un poste de travail hébergeant un logiciel permettant de réaliser les traitements suivants : • Créer des remises composées de lots par banque tirée, par devise et par remettant (le participant BCM ou ses sous-participants). Le personnel de la BCM saisit le remettant, le nombre et le montant total figurant sur la remise client pour contrôle ultérieur ; • Acquérir les images scannées recto-verso des chèques et effets de commerce et les afficher. Les images sont au format JPEG compressé. Le poids d’une image ne dépassera pas 50 kilo octets ; • Gérer les anomalies lors du passage au scanner (bourrage, chèque retourné…) et permettre d’annuler la remise en cours et de la reprendre ; • Afficher la ligne CMC7 ; • Corriger les données mal lues de la ligne CMC7 (et uniquement celles-ci / contrôle effectué par le système) ; • Saisir les montants ; • Effectuer les contrôles de cohérence : ✓ Syntaxe de la ligne CMC7 ; ✓ Clé RIB ; ✓ Clé RLMC si présente ; ✓ Code banque, code guichet, Code nature chèque • Signaler les doublons d’opérations (même numéro de chèque, n° de compte, montant) au regard d’un archivage des opérations sur un nombre paramétrable de jours et permettre de les supprimer ou les corriger • Vérifier le nombre et le montant total des chèques saisis par rapport aux totaux préalablement saisis, signaler les erreurs et permettre la correction. • Pour les effets de commerce : saisir les données complémentaires pour compléter le format de l’effet (RIB débiteur, date d’échéance, aval…) • Constituer les transactions financières avec les données enregistrées et attribuer une référence unique permettant d’indexer les images, composée du code banque sur 3 caractères, code opération sur 2 caractères, numéro séquentiel sur 20 caractères dans des séries propres à chaque agence de la BCM. • Constituer des lots par nature de moyen de paiement, devise et émetteur. • Transmettre les lots à la plateforme participant de la BCM qui composera les remises à transmettre au système de compensation. 6.3. COMPOSANTE RTGS 6.3.1. Opérations admises à l’échange via la composante RTGS La BCM s’attend à ce que la composante RTGS de l'ATS règle les opérations ci-après : 1. les transactions de montants élevés ou prioritaires dont les retraits et dépôts d’espèces effectués par les participants directs auprès des guichets de la BCM ; 2. les paiements interbancaires ; 3. les opérations de banque centrale, qui peuvent être des crédits ou des débits effectués sur les comptes des participants directs ; 4. les soldes/ positions nets de la composante de compensation ACH de l’ATS; 5. les soldes / positions nets du switch monétique national (transactions par cartes de paiement); 5. Opérations de règlement relatives aux achats et ventes des titres (aux marchés primaires et secondaires) selon les principes de livraison contre paiement (DvP) et d’opérations de bout en bout(STP) ; 6. les opérations de règlement des soldes des échanges réalisés dans les futurs systèmes de bourses de valeurs et du marché monétaire. 6.3.2. Caractéristiques principales de la composante RTGS Le système RTGS visé devra être conçu selon des normes internationales. La banque centrale joue quatre rôles différents dans le système : • Gestionnaire du système, • Administration et surveillance du système, • Exploitation du système, • Participant. Le système de RTGS fournira les services principaux suivants : • Transferts de fonds, • Envoi des requêtes de consultation des soldes et des mouvements sur des comptes de règlement, • Service de liquidité intra-journalière par l'intermédiaire des transactions de REPO, etc.., • Envoi des requêtes concernant le statut des instructions de transfert situées en file d'attente, y compris des instructions de modifications telles que modifier la priorité d’un paiement, changer sa position dans la file d’attente • Services "d’envoi de messages", • Les facilités de reporting, • Un niveau élevé de sécurité pour toutes les transactions, • Disposition de permettre des transactions transfrontalières avec d'autres systèmes RTGS régionaux et internationaux à l'avenir, 6.3.3. Participants Les entités habilitées à la participation dans la composante RTGS sont : • La Banque Centrale, • Les banques commerciales et institutions financières éligibles, • L’administration fiscale (Trésor, douanes, services des impôts …) en tant que participant indirect sous la responsabilité financière de la BCM, • La future Centrale d’incidents de paiement en tant que participant technique, • Le switch monétique national (GIMTEL), • Le dépositaire central des titres, 6.3.4. Règlement des transactions sur titre La composante RTGS doit avoir une connexion au système Dépositaire Central des Titres(CSD) pour le règlement des transactions sur titres qui incluront en premier lieu : 1. les Opérations du marché primaire de la BCM pour l’émission des titres publics ; 2. les Opérations d’open market de la BCM ; 3. La Gestion de liquidité intra-journalière et d'autres opérations de politique monétaire de la BCM ; 4. Le Règlement des transactions de titres publics au marché secondaire Pour toutes ces transactions, le principe de STP doit être garanti. L’interaction opérationnelle entre l'ATS et le CSD doit garantir la livraison contre le paiement (DvP). 6.3.5. Gestion de file d'attente et priorités de traitement La composante RTGS de l'ATS fonctionnera sur la base des flux de paiement multiples ou des files d'attente. Les soumissionnaires doivent décrire en détail les mécanismes de gestion de file d’attente offerts par leurs solutions proposées (nombre maximum des files d'attente et types de file d'attente).Les caractéristiques suivantes seront proposées : 1. Le système devrait avoir les possibilités de stocker certains types de transactions pour les exécuter à une date et à une heure ultérieure, comme indiqué par le participant. 2. Les files d'attente auront différents niveaux de priorité. Les participants doivent pouvoir assigner des niveaux de priorité à tous les paiements soumis. 3. Certaines files d'attente s’opéreront sur la base du principe de "premier entré, premier sorti" (FIFO), à moins que des mécanismes spécifiques de résolution de congestion soient appliqués par la BCM en tant qu’opérateur ou au cas où les ordres de priorité sont communiqués par les participants. 4. La gestion des files d'attente doit permettre aux trésoriers de chaque participant de s’assurer que les instructions de paiement soumises sont généralement traitées selon l'ordre et/ou les priorités qu’ils ont soumis. 5. Des instructions de paiement seront tenues dans chaque file d'attente par participant, dans l'ordre dans lequel le participant les introduit et selon le code prioritaire qu’il a assigné (il y aura une file d'attente pour chaque niveau de priorité par participant).Chaque participant ne gèrera que les files d'attente pour les instructions de paiement qu'il a émises. 6. Aucune transaction de faible priorité ne sera réglée avant que toutes les instructions de priorité plus élevé soient réglées. L'ordre ou l’instruction de paiement ayant la priorité élevée dans la file d'attente est réglé dès que les fonds sont disponibles ; les autres instructions de paiement dans la file d'attente sont traitées par la suite. 7. Afin de faciliter la gestion de liquidité journalière, le système devrait offrir aux participants la possibilité de modifier la priorité des paiements et/ou leur rang dans la file d'attente. 8. La composante RTGS doit être conçue pour éviter la congestion qui pourrait mener à une défaillance systémique, et doit contenir un mécanisme de résolution des blocages. 9. Le système doit fournir des outils de gestion automatique de file d'attente ou offrir des facilités d’intervention à la BCM pour les analyses, accompagnées des solutions aux opérateurs BCM pour implémentation. Ces facilités doivent inclure la possibilité de réorganiser les ordres et optimiser leur traitement en vue de leur règlement ; 10. Si une procédure de déblocage des files d’attente est déclenchée automatiquement ou manuellement par la BCM, elle devrait être portée à la connaissance des participants au système. 11. Chaque participant et la BCM doivent être en mesure de s’informer sur le nombre et le montant cumulé de ses transactions se trouvant dans les files d’attente. 12. Le participant initiateur de l’instruction de paiement doit être en mesure d’annuler une transaction de paiement se trouvant dans la file d'attente. Une transaction de paiement peut seulement être annulée si elle n'a pas été réglée. 13. Les transactions de la même date de valeur non réglées à la fin de la journée d’échange sont annulées (avec notification au participant). 6.4. GESTION DE LIQUIDITE ET INTERFAÇAGE AU SYSTEME COMPTABLE DE LA BCM La gestion de liquidité est un élément critique dans le fonctionnement efficace et efficient d'un système ATS ou RTGS ; la BCM entend accorder une importance significative à ces facilités et ces fonctions dans le processus d'évaluation des offres. Les soumissionnaires doivent fournir des explications détaillées sur les caractéristiques et les options de leur outil de gestion de la liquidité (incluant toute option d’interfaçage à un système externe de gestion des collatéraux) dans leurs offres, et fournir également une démonstration et des explications claires de ces dispositifs lors des réunions de présentation de l’offre. 6.4.1. Compte de règlement et de réserve obligatoire Chaque banque commerciale dispose d’un compte de règlement dans les livres de la BCM, qui est utilisé pour le règlement des obligations envers la BCM et les autres banques. En outre, ce compte sert également à la constitution de la réserve obligatoire. Ce compte doit en permanence afficher un solde positif ou nul. Interfaçage avec le système bancaire et comptable de la BCM Pendant la journée d’échange, l'ATS tiendra l’enregistrement des soldes de chaque compte de règlement, tout en étant interfacé au système comptable de la BCM en tant qu’agent de règlement en Ouguiya Mauritanienne et chez l’agent de règlement pour les autres devises, de manière que les transactions sur les comptes de règlement dans l’ATS soient impactées aussi dans le livre de la BCM et vice versa. A la fin de la journée, toutes les transactions qui ont été effectuées dans l’ATS durant la journée seront imputées en comptabilité BCM pour une réconciliation complète entre l’ATS et le Grand Livre de la BCM, assurant ainsi l’intégrité complète des processus comptables de la BCM. Les soumissionnaires devront fournir des recommandations détaillées sur la façon d’établir un lien entre l’ATS et le système bancaire/comptable de la BCM de manière à assurer la synchronisation entre les deux systèmes. 6.4.2. Sources de liquidité Les sources de liquidité dans le compte de règlement peuvent être : 1. Comptes des correspondants ; 2. Ordres de transferts entrants ; 3. Emprunts auprès d'autres banques ; 4. Facilités de crédit auprès de la BCM. 6.4.3. Liquidité Intra-journalière Au cours de la journée un participant peut solliciter l’obtention de liquidité intra journalière à la BCM. Cette liquidité pourra lui être accordée sous réserve de l’existence des garanties appropriées couvrant le montant requis, disponible comme collatéral par le biais d’un accord de rachat (pension) ou peut être d’une mise en gage. Les offres doivent contenir tous les détails des options pour y parvenir. L’octroi des facilités des crédits intra journaliers aux banques par la BCM et le transfert des titres à la BCM en garantie de ces facilités doivent être réalisés de manière automatique (sous réserve des commandes manuelles par les opérateurs système autorisés de la BCM) et simultanément à travers l’exécution des transactions nécessaires à la fois de l’ATS et des composants CSD. 6.4.4. Octroi de crédit par la BCM Le système devrait avoir des mécanismes flexibles permettant à la BCM d’octroyer des crédits, intra journalier et/ou over night, aux participants. Par exemple la BCM pourrait imposer des plafonds aux banques, ou de limiter le nombre de jours consécutifs de ce crédit over night ou le nombre de jours de ce crédit par mois. En cas de dépassement de ces limites, le système doit être en mesure de notifier automatiquement l’organe de la BCM en charge de la surveillance. 6.4.5. Réservation des fonds dans les comptes de règlement La BCM ou le participant devrait pouvoir temporairement réserver ou affecter une partie de ses avoirs en compte de règlement pour réaliser certaines transactions comme par exemple l'achat de devises auprès de la BCM ou à des fins de règlement des positions nettes d'ACH. Dans ce cas les fonds affectés ne peuvent être utilisés aux fins de régler d’autres transactions ATS. Il devrait être possible de définir une telle affectation à une date donnée. Par exemple les opérations d’achat de devises par les banques interviennent quelques jours après la conclusion de l’opération. Dans ce cas, les avoirs ainsi affectés doivent être mis de coté 6.4.6. Limites de crédit Le système devrait offrir la possibilité de fixer des limites de crédit tant bilatérales que multilatérales, pour limiter les expositions des participants. 6.4.7. Problèmes de Liquidité Le système devrait être en mesure de notifier la BCM et les participants affectés au sujet de tous les problèmes de liquidité. Le système devrait être en mesure de surveiller et de générer des alertes dans les cas suivants : 1. un solde de compte est en-dessous du niveau minimum ; 2. Un ordre de paiement est supérieur au montant disponible sur le compte de règlement ; Les paiements rejetés pour insuffisance des fonds devront être signalés au participant qui les a initiés Les offres devront préciser tous les cas qui pourraient faire l’objet d’une surveillance. 6.5. EMISSION ET RECYCLAGE DE LA MONNAIE En tant qu’institut d’émission, la BCM a pour mission notamment d’émettre de la monnaie. A ce jour toutes les procédures liées à l’émission et au recyclage de la monnaie sont manuelles ; les soumissionnaires sont invités à décrire la manière dont leurs systèmes vont améliorer les processus d’émission et de recyclage de la monnaie pour fournir une solution à moindre risque et avec une intervention manuelle limitée. 6.6. GESTION DES TRANSACTIONS DU GOUVERNEMENT 6.6.1. Département de trésor du ministère des finances Le trésor public ordonne tout paiement par l’envoi d’un ordre de paiement informatisé (OPI). La banque centrale, après vérification, procède au paiement des ordres soit à ses guichets, soit par leur domiciliation au niveau des banques commerciales, soit encore auprès de ses correspondants à l’étranger, via le réseau SWIFT. La domiciliation est utilisée également dans le paiement de salaires des fonctionnaires et de soldes des militaires qui s’effectue actuellement essentiellement par virement bancaire. Les fournisseurs doivent fournir des détails de la façon dont leurs solutions peuvent automatiser le processus de paiements du gouvernement afin de réaliser, dans la mesure du possible, la réception, la compensation et le règlement automatiques de tous les paiements du gouvernement. 6.6.2. Administration fiscale Le paiement des impôts par les contribuables s’effectue suivant la procédure ci-dessous : - le contribuable présente auprès de la banque commerciale la Note de perception ou le Récépissé de la Régie financière afin de verser les fonds au profit de la Régie concernée ayant un compte dans la dite banque commerciale ; - la BCM s'occupe, de la comptabilisation des encaissements au crédit du compte du Trésor. La BCM est en aval de la chaîne de la dépense ; Les fournisseurs devront fournir des détails de la façon dont le paiement des impôts peut être supportés et être effectué plus efficacement par leur solution 6.7. INTERFAÇAGES AVEC LES SYSTEMES DES BANQUES 6.7.1. Messages Au minimum, le système doit supporter le format standard SWIFT FIN pour tous les messages. La préférence de la BCM est que le système emploie les formats d'ISO 20022 (UNIFI) pour tous les messages, RTGS et de petits montants (ACH).Les soumissionnaires doivent fournir des informations sur toutes les normes que leurs systèmes supportent, en particulier leur plan de développement dans ce domaine. 6.7.2. Équipement Terminal des Participants Pour les paiements uniques, l’accès doit se faire depuis un PC dédié, pour des petites institutions ou de n’importe quel nombre de postes de travail et utilisateurs autorisés sur le LAN dans le cas de participants importants. Il ne devrait pas y avoir de serveur ni base de données dans le data center des participants 6.7.3. Intégration avec les systèmes bancaires des participants Le système doit fournir les Connexions standard pour permettre le traitement automatisé de bout en bout (STP) pour tous les types de paiement. Ceci exigera des participants de mener à bien les travaux nécessaires pour intégrer leurs systèmes bancaires à l'ATS. Le fournisseur retenu de l'ATS devrait travailler avec les banques commerciales afin de les aider dans cette tâche, pour fournir les spécifications complètes d’interfaçage avec STP à aucune charge, et pour fournir tout appui technique et conseils nécessaires pendant le processus de mise en œuvre. 6.7.4. Autres interfaces Selon les fonctionnalités et les équipements décrits ci-dessus, le noyau du système ATS doit pouvoir se connecter par interface aux composants externes suivants : • L'application comptable de la Banque Centrale pour télécharger les soldes d'ouverture de journée des comptes du règlement des participants au début de la journée d'échange, et pour télécharger les détails d'opérations et les soldes de fermeture de journée en fin de journée, • L’intégration Régional • Gimtel – Le Switch Monétique Interbancaire • L’application bancaire (CBS) de la BCM pour ce qui concerne la tenue des comptes de règlement, • D'autres systèmes nets : pour le règlement des résultats nets de compensation des transactions monétiques ou de compensation des opérations sur valeurs mobilières, • Les applications principales pour le règlement des opérations métiers de la banque centrale (les besoins peuvent apparaître au moment de l'élaboration des spécifications fonctionnelles détaillées), • Les terminaux Swift Alliance Access de la Banque Centrale et de leur backup ; on s'attend à ce que la solution du fournisseur inclue des adaptateurs à l'interface de MQSA selon les spécifications Swift et le middleware MQSeries.. Quant à la plateforme du participant, on s'attend à ce que la solution du fournisseur propose des interfaces à Swift Alliance Access avec MQSA et interface AFT. Si la solution du fournisseur inclut des interfaces additionnelles en standard, le fournisseur est invité à les détailler. Le fournisseur fournira une description fonctionnelle et technique détaillée de chacune des interfaces proposées. 6.8. CONTROLE ET REPORTING Le système doit fournir un ensemble complet et flexible de contrôle, reporting, et d’analyse, pour mettre à chaque participant d’avoir un maximum d’informations, et de contrôler sa participation dans le système (de la même manière que les utilisateurs des services bancaires en ligne contrôlent toutes les activités de leurs différents comptes via la connexion Internet). Les fonctionnalités de contrôle, de reporting et d'analyse doivent couvrir : 1. le rapport de contrôle intra-journalier ; 2. le rapport de fin de journée ; 3. Le rapport sur l’historique d’'activité du système. Dans le cas des participants autres que la BCM, ces fonctionnalités doivent être strictement restreintes à leur propre participation dans le système, alors que la BCM doit être en mesure d’obtenir toutes les informations sur le fonctionnement du système dans son ensemble. Le contrôle des facilités intra-journalières doivent être disponibles sur demande, alors que les rapports de fin de journée doivent être fournis automatiquement aux utilisateurs désignés au sein de la BCM et des banques participantes. Les facilités (fonctionnalités) d’analyse de l’historique doivent fournir une large gamme de possibilités y compris des fonctionnalités flexibles d’interroger la base de données ainsi que la capacité de télécharger des fichiers extraits depuis la base de données d’archive pour plus d’analyse en utilis ant les outils tels que les package d’analyse statistique ou des feuilles de calcul. Cette fonctionnalité devra être disponible pour les participants autres que la banque centrale uniquement par le biais des demandes adressées à la direction du système de paiement de la BCM. La base de données archive doit être tenue séparée de la base de données en ligne (du jour courant), pour des raisons de performance et de sécurité. La BCM conviendra avec le soumissionnaire retenu de la durée de stockage en ligne des données (par opposition à l'archivage hors ligne) pendant l’implémentation du système. 6.8.1. L'information Intra-journalière en ligne pour la BCM Le système devrait fournir au moins les informations suivantes aux utilisateurs métiers de la BCM, aux directions autorisées et aux auditeurs de la BCM : 1. Statut des messages individuels et du fichier d’entrée par lot ; 2. toute l’activité quotidienne, hebdomadaire, mensuelle et annuelle (pour chaque participant émetteur et bénéficiaire) ; 3. rapport des éventuels messages dupliqués ; 4. Toutes les informations sur le solde net des comptes par participant ; 5. Requêtes sur les instructions de paiement dans le système (sur base des différents critères de sélection) ; 6. Alertes quand les files d'attente s'accumulent au-delà des limites définies en terme de nombre d’ordres de paiements ou de montants à payer. De telles limites seront définies par la BCM ; 7. Synthèse des rapports de sécurité pour ce qui concerne les tentatives d’accès échouées, les messages non valables (avec le motif du rejet) ; 8. Un affichage graphique montrant le statut des files d'attente des ordres de paiement, et indiquant les zones de congestion etc. Un tel affichage serait incorporé au tableau de bord. 6.8.2. L'information Intra-journalière en ligne pour les participants Les points suivants s'appliquent aux participants : 1. Les participants recevront un message immédiat pour tous les paiements effectués ou reçus par eux ; 2. En cas de rupture de service au niveau d’un participant, la BCM doit être en mesure d’informer tous les participants de cette situation et de la prolongation possible de la journée d’échange résultant de cette situation ; 3. Chaque participant doit être en mesure de retracer toute transaction individuelle ou appartenant à un lot à toutes les étapes du traitement ; 4. Les participants doivent être en mesure de s'enquérir du statut de leurs files d'attente de paiement tout au long de la journée aussi bien que le solde courant de leurs comptes de règlement respectifs. Le système doit fournir au moins les informations suivantes aux participants : a. requête d’accès au solde du compte de règlement du participant ; b. requête d’accès aux instructions de paiement du participant dans le système (tenant compte de différents critères de sélection) ; c. Notification du statut des instructions de paiement envoyées/reçues débitées/créditées, si elles ont été traitées avec succès ou rejetées ; d. Description d'erreur de validation ; e. Requête d’accès à leurs propres files d'attente des transactions sortantes ; f. Requête sur le calcul des soldes moyens intra-journaliers ; g. toutes les transactions effectuées ainsi que les charges y afférentes ; h. En plus du flux d'information en ligne pendant la journée de traitement, chaque participant recevra un fichier électronique contenant l'information suffisamment détaillée pour prendre en charge la réconciliation automatisée des opérations ayant affecté son compte de règlement avec les opérations qu’il a initiées à partir de son propre système. Cette information peut être envoyée tout au long de la journée en réponse aux demandes du participant ; i. Un rapport complet, quotidien sera envoyé à chaque participant comme élément du traitement de fin de journée. 6.9. GESTION ET SUIVI DU COMPTE 6.9.1. Ouverture et fermeture de compte La BCM sera autorisée à ouvrir, clôturer ou suspendre tout compte tenu dans le système. Si un compte est suspendu, aucune transaction sortante de paiement ne peut être faite, mais le système doit permettre à la BCM soit d’enregistrer les paiements entrants ou les rejeter. 6.9.2. Gestion des limites des avances Intra-journalières La BCM aura la charge d’organiser et de gérer toute les modalités concernant l'octroi de crédit intra - journalier. 6.9.3. Suivi de compte par la BCM Pour la gestion de système, la BCM aura accès à toute l'information sur tous les comptes de règlement des participants. Le système doit disposer d’un outil complet pour afficher l'information en ligne sur la situation globale de liquidité du système, en continu tout au long de la journée d’échange ou en instantané pour la période courante et en comparaison à la période antérieure (heures, jours, et semaines), grâce à des fonctionnalités de tableau de bord décrites dans 4.8.2. 6.9.4. Historiques De Compte De Règlement Le système devrait maintenir les enregistrements en ligne des transactions de compte de règlement pour le mois en cours et les archives des données historiques pour la période d’archivage légal (dix ans). Le système devrait fournir une gamme des fonctionnalités graphiques pour permettre le suivi de la liquidité du système ; par exemple, affichage graphique du nombre de paiements en file d’attente par banque et les indicateurs courants de performance. 6.10. CONNEXIONS AUX SYSTEMES EXTERNES L'ATS aura un certain nombre de Connexions aux systèmes externes. Figure 1. : Architecture de l’ATS Le système RTGS est connecté à toutes les plateformes des banques participantes au système d’information de la Banque Centrale. Deux infrastructures de télécommunication séparées pour le transport des instructions, les messages de notification et les requêtes sont envisagés : l'utilisation du réseau SWIFT et l'utilisation d'un réseau interbancaire privé(Gimtel). Une option pourrait consister à ce que le système passe en production en utilisant Gimtel comme réseau principal et le réseau SWIFT comme réseau de secours. 6.10.1. Connexion au Système comptable de la BCM C'est une Connexion critique (prioritaire) qui sera employée pour une variété d’usages. L'ATS doit fonctionner comme un système de miroir du système comptable, pour faciliter des transactions sur les comptes de règlement tout au long de la journée. L’interface au système comptable sera également employée pour soumettre les paiements à l'ATS par la BCM, pour son propre compte et pour le compte du gouvernement. 6.10.2. Connexion aux Systèmes d’informations des banques (participants) Le système doit fournir des connexions standard pour permettre le traitement de bout en bout (STP) de tous les types de paiement entre l'ATS et les systèmes bancaires des participants. Ceci exigera naturellement des participants de mener à bien les travaux nécessaires sur leurs systèmes pour mettre en place ces connexions avec l'ATS. Le soumissionnaire retenu de l'ATS devra travailler avec les banques commerciales pour les aider à atteindre cet objectif et fournir toutes les spécifications pour l'interfaçage sans charge additionnelle pour l’implémentation du STP. Il est également attendu du soumissionnaire retenu la fourniture d’un appui technique et les conseils nécessaires pendant le processus d’implémentation. 6.10.3. Connexion aux systèmes du Gouvernement Il est prévu que les paiements du Gouvernement soient soumis au système par les liens électroniques entre le ministère des finances et la BCM. Ainsi le trésor sera un participant direct à l’ATS. Les interfaces seront requises entre l’ATS et le système installé à la direction du trésor, à l’administration fiscale (Douanes) pour des besoins de reporting des paiements effectués. Des détails spécifiques des fonctionnalités et des interfaces exigées seront développés par le soumissionnaire retenue en collaboration avec la BCM et l’administration fiscale. 6.10.4. Connexion au switch monétique national Cette Connexion a pour objectif de régler les soldes nets des transactions monétiques interbancaires. 6.10.5. Connexion aux systèmes d’échange Futurs Celle-ci pourra concerner le marché monétaire interbancaire et/ou de marché de change (forex), la bourse des valeurs mobilières. 6.11. VOLUMES ET PERFORMANCE 6.11.1. Volumes et performance Les statistiques sur les volumes actuels d'utilisation des instruments sont indiquées dans la section 2. Cependant on s'attend à un accroissement significatif du volume de paiements interbancaires, en particulier ceux du gouvernement, au cours des cinq (5) prochaines années. Les offres doivent contenir des données de référence (benchmark) pour indiquer le volume de différents types de transactions que la solution proposée peut traiter par minute ou heure , sur base de la configuration de matériel proposé. Cette information doit également indiquer toutes les contraintes et possibilités de croissance disponibles. 7. EXIGENCES FONCTIONNELLES POUR LE DEPOSITAIRE CENTRAL DES TITRES (DCT OU CSD) L’objectif principal du dépositaire central des titres (DCT) sera de permettre l’enregistrement précis des transactions concernant les titres de la banque centrale et du gouvernement sur les marchés des capitaux. À cette fin il doit contenir des fonctionnalités de dépositaire et de marché primaire (enchère/adjudication). 7.1. OBJECTIFS Les objectifs principaux du DCT sont : 1. la prise en charge de la comptabilité et gestion automatique de transferts sécurisés de titres entre : - Les clients de participants, - Les participants, - Les participants et la Banque Centrale, - Les comptes de participants 2. la fourniture d’un registre électronique centralisé en ligne pour tous les titres du gouvernement et de la banque centrale (ainsi que les futurs autres émetteurs potentiels) qui doivent satisfaire les besoins de toutes les émissions, les émetteurs, des souscripteurs, des gestionnaires et de toutes mes autres parties intéressées ; 3. l’Amélioration de l'efficacité et la sécurité du système par le traitement sur base du principe de livraison contre le paiement (Delivery versus Payment, DvP) et de traitement de bout en bout (Straight-Through Processing, STP), à travers la connexion avec le système de règlement brut en temps réel (RTGS) de la banque centrale; 4. la gestion du cycle de vie des titres d’état; 5. la prise en charge de la gestion de liquidité intra-journalière ainsi que les autres opérations de la politique monétaire de la banque centrale ; 6. la prise en charge de la gestion du portefeuille par instrument et par maturité ; 7. la facilitation du processus de traitement y compris le remboursement, le paiement des intérêts et des impôts; 8. la facilitation du traitement électronique des prises en pension (repurchase agreement) ; 9. La fourniture des facilités en ligne de requêtes à toutes les parties autorisées. 7.2. CARACTERISTIQUES FONCTIONNELLES Le DCT doit fournir les fonctions minimales suivantes : 1. Maintenir un registre de tous les titres émis par le gouvernement et la banque centrale, par volume, par taux d'intérêt, par maturité, par souscripteur, par prix ainsi que toute autre information pertinente ; 2. Maintenir un registre pour les différentes contreparties (les courtiers et les souscripteurs de titres), en détaillant si le déposant est direct ou indirect, et toute autre information pertinente comme : nom, adresse physique, adresse email, téléphone, numéro d'impôts, etc. Toutes les contreparties doivent être identifiées suivant les codes à même de faciliter la recherche d'une telle information ; 3. Avoir une application de règlement étroitement liée avec le système de RTGS, pour le règlement des opérations de marchés primaire et secondaire, opérations d’open market et les opérations de gestion de liquidité intra-journalières de la banque centrale, afin de garantir que les principes de livraison contre paiement DvP et de traitement de bout en bout STP sont respectés. Cette application de règlement doit également servir comme facilité pour permettre de régler les intérêts et gérer les maturités sur les titres de créance, et à l'avenir pour gérer les titres émis par les sociétés ; 4. Incorporer les fonctionnalités de marché primaire pour gérer les émissions de tous les autres titres ; 5. Contenir des fonctionnalités pour faciliter la gestion de portefeuille titre de la banque centrale, pour son propre compte, et pour le compte des autres participants ; 6. Être capable de supporter une connexion à tout autre futur système électronique interbancaire de négociation de prêts-emprunts garantis par les collatéraux; 7. Être capable de supporter une connexion au système électronique de négociation des titres gérées par la bourse des valeurs mobilières, s'il y a lieu à l'avenir, en respectant les principes de livraison contre paiement DvP et de traitement de bout en bout STP pour le règlement des transactions ; 8. Se conformer aux formats de message ISO 15022 ou 20022 dans la conformité avec les normes internationales minimum pour des messages générés ; 9. Fournir une vue unique et intégrée de la position de chaque courtier pour de besoin de suivi, de surveillance, et de contrôle de leur liquidité ; 10. Produire des rapports de synthèse et détaillés avec la possibilité de visualisation en ligne avant l'impression et le téléchargement à partir des applications externes ; 11. Permettre l’envoi des requêtes par la banque centrale et le ministère des finances. 7.3. LA LIVRAISON CONTRE PAIEMENT (DELIVERY VERSUS PAYMENT, (DVP)) Le système doit supporter les modèles 1 et 2 de livraison contre paiement (DvP) comme définis dans le document de la BRI :"principes pour les infrastructures de marché financier ". Le DCT doit fournir une interface automatisée et efficace avec le système RTGS de Banque Centrale pour permettre les changements de propriétaires de titres auprès du dépositaire qui doivent s’exécuter simultanément avec les imputations des montants correspondants dans le système RTGS afin de respecter le principe de livraison contre paiement (DvP). Le transfert de propriété ne peut pas se produire tant qu'un message de confirmation de paiement n’est pas reçu du système RTGS. 7.4. GENERALITES La Banque Centrale veut s'assurer que la composante DCT fournit un outil de pointe et des fonctionnalités haut de gamme au gouvernement et aux marchés financiers du pays. Le DCT doit donc contenir un ensemble complet de fonctionnalités pour atteindre les objectifs et les caractéristiques décrits ci-dessus. Les soumissionnaires doivent fournir les détails complets des fonctionnalités offertes par leurs solutions proposées. 7.4.1. Rôles Le DCT doit fournir un support pour les différents et multiples rôles des divers participants comme : - Conservateur ; - Courtier ; - Émetteur ; - Gestionnaire ; - Régulateur/Superviseur ; - propriétaire ; - détenteur. Le DCT doit en plus supporter différents types de catégories d'Usager/négociant comprenant, pour les négociants en titre : - négociants agissant pour compte propre; - négociants agissant pour compte de la clientèle; - Les activités menées par les négociants doivent être enregistrées suivant le "type de registre de négoce". Chaque négociant doit pouvoir agir dans les deux sens. - La capacité de gérer les titres à taux fixe et à taux variable selon les algorithmes déterminés par les émetteurs/autorités de régulation. 7.4.2. Exercice De Droit Le DCT doit automatiquement générer les droits à créditer aux propriétaires/détenteurs de l'instrument enregistré à la date d’échéance. Les intérêts dus doivent être réconciliés avec le portefeuille original des titres émis et transmis au système RTGS pour le paiement au bénéficiaire/ propriétaire par imputation au compte de règlement de l'intermédiaire ou de la banque commerciale du bénéficiaire. 7.4.3. Fiscalité Le module de traitement des droits doit calculer les impôts dûs sur les intérêts et dividendes rattachés aux titres (en s'assurant qu'aucun impôt n'est perçu sur les souscripteurs/détenteurs exonérés d’impôts), déduire l'impôt à payer avant le paiement des droits au bénéficiaire, et transférer ces informations sur tous les impôts déduits au système RTGS pour : i. l’imputation au compte du gouvernement du total de taxes collectées ; et ii. les détails de différentes taxes perçues individuellement comprenant le montant, l’identité du contribuable, etc., pour être communiqués à l'administration fiscale pour la mise à jour du système fiscal des contribuables. Les taux d'imposition pouvant être modifiés par le gouvernement à tout moment, ceci doit être facilement mis à jour dans le système par le personnel autorisé de la Banque Centrale. 7.4.4. Réouverture de souscriptions pour l’émission de titres Il doit être possible que l’émission d'obligations soit rouverte pour plus de souscriptions jusqu'à ce qu'un certain volume prédéterminé soit atteint. Pour ce genre de réouverture d’émission, le DCT doit mettre à jour toutes les données appropriées d'identification de l’émission et les synthèses correspondantes, incluant notamment le nombre additionnel des titres émis lors de la réouverture d’émission. Les titres à taux fixe et à taux variables doivent être gérés selon les algorithmes déterminés par les émetteurs/autorités de régulation. 7.4.5. Gestion de portefeuille Le DCT doit contenir une gamme complète des fonctionnalités standards de gestion et de contrôle de portefeuille pour permettre à la Banque Centrale de définir et gérer son propre portefeuille des actifs financiers. Ceux-ci incluront : - Une fonction d'évaluation (marché -à-marché) ; - Le calcul quotidien des intérêts échus (gains et pertes sur le portefeuille-titres) avec la génération automatique des écritures comptables pour enregistrement au système comptable de la Banque Centrale. 7.4.6. Opérations de prise en Pension (repurchase agreement) Le DCT doit avoir la capacité de gérer les opérations de prise en pension (repurchase) (y compris la capacité de gérer plusieurs titres dans une seule prise en pension) en enregistrant le changement de propriétaires et l’obligation de rachat à l’échéance convenue. L’échéance de l’opération de prise en pension ne peut aller au-delà de l’échéance du titre concerné 7.5. INFORMATIONS SUR LE PROPRIETAIRE BENEFICIAIRE ET LE DETENTEUR Les informations sur le propriétaire bénéficiaire sont les informations sur la propriété en titres. Un ensemble de titres peut appartenir à une personne ou une seule organisation, ou un certain nombre de personnes et/ou d'organisations. Un détenteur peut être un individu ou une organisation. Tous les détenteurs doivent être identifiés par un identifiant unique (UID). Le système doit pouvoir enregistrer les informations sur la propriété des titres. 7.5.1. Informations sur le propriétaire bénéficiaire Le DCT doit détenir les informations sur chaque propriétaire bénéficiaire de titres. Les informations sur le propriétaire bénéficiaire doivent inclure : 1. Un identifiant unique pour chaque propriétaire bénéficiaire. Dans le cas d'un seul détenteur ceci a peut-être l'identifiant unique (UID). Lorsqu’il y a plus d'un détenteur, les informations sur propriétaire bénéficiaire doivent identifier les détenteurs (voir le "enregistrement de propriétaire bénéficiaire ") ci-dessous ; 2. les indications si le propriétaire bénéficiaire est un détenteur unique ou un groupe de détenteurs ; 3. L’indication des entités autorisées à opérer des modifications d’informations sur le propriétaire bénéficiaire, autoriser la négociation des titres, ou si une telle action exige l’accord de tous les détenteurs; 4. Et éventuellement les instructions de paiements pour les paiements des droits. 7.5.2. Informations sur les détenteurs Les détenteurs doivent être identifiés individuellement dans le système. L’enregistrement du détenteur maintiendra les informations de base pour s'assurer que n'importe quel détenteur est enregistré une seule fois dans le système. Les courtiers sont appelés à actualiser ces informations, mais pourront détenir des informations supplémentaires dans leurs propres systèmes liés au système d’enregistrement de détenteurs dans le DCT. L’enregistrement de détenteur doit inclure : 1. Un identifiant unique (UID) qui est unique dans le système, et capable en utilisant une validation appropriée de routine; 2. les Champs normaux de contact tels que le prénom, le nom, l'adresse, le numéro de téléphone et l’adresse E-mail, dont chaque élément est repérable ; 3. L’adresse du domicile ; 4. Une indication si le détenteur est exonéré d'impôts. Les informations sur le détenteur doivent porter la mention « inactif » si aucun mouvement n’a été enregistré dans leur compte durant 12 mois. Le compte du détenteur peut être réactivé uniquement par une action explicite de la BCM. 7.5.3. Fonctionnalité de propriétaire bénéficiaire et du détenteur Les fonctionnalités suivantes doivent être disponibles : 1. Un courtier doit pouvoir avoir une vue des opérations des propriétaires bénéficiaires et détenteurs pour lesquels il est le conservateur; 2. Toute instruction de mouvement de titres doit inclure les références de propriétaire bénéficiaire et du détenteur; 3. Le système doit être capable de générer des messages destinés au propriétaire bénéficiaire et/ou du détenteur a à chaque opération sur titres ; 4. Les agents autorisés de la banque centrale doivent pouvoir dans le DCT voir toutes les détentions de titre par propriétaire bénéficiaire et par détenteur; 5. Il doit être facile d’identifier les doublons afin de réduire le risque qu’'un détenteur soit enregistrée plus d’une fois. ; 6. Le système doit avoir la capacité de générer les rapports tels que requis ; 7. Le système doit avoir la capacité de calculer et déduire des obligations fiscales comme indiqués dans le chapitre 6.4.3 en se basant sur les paramètres d’identification unique (UID). 7.5.4. Accès aux informations par le détenteur Le DCT doit avoir la capacité de générer des rapports sur demande des détenteurs. Le système doit avoir la capacité de facturer ce service aux détenteurs. 7.5.5. Accès aux informations par Internet Le DCT doit offrir au détenteur la facilité d’accéder à ses informations par Internet. L’accès au site web d’un propriétaire bénéficiaire et d’un détenteur doit être sécurisé. Après leur 'authentification, les utilisateurs doivent être en mesure de visualiser toutes leurs possessions indépendamment des courtiers. Les offres doivent contenir des détails de la façon dont ceci peut être atteint au regard des solutions proposées. 7.6. MODULE D’ADJUDICATION/ENCHERES SUR LE MARCHE PRIMAIRE Le DCT doit contenir un module intégré pour la gestion des titres du gouvernement et de la Banque Centrale sur le marché primaire. 7.6.1. Fonctionnalités Le module d’adjudication/enchères sur le marché primaire doit inclure les fonctionnalités suivantes : 1. L'acceptation des offres soumises électroniquement, pour chaque émission, par les participants distants (à travers des réseaux de télécommunications sécurisées), jusqu’à la date de clôture de ces offres. Les offres reçues ne doivent être visibles d’aucune partie au sein ou en dehors de la Banque Centrale jusqu’au moment de la clôture des offres. 2. La capacité pour la Banque Centrale de fixer les limites prudentielles pour chaque offre de soumissionnaire par rapport au montant total de l’émission. 3. La capacité d'inclure ou exclure des soumissionnaires de manière à limiter les négociants autorisés à soumissionner sur le marché primaire. 4. La capacité de calculer la fourchette des offres à retenir et à rejeter suivant les prix les plus élevés offerts, la valeur totale de l’émission et la composition des offres retenues. 5. La capacité de préparer, produire et transmettre automatiquement les avis des offres retenues et rejetées, les avis de paiement et les reçus. 6. La capacité de maintenir un registre de toutes les allocations pour des besoins de reporting. Ceci peut être conservé dans le DCT tout comme les informations sur l’émission totale. 7. La fixation automatique de l’heure limite de soumission. La BCM doit être en mesure de fixer cette heure sur l’écran pour chaque émission. 8. La capacité de déterminer les adjudications à taux (prix) unique ou multiple. 9. Le système de négociation des titres doit être capable de calculer les allocations des soumissions retenues en tenant compte des prix proposés, des limites prudentielles ainsi que la part d’émissions spécialement réservées à certaines institutions. 10. La capacité d'imprimer les titres physiques pour les soumissionnaires qui en font la demande. 11. Le système doit fournir des rapports à la Banque Centrale et aux soumissionnaires à l’issue des adjudications en ce qui concerne : a. les avis aux courtiers sur toutes les composantes de l’émission, le montant, la valeur unitaire, le prix, etc.… Chaque avis doit inclure également la confirmation d'information sur le type et la nature de l’émission, les intérêts à payer, la date de maturité et les références sur les titres de ce courtier. b. les avis à la banque centrale et/ou au gouvernement sur la composition, le taux des titres alloués au soumissionnaire retenu le montant, la quantité, le taux, etc. Ceci doit inclure également le calcul et l'affichage de la courbe de rendement pour l’émission concernée. 7.6.2. Participants Les participants aux adjudications primaires sont : • La banque centrale et • Toutes les banques commerciales 7.7. CONNEXIONS A LA COMPOSANTE RTGS DU SYSTEME ATS Le DCT doit être étroitement connecté au système ATS, afin de fournir les possibilités suivantes : 1. le règlement des opérations sur titres effectuées de manière irrévocable comme décrit en 2 (3) ci-dessus ; et 2. l’octroi de liquidité intra-journalière garantie aux participants directs dans le système de RTGS si la Banque Centrale le permet. 8. EXIGENCES FONCTIONNELLES ET TECHNIQUE DU RESEAUX CENTRAL / INTERBANCAIRE (BCM) Le fournisseur devra réaliser la conception détaillée du réseau cible dans lequel les systèmes ATS et CSD devront s’intégrer. Cette conception sera formalisée dans un cahier de spécifications techniques détaillées qui comprendra en coutre le plan de déploiement du réseau. Pour cela il travaillera en collaboration étroite avec : • L’équipe projet réseau et Gimtel au niveau de la BCM. • Les équipes projet réseau et télécommunications au niveau des banques primaires et autres participants. La conception détaillée prendra en compte les caractéristiques propres de chacun des systèmes (ATS et CSD). Le cahier des spécifications techniques détaillées comprendra à minima : • Le plan d’adressage IP cible. • L’ensemble des schémas logiques et physiques, globaux et détaillés requis, au format Microsoft Visio. • Les principes et règles de routage. • Les définitions de l’ensemble des VLAN nécessaires. • Les principes et règles de filtrage, sécurisation. • Les règles de gestion de la qualité de service. • La justification de la mise en œuvre de protocoles / méthodes / technologies afin de répondre aux exigences de disponibilité et de performance, • Le plan de déploiement • Toutes autres informations utiles. La validation de ces documents par l’équipe projet conditionnera le démarrage des travaux de mise en œuvre puis le déploiement du réseau. 8.1. LES EQUIPEMENTS Le protocole TCP/IP V4 sera utilisé par l’ensemble des équipements des réseaux, les équipements actifs, firewalls et autres. Ces équipements seront de plus compatibles IPV6. Tous les équipements seront administrables, supporteront les VLAN (802.1q) et la mise en œuvre de la qualité de service (802.1p) ainsi que les mécanismes de contrôle d’accès au réseau (802.1x). Les firewalls seront certifiés Critères Communs EAL4+. Les prises d’alimentation électrique des équipements seront de type E/F (norme CEE 7/7). Le fournisseur fournira l’ensemble des équipements qu’il aura estimé nécessaires pour répondre aux besoins du point central (BCM) et les autres participants. L’ensemble des onduleurs fournis sera conforme à la norme EN50091. Les ports Ethernet seront compatibles 10/100/1000 baseT. Cette fourniture est forfaitaire et comprend notamment : • L’ensemble des câbles réseaux requis pour câbler les armoires. • L’ensemble des éléments de câblage associés (réglettes, patch, panneau de brassage depuis lequel le pré câblage des locaux sera connecté). • Les armoires 19’’/42U requises pour recevoir les équipements fournis (actifs, câblage) au niveau de la BCM • L’ensemble des équipements actifs. • Le ou les onduleurs intégrés dans les armoires et administrable(s) assurant 1 heure d’autonomie à l’ensemble des équipements fournis au niveau de la BCM. • L’ensemble des postes de travail requis. • Aucun équipement réseau, onduleur armoire n’est prévue pour équiper les sites des banques ainsi. 8.2. LE DEPLOIEMENT Le fournisseur aura la charge d’installer et de mettre en service l’ensemble des équipements livrés. Il sera également responsable de la mise en ordre de marche du réseau ainsi créé, il travaillera pour cela avec les opérateurs télécoms chargés de mettre en œuvre les moyens de télécommunication étant entendu que ces derniers seront responsables du bon fonctionnement des liens livrés. Il interviendra par conséquent au siège de la BCM et sur son site de secours où il sera en charge de bâtir le réseau interbancaire. Il interviendra également au niveau des sièges des banques commerciales (toutes situées à Nouakchott) afin de les assister dans la mise en service des équipements d’extrémité et réaliser les tests de bon fonctionnement. Les banques et autres participants fourniront les équipements, l’énergie et l’emplacement appropriés (armoire ou autre) pour pouvoir se connecter au réseau du système de paiement. Chaque installation de site donnera lieu à un rapport d’installation détaillé présentant les configurations en place, les difficultés rencontrées et les propositions d’améliorations. 8.3. SPECIFICATIONS TECHNIQUES Il est attendu du fournisseur qu’il bâtisse le réseau interbancaire. Pour cela il aura la charge de fournir tous les équipements réseau et de sécurité requis et de fournir les services d’intégration associés uniquement au niveau de la BCM. 8.3.1. Architecture Réseaux Cible L’architecture générale du système cible figure en page suivante. Ce schéma présente les principes de connexions des différents éléments. Il n’est pas exigé du soumissionnaire qu’il respecte en l’état ce schéma, ce sont les principes de redondances, de ségrégation et de routage sous-jacents qui doivent être respectés. La finalité de ce réseau est de donner à la BCM et aux banques l’accès au système ATS/CSD ainsi qu’au switch monétique. 8.3.2. Schéma Architecture cible Hébergeur monétique site 1 Hébergeur monétique site 2 Switch Gimtel Liaison E Switch Gimtel Liaison D Réseau Inst. non bancaires GINTEL Liaison D Banques Liaison D SwiftNet Liaison D Liaison C Part. Indirect Gouvernement Liaison D Liaison C SwiftNet Liaison F Liaison C Liaison C BCM Site 1 Liaison FO-A BCM Site 2 Liaison FO-B Service Interconn Interconn Service Système Bureau exion exion Bureau Système ATS/CSD SWIFT avec le avec le SWIFT ATS/CSD BCM LAN BCM LAN BCM BCM SwiftNet1 SwiftNet2 En pratique, la solution monétique et les centres d’hébergement associés ne seront pas mis en œuvre immédiatement. Le réseau à déployer sera donc celui décrit ci-après. Néanmoins il est demandé aux soumissionnaires de prévoir l’ensemble des équipements et des fonctionnements décrits pour l’architecture cible complète. Les schémas présentés ci-dessus (architecture cible) font apparaître : • Le site du siège de la BCM • Le site de secours de la BCM • Les deux sites d’hébergement monétique • Le site type d’une des 18 banques primaires et autres institutions financières • Le site type d’une des institutions non bancaires Les sites de secours sont des sites miroirs du siège, ils seront globalement équipés à l’identique. Au niveau du siège de la BCM, le schéma fait apparaître : • L’interconnexion avec le réseau de la BCM. • L’interconnexion avec le réseau dédié qui reçoit les équipements d’accès à Swift. • Les deux réseaux protégés à créer pour l’ATS et le CSD. • Les équipements actifs assurant l’interconnexion (représentés par des routeurs et des firewalls) des réseaux protégés avec les banques, le site de secours, les sites monétiques. Il est important de noter que l’extension future doit prendre en compte les contraintes de l’architecture cible. 8.4. BESOINS DETAILLES 8.4.1. Principes • La BCM disposera de deux sites d’hébergement situés à Nouakchott, un site principal et un site de secours (à déterminer). Ces sites recevront l’ATS et le CSD. • La description des besoins portent sur le site principal, le site de secours sera identique au principal. • Sur chaque site d’hébergement les composantes des systèmes (serveurs, postes) seront installées au sein de réseaux protégés (VLAN protégé par un firewall physique). • Le réseau d’ensemble permettra de maitriser toutes les communications entre les VLAN de manière paramétrable au sein d’un site ainsi qu’entre les sites, chaque VLAN sur chaque site pouvant être mis en communication, de manière maîtrisée à tout autre. • Le réseau d’ensemble supportera la gestion de la qualité de service. Celle-ci sera paramétrable par nature de flux, mais également par VLAN. • Les flux réseaux liés à l’utilisation des systèmes ATS et CSD passeront par les liaisons VPN C et les fibres optique A et B représentées sur le schéma ci-dessus. • L’accès au réseau Swift est en dehors du périmètre de ce marché. 8.5. AU NIVEAU DE LA BCM Besoins au niveau du réseau local de la BCM Le point de contact entre le Système d’Information de la BCM et les systèmes ATS et CSD se fera au niveau de l’interconnexion avec le réseau de la BCM (en vert sur le schéma). • Deux interfaces Ethernet sont à prévoir pour un fonctionnement redondant. Besoins au niveau de l’accès à la plateforme SWIFT Identique au point précédent. L’ensemble des équipements d’accès à Swift sera placé dans un réseau dédié, le point de contact avec ce réseau se fera au niveau de l’interconnexion avec le réseau Swift (également en vert sur le schéma). Deux interfaces Ethernet sont à prévoir pour un fonctionnement redondant. Seule une interface sera utilisée si le réseau du côté Swift ne supporte pas la redondance. 8.5.1. Au niveau des banques et autres participants Les équipements déployés au niveau de chaque participant sont paramétrés par le participant. Le fournisseur précisera les modalités et conditions de connexion des participants aux deux sites de la BCM (primaire et secondaire). Le fournisseur fournira cependant une assistance technique aux participants lors de leur raccordement initial au réseau. 8.5.2. Au niveau des interconnexions avec les liaisons WAN Il est prévu de : o Chiffrer en IPSec AES ou plus performant toutes les communications sur les liaisons WAN. o Maîtriser les communications intersites au travers de VLAN. o Mettre en œuvre de la gestion de la qualité de service. o Supporter les liaisons redondantes afin d’augmenter la disponibilité (Liaisons A et B). o Supporter les différentes technologies de liaisons, toutes les interfaces étant de type Ethernet. o Supporter des liaisons point-multipoints établies sur des VPN (cf. Liaison C) o D’être en mesure de connecter 20 banques et autres institutions financières, tout en conservant des possibilités d’en adjoindre. 8.6. L’ADMINISTRATION ET LA SUPERVISION L’ensemble des équipements livrés pour le système ATS/CSD doit être livré accompagné d’un minimum de deux stations d’administration et de supervision. Ces stations seront installées sur le site principal et le site de secours. Compte tenu des fortes contraintes de séparation des réseaux notamment des réseaux protégés, le soumissionnaire expliquera de manière détaillée comment il compte mettre en œuvre une solution d’administration et de supervision centralisée sans créer de brèche dans le système. Les stations d’administration embarqueront les logiciels et interfaces requises par les solutions d’administration propres aux fournisseurs des différents équipements. Les postes de travail fournis seront de type PC, récents, dotés d’un clavier de type français, d’un écran plat 23 pouces et de Windows10. La solution de supervision disposera des caractéristiques suivantes : • Elle permettra la supervision et la production de statistiques et d’alertes à partir de l’ensemble des équipements fournis dans ce lot quelque en soit le fabriquant. • Elle sera dotée de dispositif de détection d’intrusion. La justification du positionnement des sondes et de leur nombre et nature sera fournie dans l’offre. • Elle sera capable de superviser d’autres équipements réseaux notamment à l’aide de snmp version 3. • Elle fournira une représentation graphique temps réel de l’état du réseau et des équipements actifs le constituant avec possibilité d’afficher les caractéristiques détaillées des équipements par simple clic de souris. • Elle sera capable de générer des alertes (mail, édition, lancement application Windows) sur occurrence d’un événement défini au sein de listes paramétrables. • Elle fournira des rapports détaillés et synthétiques permettant de suivre le SLA des opérateurs télécom (latence, disponibilité, débit utile, saturation, temps réel de non disponibilité,…) sur des périodes paramétrables (semaine, mois, trimestre, année). 8.7 MATERIEL, LOGICIEL ET TELECOMMUNICATION La plaetforme ATS/CSD fonctionnera sur du matériel dédié à installer sur le site principal au siège de la BCM et dans un site de secours, comme suit : 1. Le système de production sera installé sur des serveurs aux deux emplacements. L'équipement à chaque emplacement devrait être suffisant pour faire fonctionner tout le système si l'autre site devient indisponible, mais en fonctionnement normal, la BCM souhaite que les systèmes des deux sites soient couplés de telle manière qu'une panne de n'importe quel serveur (par exemple) n'ait aucun effet sur le fonctionnement du système. Les offres doivent contenir des recommandations quant à la façon dont les deux sites seront équipés et couplés pour permettre le niveau le plus élevé de disponibilité. 2. Les offres doivent également contenir des détails de la façon dont des procédures appropriées de basculement seront développées et examinées pour tenir compte des situations des défaillances multiples ou d'indisponibilité complète d'un site. 3. Un système de test et de formation sera installé sur le site principal d'exploitation. Ceci sera utilisé pour tester les modifications du logiciel, la formation du personnel, etc. Les offres doivent donner tous les détails de tout matériel, logiciel système, middleware et de tous autres produits et équipements nécessaires pour exploiter le système. Tous les équipements doivent être compatibles avec l'infrastructure informatique existante de la BCM. Le soumissionnaire retenu devra fournir des assurances contractuelles que toute la configuration convenue (matériel, réseau et logiciel) supportera le système suivant les charges de travail prévues pendant au moins trois années après recette (réception). 8.7.1. Matériel Les soumissionnaires doivent indiquer les détails complets de tous les éléments de matériel recommandés pour déployer leur solution proposée. Ceux-ci doivent inclure les détails de n'importe quel matériel pouvant être installés par les participants. Tous les composants du système devront fonctionner sans besoin de mise à niveau pendant une période au moins de trois ans à partir de la réception définitive et le matériel devrait être dimensionné en conséquence. Les recommandations de matériel doivent inclure tous les services relatifs et doivent couvrir (si applicable) : Serveurs Les offres doivent indiquer en détail tous les composants de serveur recommandé, couvrant l'application, les données et tous les autres serveurs exigés (par exemple serveurs web ou de certificat), ainsi que tout équipement nécessaire pour la connexion à l’infrastructure informatique existante de la BCM, et toute les options du système d'exploitation. En rapport avec le modèle et la gamme des serveurs, le client a une préférence pour les serveurs IBM haut de gamme, dont est constitué son Datacenter et pour lesquels elle dispose d’une expertise Stockage De Données Les offres doivent indiquer en détail la capacité de l'équipement de stockage de données recommandé. Ceci devrait supporter le dimensionnement de l'information sur la capacité requise pour supporter toutes les copies des bases de données de système et n'importe quelles autres informations supplémentaires, basées sur les volumes actuels et de prévision donnés dans ce DAO. Les offres doivent tenir compte des données des cinq dernières années plus celles de l'année en cours pour être contenues dans la base de données en ligne et jusqu'à dix ans sur une base de données secondaire. Ces conditions seront discutées plus en détail avec le soumissionnaire retenu. Spécifié la baie de stockage de données Rack Space Les propositions doivent inclure toutes les informations nécessaires pour que la BCM comprenne l'impact du nouveau matériel sur le centre de données, y compris les informations physiques sur les serveurs et d'autres unités telles que les dimensions, les besoins en rack, la consommation d'énergie, etc… Le vendeur devra propose des racks pré-câblé et avec leur système de refroidissement et des dispositifs de contrôle de température. Postes de travail La BCM considère que le système utilisera les PCs existants en tant que postes de travail d'utilisateur d'application. Les soumissionnaires doivent indiquer des configurations minimales et optimales requises et devraient fournir (30) PCs additionnels et (20) scanners de haute capacité pour les utilisateurs de la BCM. Autres Matériels Les offres doivent inclure des détails de tout autre matériel requis par leur solution. 8.7.2. Logiciel Logiciel De Participant En plus du logiciel installé à la BCM, les soumissionnaires doivent indiquer en détail tous les produits logiciels (requis et facultatifs) qui pourraient être installés par chaque organisation participante, y compris des conditions pour le STP (Straight Through Processing). Logiciel système et Middleware (intermédiaire) En plus des systèmes d’exploitation des serveurs, les offres doivent clairement indiquer en détail tous les autres logiciels et middleware qui devront être installés pour faire fonctionner la plateforme. Logiciel De Base de données Les offres doivent décrire tous les produits du système de gestion de bases de données sur lesquels leur solution fonctionnera, aussi bien que la recommandation de leur préférence, et indiquer également la nature et le nombre de licences du système de gestion de bases de données qui seront requis. Les soumissionnaires doivent fournir une description de toutes les fonctionnalités spéciales du logiciel de gestion de base de données qui sont utilisées par leur application, par exemple la réplication automatique de base de données pour faciliter la haute disponibilité. Reporting Les offres doivent décrire les outils standards de génération de rapports de base de données qui peuvent être utilisés pour le développement rapide des rapports afin de satisfaire des besoins spécifiques. 8.7.3. Télécommunications Les soumissionnaires doivent définir en détail tous les besoins de communications pour leurs solutions, couvrant les deux sites de la BCM et tous les participants, y compris la performance, la sécurité, la fiabilité, les possibilités de secours, la bande passante et toute autre considération appropriée. 9. IMPLEMENTATION ET SUPPORT La BCM s'attend à la fourniture d’une qualité de service exceptionnelle du soumissionnaire retenu. Cette section définit les conditions de service qui doivent être satisfaites pour assurer l’implémentation réussie de tout le système. 9.1. NIVEAU DE CONSULTANCE METIER Du fait que la mise en œuvre de l'ATS est un nouveau domaine pour la MAURITANIE, la BCM entend bénéficier du soumissionnaire retenu d’un niveau élevé de conseil en matière de métier - en plus de l'appui technique - tout au long de la durée du projet, basé sur son expérience internationale dans l’implémentation des systèmes de paiement. Les soumissionnaires doivent donc donner des détails sur le support qu'ils fourniront dans ce domaine, non seulement dans la finalisation des caractéristiques fonctionnelles de l'ATS, mais aussi en couvrant les aspects tels que le développement des règles et des procédures opérationnelles, des régimes de tarification de système et tous les autres domaines où le fournisseur estime qu'il peut offrir des conseils sur les bonnes pratiques et d'éviter des pièges, conformément aux meilleures pratiques internationales. En particulier le soumissionnaire retenu devra fournir les modèles de documentation pour les règles de fonctionnement du système, des accords d’adhésions des participants, des modes opératoires et des politiques de tarification. Un poids significatif sera donné à cet aspect lors de l’évaluation des offres. 9.2. PLAN DE GESTION DU PROJET Les offres doivent contenir les plans détaillés du projet en montrant comment les soumissionnaires entendent mettre en œuvre tous les aspects liés au projet. Les plans de gestion du projet doivent prendre en compte notamment les points suivants : 1. L’Organisation et la gestion du projet (l'équipe du soumissionnaire retenu et ce qui est attendu de l’équipe de la BCM en termes de charge de travail) ; 2. Les Phases d'exécution du projet qui précisent les séquences, les activités et les livrables pour chaque phase ; 3. L’élaboration des procédures métiers, et des spécifications du système ; 4. Le Développement, la livraison et l’installation du système ; 5. L’Intégration du système ; 6. La Formation ; 7. La Documentation ; 8. La gestion des changements ; 9. L’installation et le test d'homologation ; 10. Les services de garantie et post-garantie ; 11. La planification des tâches et des ressources montrant la durée, la séquence, l'allocation des ressources nécessaires et la corrélation entre toutes les activités et ressources principales requises pour finaliser le contrat ; 12. Un programme détaillé de déploiement du personnel. Le plan de gestion du projet du soumissionnaire retenu (fournisseur) sera affiné et éventuellement mis à jour à l’issue des discussions et accord entre la BCM et le fournisseur au cours de la première phase de l'exécution du projet. Une fois accepté, cet accord deviendra le plan du projet convenu et servira de document formel de suivi de l’évolution du projet entre les directeurs de projet de la BCM et du fournisseur. 9.3. LE PERSONNEL DU SOUMISSIONNAIRE RETENU Les offres doivent décrire la structure, les compétences, les rôles et les responsabilités de l’équipe de projet proposée, y compris les CVs de tous les membres de l’équipe proposée. Pour assurer le transfert maximum de connaissance, l’équipe de projet du fournisseur devrait être structurée pour travailler avec des contreparties et avec celle de la BCM. Les offres doivent donc montrer les attentes du fournisseur sur la structure et la gestion de l'équipe de la BCM, ainsi que les rôles et les responsabilités de chaque membre. Un programme de déploiement détaillé du personnel doit être fourni pour montrer l'affectation planifiée des personnes/ jours de chaque membre d'équipe à chaque étape du projet, sur place dans les locaux du fournisseur et sur le site de la BCM. L’équipe du projet doit inclure les spécialistes clé et leurs remplaçants au moins dans les domaines suivants : 1. Direction de projet ; 2. Système RTGS ; 3. Système de compensation (ACH) ; 3. Système de Dépositaire Central Des Titres (CSD) ; 4. Intégration de systèmes ; 5. Technologies de l'information et de communications (IT) ; 6. Formation des utilisateurs finaux. Chaque spécialiste principal doit avoir au moins dix ans d'expérience éprouvée, dont au moins cinq ans dans son domaine au cours des cinq dernières années, et au moins trois ans d'expérience dans sa position actuelle. La BCM s’attend à ce que l’équipe de projet du soumissionnaire retenu, en particulier les spécialistes clé, demeurent dans leur affectation durant toute la durée du projet. En cas d’indisponibilité de ces personnes clé pour des raisons indépendantes du fournisseur, celui-ci doit désigner d’autres personnes ayant au moins l’expérience et la capacité équivalentes, sous réserve de l’approbation de la BCM. 9.4. GESTION DE PROJET Les paragraphes suivants décrivent les attentes de la BCM en ce qui concerne la gestion globale du projet. Les soumissionnaires sont invités à présenter leurs observations et à proposer toutes les variations ou modifications s’il y’a lieu. 9.4.1. Comité de pilotage Le comité de pilotage de la BCM a la charge et la responsabilité finale de tous les aspects du projet. Le comité de pilotage communiquera comme sollicité avec l’équipe de projet responsable du système national de paiements. Le Directeur de projet de la BCM agira en tant que secrétaire au comité de pilotage. Le comité de pilotage se réunira régulièrement pour approuver le compte rendu de la réunion précédente sur l’avancement du projet, pour passer en revue les progrès réalisés et approuver toutes les actions proposées par le directeur de projet. Les deux directeurs de projet (voir le prochain paragraphe) assisteront aux réunions du comité de pilotage. 9.4.2. Directeur de projet La BCM et le fournisseur désigneront chacun un directeur de projet qui aura la responsabilité générale de veiller à l’implémentation réussie et complète des obligations de leurs parties respectives au titre du contrat. À cette fin, les deux directeurs de projet travaillent en étroite collaboration pour le suivi de toutes les étapes du contrat. 9.4.3. Suivi de l’avancement du projet Durant l'implémentation du projet, le directeur de projet du fournisseur soumettra au directeur de projet de la BCM un rapport sur l'état d'avancement mensuel couvrant : 1. les Résultats accomplis pendant le mois précédent ; 2. Toutes les modifications intervenues sur plan du projet, les actions correctives à prendre, et les révisions proposées au plan du projet ; 3. Tous les incidents et problèmes rencontrés ou potentiels, et les actions envisagées pour leur résolution. Les deux directeurs de projet tiendront des réunions formelles sur l’état d’avancement du projet à une fréquence régulière à convenir, celle-ci ne peut être inférieure à un mois. Ces réunions auront pour objet d’évaluer le progrès réalisé à ce jour y compris les rapports mensuels du fournisseur sur l'état d'avancement du projet, s’accorder sur les actions à mener pour résoudre les problèmes rencontrés et mettre à jour le plan de projet si besoin. Les directeurs de projet inviteront d'autres membres de l’équipe de projet à participer aux réunions sur l’état d’avancement du projet si besoin. Des comptes rendus écrits de toutes les réunions et actions convenues seront élaborées par le directeur de projet de la BCM et distribuées à toutes les parties impliquées si nécessaire, y compris le comité de pilotage. 9.4.4. Réunions de Groupe d'Utilisateurs Un groupe d'utilisateurs sera établi, dont les membres comprendront les représentants de toutes les directions impliquées de la BCM, des banques participantes et d'autres établissements si nécessaire. Le directeur de projet de la BCM organisera des réunions régulières du groupe d'utilisateurs, au cours desquelles les deux directeurs de projet rendront compte de l’état d’avancement et consulteront sur tous les aspects du projet qui requièrent l’implication des utilisateurs. 9.5. RECEPTION DES SYSTEMES Tout le système ne sera pas validé tant que toutes les fonctionnalités aient été intégralement testées pour démontrer qu’elles fonctionnent correctement sur tous les sites, y compris auprès des participants. 9.5.1. Généralités Le processus d'installation et de test démontrera (pour tous les composants du système) : 1. La facilité d'installation et du démarrage du système ; 2. Le fonctionnement de la plateforme système ; 3. Le fonctionnement et gestion du système par un personnel non technique ; 4. Les Interfaces de communications automatisées fiables et efficaces ; 5. La fiabilité élevée et reprise rapide en cas de panne ; 6. Le fonctionnement efficace et correct de toutes les connexions du système ; 7. L'intégrité complète du traitement et des réponses précises à toutes les requêtes d'information sur le système ; 8. La capacité de prendre en charge les flux attendus et des pics de volumétrie ; 9. La fourniture d’une documentation claire et efficace ainsi que d’autres matériels de support ; 10. L’efficacité de l’encadrement et de la formation ; 11. L’efficacité des modalités organisationnelles pour un fonctionnement à grande échelle ; 12. L’organisation efficace du support ; 13. L’efficacité du reporting d’incidents, des procédures d’investigation et de résolution. 9.5.2. Organisation de la recette L’exécution effective du contrat sera appréciée à l’issue d’une série de tests de recette formels effectués sur tous les aspects de l'ATS et du CSD. Le paiement est subordonné à l’exécution avec succès des objectifs assignés. Les tests de recette devront confirmer que le fournisseur a répondu à chacune des exigences spécifiées et agréées dans le contrat et a livré tous les rapports et les documents requis ainsi que des systèmes opérationnels. Chaque étape des tests de recette sera entièrement documentée et signée par la BCM pour confirmer la recette de chaque élément. 1. Les premiers tests seront exécutés en utilisant le système installé à la BCM. Ces tests confirmeront le fonctionnement général de chaque élément du système dans son ensemble, ainsi que toutes les connexions au sein de la BCM, en particulier : i. l’interfaçage entre l'ATS et le dépositaire central de titres ; ii. l'interfaçage avec le système comptable de la BCM. 2. Les tests fonctionnels seront effectués à travers le système installé sur le site principal et celui de secours, et sur tous les systèmes et éléments déployés auprès des participants, y compris l’interfaçage avec leurs systèmes d’information. 3. Les tests opérationnels (également appelés pilotes) comporteront des tests de performance des systèmes pour confirmer la capacité des matériels et des logiciels (tels que dimensionnés par le fournisseur) à supporter la charge de travail maximale. Ils incluront la gamme complète des procédures de basculement indiquées par le fournisseur pour gérer les incidents sur l’un ou l’autre site. Ils incluront également des tests de connectivité avec les réseaux prévus, des vérifications des dispositifs de sécurité logique. 9.5.3. Description et exécution des tests de recette Les contenus de tous les tests de recette seront proposés par le fournisseur pour approbation. Le planning et la modification de ceux-ci si nécessaire seront confirmés par la BCM. Tous les tests de recette seront effectués par les équipes opérationnelles et techniques de la BCM et seront suivis et appuyés à chaque étape par le fournisseur. La BCM mettra en place un personnel et une équipe de gestion à la disposition du fournisseur afin qu’il participe activement au processus de test de recette ainsi qu’au programme de formation et du transfert de connaissance pour la prise en main du système. 9.5.4. Recette définitive Le directeur de projet de la BCM sera responsable de l'évaluation finale de tous les résultats de tests de recette. À la fin de chaque phase de test, le directeur de projet remettra au fournisseur un Procès-Verbal de recette si le fournisseur a exécuté toutes les obligations contractuelles ou une déclaration spécifiant les obligations non exécutées et qui doivent l’être avant que la recette ne soit validée. La recette définitive ne sera prononcée qu’après l'accomplissement réussi de tous les tests et une recette formelle de tous les livrables du projet. 9.5.5. Correction de défauts Le fournisseur sera responsable de la correction de tous les défauts trouvés pendant les tests d'homologation au moment opportun de sorte que le programme global du projet ne soit pas affecté. 9.6. PARAMETRAGE ET DEPLOIEMENT Outre le paramétrage complet de sa solution, le titulaire du marché en assurera le déploiement chez les participants et la BCM. Ces travaux seront réalisés en collaboration avec les équipes techniques de BCM au titre du transfert de connaissance que le titulaire du marché devra fournir. Le besoin à couvrir concerne les agences et directions provinciales de la BCM qui doivent disposer d’un accès au système. Dans le cas où cet accès s’effectue via une plateforme spécifique, il s’agit d’assister les équipes de la BCM pour le déploiement dans l’environnement Citrix car la BCM ne souhaite pas les installer dans les sites distants. 9.7. TRANSFERT DE CONNAISSANCE ET FORMATION 9.7.1. Transfert de Connaissance La BCM considère que la formation et le transfert de connaissance sont les facteurs les plus importants pour la réussite du projet. Un objectif important est plus de s’assurer du t ransfert effectif de la connaissance sur le système de paiement et la technologie correspondante, non seulement à la BCM mais en plus auprès de tous les participants. Ceci s’avère aussi critique puisque tous les participants devront prendre en charge le fonctionnement et la maintenance des nouveaux services et technologie y afférentes. Les soumissionnaires doivent décrire en détail comment ils comptent atteindre ce haut niveau de transfert de connaissance. 9.7.2. Formation Les offres doivent inclure des plans de formation pour chaque élément du système à fournir et pour le projet dans son ensemble, tous les modules de formations proposés, le nombre recommandé et (si applicable) les connaissances pré requises du personnel de chaque institution qui doit être formé, la durée de chaque module de formation et le nombre de formations pour chaque module proposé. Les plans de formation doivent spécifier tous les prérequis qui doivent être satisfaits avant le début de la formation. Ils doivent concerner non seulement la BCM mais également toutes les institutions impliquées, pour chaque composante du système. La formation doit inclure les modules spécifiques pour : 1. la gestion du personnel de la BCM et des participants ; 2. le personnel opérationnel et de supervision de la BCM et des participants; 3. Les auditeurs ; 4. La formation technique pour les équipes de développement et de test du système de la BCM et des institutions participantes ; 5. La formation technique pour l’équipe d’exploitation et de maintenance des systèmes de la BCM et des institutions participantes ; 6. La Formation dans la rédaction et dans l’exploitation des rapports; 7. Toute autre formation pertinente pour les utilisateurs. 9.8. DOCUMENTATIONS Les plans de gestion de projet proposés doivent contenir les spécifications détaillées de la documentation que le soumissionnaire doit fournir, indiquant pour chaque article : 1. sur quel support ou médias il sera fourni ; 2. si c'est un document standard ou s’il sera conçu en fonction des contextes spécifiques du système d’information de la BCM. La BCM s’attend à ce que la documentation fournie puisse inclure au moins ce qui suit : 1. la Documentation des produits, décrivant les différentes composantes du système qui concernent les spécifications (exigences) métiers et techniques du système à fournir ; 2. la Documentation pour les utilisateurs finaux, personnalisé selon le cas, comprenant les guides opérationnels, guide d’opérations et les manuels standards pour les utilisateurs. Une aide en ligne devra être fournie pour tous les modules des systèmes ; 3. la Documentation technique que la BCM devra utiliser pour le fonctionnement effectif et sécurisé de l’environnement de production. Celle-ci doit inclure une documentation finale des systèmes tel que déployés « As-Built » et la documentation de la conception finale qui inclut les options et les paramètres de configuration retenus ainsi que toutes les instructions et procédures de fonctionnement ; 4. la Documentation détaillée des processus opérationnels ; 5. le guide de référence technique relatif aux aspects de développement autour de la solution. 9.9. GARANTIE Le fournisseur devra offrir le support opérationnel pour tous les systèmes sur les sites principal et de secours pendant la période d’implémentation et pour une durée d’au moins un mois calendaire après la recette opérationnelle matérialisée par un procès-verbal. Après la recette opérationnelle, le fournisseur offrira le support pour l'ATS et le CSD sans frais pendant une période d'une année (la période de garantie du système). Après cette période, le support sera fourni conformément au contrat de service (Service Level Agreement, SLA). 9.10. SUPPORT CONTINU Pendant la phase d’installation et de test d’homologation du système, l’équipe support du fournisseur doit être à tout moment disponible en cas d’appel pendant des heures normales de travail à la BCM. Lors de la recette opérationnelle, le fournisseur établira un seul point de contact pour tous les problèmes liés au software et au support. Le point de contact sera disponible tout au long de la journée d’échange du système, qui sera convenue entre la BCM et le fournisseur pendant l’implémentation. Le support en dehors des heures de service sera également convenu au même moment. Les offres doivent inclure des détails sur la façon dont le fournisseur offrira le niveau de support continu exigé. 9.10.1. Helpdesk de la BCM Le fournisseur est appelé à assister la BCM dans la mise en œuvre du service helpdesk qui doit fournir assistance à tous les utilisateurs pendant la journée d’échange. Les offres doivent contenir les recommandations pour la mise en place et le fonctionnement du service helpdesk, incluant le niveau de formation des opérateurs, la formation additionnelle nécessaire, la documentation, les procédures opérationnelles, etc. 9.10.2. Mises à niveau Les fournisseurs doivent décrire leur méthodologie pour fournir et implémenter des mises à niveau du système pendant sa durée de vie, en s'assurant que toute formation est fournie sur la gestion des changements et des améliorations nécessaires, et que la continuité de service est assurée pendant les mises à niveau, les ajouts et les changements. 9.10.3. Gestion des incidents Les détails des problèmes rencontrés avec le fournisseur pendant le projet, pendant la période de garantie du système ou pendant la période du contrat de service doivent être enregistrés pour permettre à la BCM de réaliser un suivi. Un reporting régulier devrait être une fonctionnalité standard du système et devrait inclure : 1. Le nombre d’incidents de perturbation de service pour une période donnée, par source de perturbation et au global ; 2. le nombre d’incidents reportés mais qui n’ont pas affecté le bon fonctionnement du service ; 3. Le temps consacré pour restaurer le service après chaque incident ayant conduit à une interruption ; 4. Le temps moyen de récupération. Les soumissionnaires doivent également expliquer comment le personnel de la BCM peut monitorer régulièrement les incidents signalés. 9.10.4. Contrat de service La BCM s'attend à un niveau très élevé de fiabilité et de disponibilité de tous les systèmes. Comme précédemment indiqué, les systèmes fonctionneront sur le site nominal et de secours, afin d’assurer un niveau élevé de fiabilité et de disponibilité. La BCM compte signer une convention de service (SLA) avec le fournisseur pour assurer la continuité de fonctionnement du système. Pour ce contrat de service, la BCM s’attend à ce que : 1. Il n’y ait pas plus de trois pannes logicielles par année et pas plus d’une panne par mois. Une défaillance logicielle est définie comme un évènement où une composante de l’application ne répond pas aux instructions de l’opérateur et ne parvient pas à remplir sa fonction normale et nécessite d’être redémarrée manuellement ou ne parvient pas à redémarrer. Dans tous les cas, le temps de reprise d’une panne ne doit pas excéder 30 minutes. 2. Dans une situation de baisse de la performance du système (en mode dégradé), celle-ci ne doit pas retarder le traitement de fin de journée de plus de 30 minutes. Ce type d'incident ne peut pas se produire plus d’une fois par mois ou trois fois par an. 3. L'attente de la BCM sur la disponibilité générale des systèmes est de 99.95% (où la disponibilité signifie que les systèmes sont prêts à être utilisés par la BCM pour les objectifs prévus durant la période de validité de la garantie).Les fournisseurs sont priés de donner des détails sur la fiabilité et la disponibilité attendues pour les présentes configurations (matériel, logiciel etc.) de leur proposition. . Les offres doivent inclure le modèle de conventions de service qui prennent en considération les attentes susvisées de la BCM. 9.11. LA MAINTENANCE DES MATERIELS, PROGICIELS ET LOGICIELS Il est demandé au soumissionnaire d’inclure dans sa proposition les conditions d’une période de garantie des progiciels, logiciels et matériels pour deux (2) ans ainsi que des modèles de contrats de maintenance pour les progiciels, logiciels et matériels avec les conditions financières, techniques et de délai relatives aux maintenances sur une période d’exploitation de un (1) ou trois (3) ans à compter de la fin de la période de garantie1. 9.11.1. Maintenance des progiciels et logiciels Pendant la période de garantie qui commence à courir après la date de signature du PV de la recette définitive, le fournisseur doit fournir une option de redémarrage avec contournement du défaut constaté dans un délai de quatre (04) heures et de correction dans un délai de quarante-huit (48) heures. Au-delà de la période de garantie, il inclura un coût forfaitaire annuel permettant d’assurer une remise en fonctionnement opérationnel du système sous 12 heures maximum pour : ✓ Une période d’une année ✓ Une période de trois années La comparaison des coûts de maintenance sera effectuée sur la période de trois (3) ans. 9.11.2. Maintenance des matériels Le soumissionnaire doit présenter un projet de contrat de maintenance, l’engageant sur une période de 3 ans en faisant ressortir les éléments suivants : ✓ Coût estimatif de la main d’œuvre. ✓ Coût estimatif du support technique des progiciels. ✓ Coût estimatif des équipements. En particulier, doivent être précisés : 1 Les deux hypothèses un an et trois ans de maintenance doivent être chiffrées ✓ Le nombre d'agents (fournisseur et/ou sous-traitant) chargés de la maintenance, de l'assistance technique et leurs fonctions, ainsi que leur lieu de résidence. ✓ Evaluation du stock minimum de pièces de rechange que le soumissionnaire doit fournir pour les équipements proposés. ✓ Les outils (utilitaires) de diagnostics et de dépannage. ✓ Possibilité de diagnostic et de maintenance à distance. ✓ Les délais d'intervention contractuels acceptés par le soumissionnaire pour répondre à une demande d'intervention. ✓ Les garanties concernant les délais d'intervention. Le fournisseur et ses partenaires sont tenus d’expliquer aux personnels d’exploitation des systèmes ATS et DCT, en cas d’incident, la cause du dysfonctionnement et la solution apportée. La maintenance vise à assurer un fonctionnement continu (7 jours/7) pour lequel le soumissionnaire doit prendre et faire prendre à ses partenaires les dispositions nécessaires (hot line, interventions sur site, assurance du back up, etc.…). Les plages horaires d'intervention devront être précisées ainsi que les coûts correspondants. Le soumissionnaire fournira le certificat de dépôt auprès d'un tiers de confiance des sources de l'intégralité des logiciels fournis pour l'ensemble du système livré en production. 9.12. CALENDRIER L’ensemble des opérations et fournitures dans le Plan projet devra se dérouler sur 14 mois maximum. Le Soumissionnaire devra fournir un plan de mise en œuvre détaillé des systèmes ATS et CSD avec l’ensemble des composantes (systèmes centraux, plateformes d’administration, plateformes participant, postes de numérisation de la banque centrale) cohérent avec les objectifs. Calendrier indicatif: Etape Conditions d’exécution Mois Lancement / cadrage / Plan projet 0 Spécifications 1 Personnalisations des progiciels Spécifications validées 3 Recette fonctionnelle Système livré 5 Recette d'intégration mise à niveau du SI de la BCM finalisée, 7 Formation BCM et participants 7 Tests pilote ATS et CSD Banques commerciales prêtes 8 Déploiement et Démarrage ATS et CSD Conditions de démarrage satisfaites 12 10. REGLES DE PRESENTATION DES OFFRES TECHNIQUES 10.1. DESCRIPTION DES TECHNOLOGIES DE L’INFORMATION, DOCUMENTS ET AUTRES PRODUITS ET SERVICES 10.1.0. Le Soumissionnaire doit fournir des descriptions détaillées de toutes les caractéristiques essentielles (paramètres techniques, performances et autres) de l’ensemble des Technologies de l’information, Documents et autres Produits et Services clés figurant dans l’offre (par exemple, numéros de version, de révision et de modèle). S’il ne fournit pas suffisamment d’informations précises, il risque de voir son offre déclarée non conforme. 10.1.1. Pour faciliter l’évaluation des offres, il convient d’organiser cette partie descriptive (y compris en ce qui concerne les renvois) de la même manière que le commentaire point par point du Soumissionnaire sur les Spécifications techniques dont il est question à la Section 9.3 ci-après. Tous les renvois doivent au minimum indiquer clairement les titres et numéros de page correspondants. 10.1.2. [ préciser : toutes autres informations techniques relatives aux Technologies de l’information, Documents et autres Produits et Services nécessaires à l’évaluation de la conformité de l’Offre technique (par exemple, antécédents des technologies proposées si, au titre des critères impératifs de conformité technique utilisés dans l’évaluation, le Soumissionnaire doit démontrer qu’il a la capacité voulue pour assurer la révision et l’extension de ces technologies). ] 10.2. COMMENTAIRE POINT PAR POINT SUR LES SPECIFICATIONS TECHNIQUES 10.2.0 Le Soumissionnaire doit fournir un commentaire point par point sur les Spécifications techniques de l’Acheteur pour démontrer que le Système, dans sa conception globale, et les Technologies de l’information, Produits et Services proposés dans son offre sont conformes pour l’essentiel à ces Spécifications, voir la Clause 16.2 b) des IS (Clause 14.2 b des IS dans le DTAO en deux-étapes). 10.2.1 Pour démontrer la conformité de son offre, il est vivement recommandé au Soumissionnaire d’utiliser la Liste de contrôle de conformité technique figurant à la Section G des Spécifications techniques, sinon, il courra sensiblement plus de risques de voir son offre déclarée non conforme sur le plan technique. La liste de contrôle doit notamment comporter des renvois précis aux pages correspondantes de l’offre technique du Soumissionnaire. 10.3. PLAN DE PROJET PRELIMINAIRE 10.3.0 Le Soumissionnaire doit préparer un Plan de projet préliminaire décrivant, entre autres choses, les méthodes et les moyens en personnel et en matériel qu’il se propose d’utiliser pour la conception, la gestion, la coordination et l’exécution de toutes les tâches qui lui incomberont, si le Marché lui est attribué, et contenant ses estimations sur la durée et la date d’achèvement de chacune de ces principales activités. Ce plan DOIT aussi traiter des questions et points prioritaires spécifiés dans [ indiquer : « la Clause 19 du CCP » y compris tout autre élément indiqué à la Clause 16.2 c) des IS (Clause 14.2 c) des IS dans le DTAO en deux-étapes)]. Il devra également préciser de quelle manière le Soumissionnaire envisage les principales responsabilités de l’Acheteur et de toutes autres tierces parties associées à la fourniture et à l’installation du Système, et indiquer les moyens que le Soumissionnaire se propose d’employer pour coordonner les activités de chacune des parties concernées, afin d’éviter les retards ou les chevauchements. 10.4. CONFIRMATION DE RESPONSABILITE POUR L’INTEGRATION ET L’INTEROPERABILITE DES TECHNOLOGIES DE L’INFORMATION 11.4.0 Le Soumissionnaire doit confirmer par écrit que, dans le cas où le Marché lui sera attribué, il acceptera d’être tenu responsable de l’intégration et de l’interopérabilité de toutes les Technologies de l’information proposées et devant être incluses dans le Système, ainsi qu’il est spécifié plus en détail dans le Dossier d’appel d’offres. ANNEXE 1.Conditions fonctionnelles, techniques et de services La liste des spécificités indiquées ci-dessous n'est pas exhaustive et les soumissionnaires peuvent faire des suggestions supplémentaires optionnelles, des spécificités qui seront disponibles dans le système offert. 1. Conditions fonctionnelles du système ATS/CSD Cette section fournit les caractéristiques fonctionnelles détaillées pour le système ATS/CSD. Les propositions doivent contenir une réponse par article à cette section, comme spécifié dans la section 9. Les options fournies dans le système proposé, pour satisfaire à n'importe quelle exigence particulière ci- dessous, doivent être détaillées, ainsi que n'importe quelle recommandation que le soumissionnaire souhaiterait faire. Dans le cas où le soumissionnaire ne peut pas répondre à une exigence donnée, cela devrait être clairement précisé dans sa réponse. Clef de Priorité : O - Condition - Obligatoire E - Aucune condition obligatoire, priorité Elevée B - Aucune condition obligatoire, Basse priorité 1. Conditions techniques et fonctionnelles du système ATS Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire Mesures de gestion des risques Chaque participant au système ATS sera responsable de la supervision de O 1.1 son compte, en veillant à ce qu’il dispose d’un solde suffisant pour exécuter chaque ordre de paiement tel que transféré à travers le système. Pour soutenir ces procédures, le système devrait inclure : 1. Les messages textes transférés à travers le système entre deux ou O plusieurs participants. 2. La sécurité, l’authentification et la validation des messages textes O 3. Un texte/référence en ligne contenant les règles et les procédures édictées O par la BCM Surveillance des soldes de compte O 1.2 L’administrateur du système au sein de la BCM devra avoir une vue globale du système ainsi qu’une vue sur l'activité de chaque participant. Les participants doivent pouvoir obtenir des informations sur le statut de leurs O opérations dans la file d’attente tout au long de la journée, ainsi que sur le solde courant de leurs comptes de règlement respectifs Gestion de liquidité : Chaque participant dispose d’un compte de règlement unique en les livres O de la BCM dans lequel toutes ses liquidités sont contenues. L’ensemble des comptes de règlement sera tenue dans la composante RTGS de l'ATS 1.3 pendant la journée d’échange, servira aux opérations de paiement et à maintenir la limite de solde pendant la journée d’é change. Il sera nécessaire qu'une réconciliation complète soit faite entre l'ATS et le système comptable de la BCM à la fin de la journée d’échange afin d’assurer l’intégrité de toutes les opérations comptables de la BCM Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire Source de liquidité : 1.4 Le système devra prendre en charge les sources de liquidités suivantes : 1. Transferts entrants (montant y compris d'intérêt et de maturité de dette O du Gouvernement); 2. Emprunts interbancaires ; O 3. Achat et vente des devises étrangères par la BCM O 4. Comptes de correspondants O 5. Facilités d’avance intra-journalière O Avance intrajournalière : 1.55 Le système devrait supporter le traitement des opérations de bout en bout STP O (Straight Through Processing) et les soumissionnaires devront expliquer comment le STP est réalisé dans leur solution. Il devra également être possible d’effectuer des demandes de liquidité intra- O journalière à n'importe quel moment, pendant la journée d’échange en rendant disponibles les montants nécessaires. La liquidation de ces montants ne devra exiger aucune intervention des opérateurs de la BCM. Réapprovisionnement par la BCM : Le système devra mettre à la disposition de la BCM des moyens adaptés au O 1.6 réapprovisionnement des comptes des participants en intra-journalier et en overnight. Affectation des fonds dans des comptes de règlement : La BCM ou le participant devront pouvoir temporairement réserver ou O 1.7 affecter des fonds dans le compte de règlement d'une banque jusqu'à un niveau donné pour satisfaire aux exigences fixées (par exemple pour l’obtention d’espèces auprès des guichets de la BCM). 1.8 Problèmes de liquidité : Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire Le système ATS devrait informer la BCM ainsi que les participants émetteurs O d’ordre de paiement de tout problème de liquidité. Le système devrait être en mesure de surveiller et notifier la BCM des évènements tels que: 1. La possibilité que le solde d'un compte atteigne et dépasse un niveau minimum 2. Un solde de compte en-dessous du solde moyen requis O 3. Les détails des ordres de paiement non exécutés en raison du manque de O liquidité Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire Gestion de file d'attente et traitement de priorité La composante RTGS de l’ATS va traiter plusieurs flux d’opérations de O paiement en file d’attente. Les soumissionnaires devront décrire en détail les mécanismes de gestion des files d’attentes implémentés dans leurs solutions (incluant le nombre maximal de files d’attente et les types de files d’attentes). Avec les caractéristiques minimum suivantes : 1. Le système devrait avoir comme options conservation de certains types de transactions pour une exécution ultérieure, aux date et heure prévues par le participant émetteur. 2. Certaines files d’attente vont fonctionner suivant l’approche FIFO « First In, First Out », à moins que les mécanismes de déblocage soient utilisés par la BCM en tant qu'opérateur 3. Des ordres de paiement seront insérés dans chaque file d'attente par le participant, dans l'ordre dans lequel le participant les expédie et selon le code de priorité assigné par le participant (il y aura une file d'attente 1.9 pour chaque niveau de priorité par participant). Chaque participant contrôlera seulement les files d'attente pour les paiements qu'il a ordonné ; 4. Aucun transfert de faible priorité ne sera traité avant que tous les transferts de priorité plus élevée n’aient été traités. L'ordre de paiement en tête de la file d'attente est réglé lorsque les fonds sont disponibles. 5. Pour faciliter la gestion quotidienne des liquidités, le système devra donner aux participants la possibilité de modifier la priorité des ordres de paiement en file d’attente et/ou de modifier la position des ordres de paiement dans la file d’attente 6. La composante RTGS doit être conçu pour éviter la congestion qui pourrait mener à un blocage systémique. Si le mécanisme de résolution des blocages systémiques est mis en œuvre par la BCM, Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire les participants devront en être notifiés. 7. Le système doit fournir des outils automatiques de gestion des files d'attente 8. Chaque participant ainsi que la BCM devront être autorisés à obtenir des renseignements au sujet du nombre et du montant total de paiements dans leurs files d'attente. 9. Les transactions non réglées et à la fin de journée d’échange devront être annulées (en avertissant le participant). 1.10 Fonctions de règlement de compte : Les propositions doivent contenir des détails sur la façon dont ceci sera O réalisé par leur système proposé. (A noter que le livre de la BCM est le noyau du système bancaire) Le fournisseur choisi devra connecter le système ATS avec le noyau du système bancaire de la BCM. Instruments de paiement : Le type de transactions élémentaires qui vont s’effectuer dans le système O RTGS est le virement bancaire (ordre de paiement). 1.11 Dans ce type de transfert, des fonds doivent être disponibles dans le compte du participant initiateur de l’ordre de paiement afin que le virement soit exécuté immédiatement et que le compte du participant bénéficiaire soit crédité. Les ordres de paiement seront émis individuellement ou par lot. Ils devront O être émis exclusivement de façon électronique. Le RTGS délivrera également vers les participants destinataires, les sorties correspondantes électroniquement. Les soumissionnaires doivent décrire tous les types d'instruments de O paiement que leur solution proposée peut traiter, avec des recommandations Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire quant à la composante (RTGS ou ACH) approprié pour l’instrument de paiement considéré La BCM précise que la composante RTGS traitera de ce qui suit : O 1. Paiements interbancaire en temps réel de gros montants ; 2. Règlement des soldes de compensation provenant de la composante ACH de l'ATS 3. Règlement de soldes de la compensation des opérations transférées à travers le Switch monétique 4. Règlement des transactions impliquant le transfert des titres selon le mécanisme de DvP en liaison avec les opérations réalisées dans le système Dépositaire Central des Titres ; En plus de la composante RTGS, l'ATS contiendra également la O fonctionnalité de compensation (pour la composante ACH) afin d’effectuer le traitement de différents flux de paiement de détail (de valeur basse). Ceux- ci incluront : 1. Ordres de virements ordonnés par des clients des institutions financières ; 2. Fichiers séquentiels des instructions de paiement (crédits) provenant des banques qui n'ont pas complètement mis en application le Straight-Through Processing (STP) ; 3. Dossiers des ordres de prélèvements des fournisseurs de service ou d'autres entités identifiées ; 4. Ordre de paiement par chèques et effets (lettre de change et billet à ordre d'autres entités identifiées ; 5. D'autres flux possibles des paiements de basse-priorité ; 6. Des paiements présentés par lot, par exemple les paiements des salaires 1.12 Standards de message : O Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire Les formats de message doivent être basés sur des normes reconnues et doivent être similaires aux formats SWIFT Les soumissionnaires doivent fournir des informations à propos des normes O auxquelles leurs systèmes se conforment, y compris la planification d’adoption de leurs produits futurs à des normes naissantes. Annulation d'un paiement se trouvant dans la file d'attente du RTGS : Le participant émetteur pourra annuler une transaction de paiement en file O 1.13 d'attente. De telles demandes seront authentifiées et une transaction de paiement peut seulement être annulée si elle n'a pas été déjà réglée. Chaque demande fera l’objet d’un message de retour avec une indication de l’action réalisée par le système Programme d’ouverture des journées d’échanges du système 1.14 Le système sera opérationnel pendant tous les jours ouvrables de la BCM. O Les heures des opérations seront ajustables et paramétrables Signalisation des ordres 1.15 Pour chaque transaction de paiements réglée, le débit et le crédit des comptes O de règlement respectifs des participants devraient être exécutés simultanément Ordre de règlement des soldes de systèmes nets Le système devrait également pouvoir traiter un ensemble de soldes de O participants comme un tout et réaliser le règlement en mode « tout ou rien ». 1.16 Si un seul débit ne peut pas être imputé sur le compte du participant concerné, alors l’ensemble des soldes doit être rejeté. Ceci est particulièrement nécessaire pour régler les résultats des systèmes tels que l'ACH. Les positions multilatérales issues du résultat de la compensation seront O considérées dans le système RTGS comme une série de transactions à traiter Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire Demandes de règlement des systèmes de règlement de titres : Le système doit être relié à la CSD pour le règlement de toutes les opérations O de titres qui inclura : 1. les opérations relatives au marché primaire des titres du gouvernement et de la BCM; 2. Les Opérations d’ « open market » et d'autres opérations de politique monétaire de la BCM ; 1.17 3. la comptabilisation de toutes les transactions réalisées sur les marchés financiers ; 4. Des outils de gestion des avances intra-journalières ; 5. Le règlement des opérations interbancaires de marché monétaire; 6. Règlement des transactions du marché secondaire des titres émis par la BCM ou le Gouvernement 7. Le règlement des opérations liées au service de la dette, pour l'ensemble des titres de la dette publique Pour toutes ces opérations, le principe de Straight-Through-Processing doit O être garanti. L'interaction opérationnelle entre l’ATS et le CSD pour garantir la DvP est décrit dans le dossier d’appel d’offres. Ouverture et fermeture de compte : La BCM disposera de la faculté d’ouvrir, de fermer ou de suspendre O n'importe quel compte tenu dans le système d'ATS. Si un compte est 1.18 suspendu, aucune transaction sortante de paiement ne peut être effectuée, mais des paiements entrants peuvent être reçus. Le système aura des dispositifs de paramétrage tel que la Fermeture complète (Full close) d’un compte, crédit uniquement (Only credit), etc. Maintenance des autorisations de découvert intra journalières : 1.19 La BCM aura les habilitations nécessaires pour déterminer et d’actionner O toutes les dispositions concernant l'octroi de crédit intra-journalier/overnight Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire Surveillance (monitoring) de compte par la BCM : Pour la gestion de système, la BCM aura accès à toute l'information de O 1.20 compte de règlement, incluant : 1. Soldes des comptes ; 2. Paiements en file d’attente et 3. Historiques de compte. Des statistiques seront produites à intervalles réguliers. Elles incluront des O mesures d'efficacité de règlement pour chaque compte, tel que le temps en moyenne entre la réception des paiements et la notification de règlement. Le système devrait afficher des synthèses en ligne de la situation globale de O liquidité du système, pour la période courante et la comparer à la période précédente (heures, jours, et semaines). Archivage: O Le système devrait maintenir les enregistrements en ligne des transactions impactant les comptes de règlement et les données historiques pendant la 1.21 durée prévue par la loi. Des dispositions appropriées doivent être prises afin de réaliser la récupération des données liée à l’historique du compte de règlement. Les données liées à l’historique doivent être stockées localement pendant une période d’au moins sept ans. Le système devrait fournir une gamme de fonctionnalité graphiques pour O faciliter le contrôle d’activité et la surveillance (monitoring) des liquidités ; par exemple, un affichage graphique représentant le nombre de paiements alignés par banque et un indicateur de performance en temps réel. Les soumissionnaires sont priés de fournir les détails complets de la O démarche à entreprendre pour rechercher des données en ligne et offline, et de décrire en détail comment rechercher des données couvrant des périodes multiples. Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire Coordination des opérations avec des participants : 1. En début de journée, les participants recevront un message indiquant O que le système est ouvert pour le début des opérations ; 2. Les participants recevront un message en temps réel pour toutes les occurrences des paiements effectués à partir ou reçus sur leurs comptes ainsi que les messages de paiement envoyés mais tenus en file d'attente, indiquant le solde du compte, les crédits utilisés (seulement pour des 1.22 banques). 3. Les participants recevront un message spécifique indiquant le début d'une journée d’échange ou sa fin ; le système devra, par exemple, annoncer le déversement des soldes du système de compensation. En cas de rupture de service subie par un participant, la BCM doit pouvoir informer tous les participants en ligne de la situation actuelle et la prolongation de la journée d’échange qui peut résulter de cette situation. 1.23 Volume : Le système devrait disposer d’une capacité de traitement d’au moins 5.000 O transactions de paiement par jour en pic pour ce qui est des évaluations indiquées. Le système devrait pouvoir gérer cinq cycles de règlement par jour pour des systèmes de règlement nets. Quoi qu'il arrive, les soumissionnaires doivent indiquer leurs options en matière de capacité de traitement. Performance : O Le système doit pouvoir traiter uniformément au moins 10 transactions de 1.24 paiement par minute (mesurée lors de tests de benchmark en utilisant la longueur moyenne des messages de paiement de la BCM/ISO, et en assumant qu’il n’y ait aucun problème de type opérationnel). Cette mesure tient compte Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire d’un traitement de bout en bout, de l’envoi de l’ordre du participant jusqu’à la confirmation que le paiement a été effectué. Le soumissionnaire démontrera que son système peut traiter les volumes O maximum de transactions prévisionnelles et expliquer comment il peut faire face aux augmentations de volumes. Il doit tenir compte également, pour le site de secours, de l’absorption des flux du système défaillant. La configuration d’origine doit être dimensionnée pour pouvoir absorber les pointes journalières sur les 5 ans à compter du démarrage. Il devra également fournir les résultats de tests démontrant la capacité de son système à traiter 10 paiements par minute dans la configuration matérielle proposée dans son offre. Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire Performance Monitoring: La performance du système sera surveillée en continu, et le système devrait O produire des rapports appropriés d’exceptions (erreurs) avec des détails appropriés chaque fois que les performances du système vont à l’encontre des normes acceptables de rendement. Les propositions doivent inclure des détails sur les recommandations des soumissionnaires couvrant au moins ce qui suit : 1. La conception et l’implémentation d'un système de surveillance approprié, y compris un moniteur d'événements qui dépeint des événements opérationnel critique et de sécurité comprenant le statut 1.25 opérationnel de tous les utilisateurs autorisés et les tentatives d'accéder au système par les utilisateurs non autorisés ; 2. .Le développement d'un horaire de traitement quotidien fixe ; 3. Introduction d'un système de reporting approprié qui peut être employé pour surveiller la qualité des nouveaux services et les fournir à tous les participants Les soumissionnaires doivent décrire comment les différentes mesures doivent être surveillées et, le cas échéant, donner également une indication des niveaux de performance qu'ils comptent réaliser. Les mesures doivent inclure les trois éléments suivants : Disponibilité du Système La disponibilité du système devrait pouvoir être mesurée (par exemple, par O 1.26 le taux de disponibilité de chaque composant pendant les heures ouvrables) indépendamment des sources de dysfonctionnement (par exemple, logiciel, réseau, puissance, erreur humaine). Comptage des messages Un comptage doit être réalisé concernant les messages en fonction des O 1.27 paramètres suivants : 1. nombre et valeur des messages par jour et par type de paiement, flux (file d'attente) par participant et le total ; Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire 2. nombre et valeur des messages traités pendant l'heure de pointe ; 3. Temps moyen des messages dans la file d'attente, par participant et le total par jour ; 4. Durée moyenne des messages de paiements dans les files d'attente, en heure de pointe. D’autres possibilités de paramétrage doivent également être proposées pour réaliser des comptages ou des statistiques de performance. 1. Quoi qu'il arrive, la disponibilité des outils pour recueillir et maintenir des statistiques additionnelles pour la BCM et les participants serait un dispositif souhaitable de la solution proposée. Règles et procédures opérationnelles 1.28 Les soumissionnaires devront travailler avec la BCM pour développer et O mettre en œuvre des règles et des procédures pour la mise en marche du système L'information de facturation O Le système doit inclure un mécanisme flexible de facturation qui calculera 1.29 automatiquement, pour chaque composante (ATS et CSD) des frais pour chaque participant et qui devrait avoir les fonctionnalités suivantes : 1. Permettre le calcul des frais périodiques fixes (par exemple frais annuels ou mensuels d'adhésion) ; 2. Calculer les frais d'utilisation en fonction des messages ou du type d'instruction utilisés ; 3. Appliquer des coefficients de modification de tarif par message pendant des tranches horaires au cours de la journée ; 4. Appliquer des coefficients de modification de tarif pour différents flux de paiement (files d'attente) ; Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire 5. Appliquer des coefficients de modification de tarif pour des volumes de transactions ; 6. Tenir compte de différents frais selon le participant ; 7. Appliquer des frais directement, sans intervention manuelle autre que l’autorisation de la transaction ; 1. 8. Etablir automatiquement les factures à envoyer à tous les participants directs Les soumissionnaires doivent expliquer en détail les options des O fonctionnalités de facturation, y compris la génération automatique des messages de paiement pertinents. Rapports O Le soumissionnaire retenu sera tenu de développer un certain nombre de 1.30 rapports normalisés. Ceci devrait être fait ensemble avec le personnel de la BCM afin de s’assurer qu’ils sont suffisamment formés pour élaborer par eux-mêmes des rapports spécifiques Le système doit fournir un ensemble complet et flexible de surveillance, O possibilités de reporting et d'analyse, pour permettre à chaque participant d'avoir le maximum d’information, et de contrôle sur sa participation au système (similaire à la manière dont les utilisateurs de services bancaires en ligne peuvent contrôler toutes les activités de leurs différents comptes eux- mêmes via un navigateur internet web). Les possibilités de monitoring et de reporting ainsi que d'analyse doivent couvrir : 1. Les rapports de monitoring intra-journaliers 2. Les rapports de fin de journée 3. Les rapports sur l’historique d’activité du système classés par préférence de l’utilisateur telle que la date, le montant,… Dans le cas des participants autres que la BCM, ces rapports doivent être O strictement confinés à leurs propres données, tandis que la BCM doit pouvoir obtenir l'information sur l'ensemble des opérations de tous les participants. Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire .Les outils de monitoring intra-journalier doivent être disponibles sur O demande, tandis que les rapports de fin de journée doivent être fournis automatiquement aux utilisateurs concernés, BCM et participants. Les outils d'analyse de l’historique devraient fournir un éventail de O possibilités, y compris des possibilités flexibles de requêtes de base de données et également la capacité de télécharger des extraits de l'historique de la base de données pour réaliser des analyses plus approfondies à l'aide d’outils statistiques ou les tableurs. Ce service sera à la disposition d'autres participants sur demande adressée à la BCM La base de données archive doit être tenue de manière séparée de la base de O données en ligne (du jour courant), pour des raisons de performance et de sécurité. La BCM se mettra d'accord avec le soumissionnaire retenu sur la durée pendant laquelle les données archive doivent être gardées en ligne (contrairement à l'archivage différé) pendant le fonctionnement des systèmes. Information intra-journalière en ligne pour les participants 1.31 Le système devrait fournir au moins les informations en ligne suivantes aux O utilisateurs opérationnels de la BCM, aux départements autorisés et aux auditeurs : 1. Message simple et statut en entré du fichier séquentiel ; O 2. Activité quotidienne, hebdomadaire, mensuelle, et annuelle totales O (pour chaque participant émetteur et destinataire) ; 3. Activité pendant des périodes définies par l'utilisateur ; O 4. Rapports sur des possibles doublons de message ; O 5. Toute l'information du solde de compte, des participants ; O 6. Requêtes de consultation des ordres de paiement dans le système O (tenant compte de différents critères de sélection) ; Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire 7. Alertes quand les files d'attente augmentent en taille au-delà des limites O définies en termes du nombre de paiements ou des montants à payer. De telles limites seront définies par la BCM ; 8. Des résumés des rapports de sécurité concernant des tentatives d’accès O non concluante, les messages invalides ; 9. Un affichage graphique montrant le statut des files d'attente de O paiement, Un tel affichage serait disponible pour la Direction des opérations bancaires et fournirait rapidement aux utilisateurs une vue générale de l’état de fonctionnement du système. • L'information en ligne intra journalière pour des participants O 1.32 Le système devrait fournir au moins l’information suivante aux participants pour permettre la gestion de leurs flux de paiement : 1. Les participants recevront un message immédiat pour tous les paiements envoyés ou reçus dans leurs comptes de règlement par la composante RTGS ; 2. En cas d’interruptions de service chez un participant, la BCM doit pouvoir informer tous les autres participants de la situation et aviser d’une possible modification de l’organisation de la journée d’échange ; 3. Un participant doit être capable de tracer n’importe quelle transaction individuelle ou appartenant à un groupe d’instructions à travers toutes les étapes du traitement ; 4. Les participants doivent pouvoir se renseigner sur le statut de leurs files d'attente de paiement tout au long de la journée ainsi que le solde courant de leurs comptes respectifs de règlement 5. Le système devrait fournir au moins les informations suivantes aux participants : a. Accès à l’information sur le solde de compte de règlement du participant b. Information sur des instructions de paiement dans le système (tenant compte de différents critères de sélection) c. Avis du statut des ordres de paiement envoyé/reçu débité/crédité, traités avec succès ou rejeté Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire d. Statut d'ordre (sur demande) e. Description d'erreur de validation f. Accès à l’information de leurs propres files d'attente sortantes g. Informations des soldes moyens quotidiens intra-journaliers calculés h. Activité et frais de transaction i. En plus du flux d'information pendant le jour de d’opérations, chaque participant sera équipé de dossier électronique contenant des informations suffisamment détaillées sur la réconciliation de compte automatisée j. Un rapport quotidien complet sera envoyé à chaque participant comme faisant partie de l’opération journalière k. Le système doit fournir des équipements d’information ad-hoc à travers toutes les données, sujettes au contrôle d'accès des utilisateurs l. Le système doit permettre l'accès à toutes les données antérieures année / période (si non archivé en-dehors du système), sujet au contrôle d'accès d'utilisateur m.Le système devrait permettre à l'utilisateur de définir des critères de recherche/filtrage n. Le système devrait permettre à toutes informations qui s’affichent sur écran d'être imprimé ou sauvé à un dossier o. Tous les écrans d’information doivent avoir la possibilité de faire défiler en haut et en bas l’information qui sera adapté dans une fenêtre simple. Problèmes de liquidité Le système devrait être en mesure de notifier la BCM et les participants O concernés des problèmes de liquidité. Le système devrait être en mesure de 1.33 surveiller et de générer des alertes dans les cas suivants : 1. un solde de compte est en-dessous du niveau minimum ; 2. Un ordre de paiement est supérieur au montant disponible sur le compte de règlement ; Priorités Réponses du Numéro Conditions techniques et fonctionnelles critiques soumissionnaire Les paiements rejetés pour insuffisance des fonds devront être signalés au participant qui les a initiés 1. Les offres devront préciser tous les cas qui pourraient faire l’objet d’une surveillance. 2. Capacite d’interfacage du systeme Numéro en Priorité Condition critique Réponses du soumissionnaire travers de réf. Interfaçage avec les systèmes de la BCM 2.0 Le fournisseur développera l’interpréteur comptable qui permettra d’alimenter le système d’information de la BCM avec tous les mouvements opérés sur les systèmes installés (ATS et CSD) Le fournisseur développera l’interface avec l’application Flexcube de la BCM pour la gestion des comptes en devises et plus précisément du dollar 2.1 US pour ce qui concerne les opérations libellées en USD et échangées dans le système ATS. Interfaçage avec les systèmes bancaires des participants : Les banques effectueront des opérations de paiements à partir de leurs O comptes tenus dans les livres de la BCM au nom de leurs clients. 2.2 L’interface en mode STP (straight-through processing) doit être réalisée de telle sorte que, dans la mesure du possible, les comptes des clients des banques ainsi que leurs comptes gérés dans les livres de la BCM soient mis à jour simultanément Messages Au minimum, le système doit supporter le format standard SWIFT MTnnn O pour tous les messages. La préférence de la BCM est que le système emploie les formats d'ISO 2.3 20022 (UNIFI) pour tous les messages, RTGS et de petits montants (ACH).Les soumissionnaires doivent fournir des informations sur toutes les normes que leurs systèmes supportent, en particulier leur plan de développement dans ce domaine. Numéro en Priorité Condition critique Réponses du soumissionnaire travers de réf. Terminal du Participant : Pour les paiements individuels, l’accès peut se faire depuis un PC dédié, O pour des petites institutions ou de n’importe quel poste de travail et 2.4 utilisateurs autorisés sur le LAN dans le cas de participants ayant un nombre important d’utilisateurs. Dans ce cas, il doit être clairement indiqué comment le système sera accessible par ces utilisateurs, par exemple par l’Internet Intégration des participants stratégiques Le système doit fournir les Connexions standard pour permettre le O 2.5 traitement automatisé de bout en bout (STP) pour tous les types de paiement. Ceci exigera des participants de mener à bien les travaux nécessaires pour intégrer leurs systèmes bancaires à l'ATS. Le fournisseur retenu de l'ATS devrait travailler avec les banques O commerciales afin de les aider dans cette tâche, pour fournir les 2.6 spécifications complètes d’interfaçage avec STP à aucune charge, et pour fournir tout appui technique et conseils nécessaires pendant le processus de mise en œuvre. Les soumissionnaires doivent indiquer le coût pour connecter l’ATS avec O 2.7 les systèmes bancaires de base des banques participantes dans leur offre. Les soumissionnaires doivent décrire aux participants les options O 2.8 d'intégration disponibles pour réaliser les connexions en mode STP entre la composante RTGS et leurs systèmes bancaires. 3. Exigences techniques relatives à l’ATS Numéro en travers Condition critique Priorité Commentaires de réf. 3.0 Conditions de système L'environnement technique global de la BCM dans lequel le système O sera déployé est décrit dans la section traitant des exigences du système. Les soumissionnaires devront clairement indiquer l'environnement informatique ainsi que tous les matériels et logiciels additionnels requis par le système, et montrer clairement comment l'intégration avec l'environnement informatique de la BCM sera réalisée La solution recherchée doit être complète, à un prix fixe et inclure tous les éléments, mais de façon non limitée : 1. Aux logiciels applicatifs ; 2. Au matériel et à tout autre logiciel (par exemple logiciel système, RDBMS, etc.) nécessaire au nouveau système de paiement. Si le soumissionnaire veut proposer d’autres éléments allant au-delà de la solution recherchée, chaque supplément devra faire l’objet d’une description détaillée en termes de caractéristiques, de performances et en termes d’un minimum d’exigences pour le fonctionnement des applications 3. A toute personnalisation et intégration de logiciel incluant une analyse des exigences, une spécification, le développement et l’implémentation des modules logiciels spécifiques 4. A un niveau élevé de support pour aider la BCM dans les aspects métiers du nouveau système de paiement. Ces services incluront le support sur les procédures opérationnelles, la politique de tarification ainsi que les règles d'exploitation 5. Aux services incluant l’installation, les tests, la documentation, la formation, la remise et reprise, et l’intégration avec Numéro en travers Condition critique Priorité Commentaires de réf. l’environnement informatique existant comme décrit à la section 5 6. Au support continu (hors période de garantie) Les offres devront prendre en compte tous les aspects du système, notamment : 1. Les équipements et fonctionnalités comprenant tout autre service fourni aux participants directs et indirects ; 2. Niveaux des performances du système ; 3. La facturation ; 4. Les opérations, la maintenance et le support ; 5. Développement et améliorations ; 6. Capacité, évolutivité et mises à niveau du système. Principes de conception : Les systèmes ATS et CSD (DCT) doivent être considérés comme étant O 3.1 deux composants d’un même système et devront être conçus sur base des meilleures pratiques internationales et conformément aux principes d’exigences suivants: 1. Avoir un niveau élevé de convivialité avec une interface O graphique réalisée suivant les standards en matière de construction d’interface utilisateur graphique 2. Se conformer aux standards de l'industrie qui permettent au O système d'être facilement connecté avec d'autres systèmes, et/ou d'être étendu par des modules fonctionnels additionnels ou en capacité ; Numéro en travers Condition critique Priorité Commentaires de réf. 3. Offrir des moyens de connexion à faible coût et faciles à mettre O en œuvre pour des nouveaux participants soit sur un terminal distant soit par une liaison directe 4. Permettre un usage optimal de chaque équipement déjà installé O au sein du système de la BCM comme dans celui des participants ; 5. Fournir des pistes d'audit complètes pour toutes les activités au sein du système, y compris les accès système, les messages envoyés et reçus 6. Atteindre un haut niveau de fiabilité avec un accent particulier O sur l’intégrité, la sécurité et l’exactitude des données, ainsi que sur la prévention d’accès non autorisés : a. Mécanismes de sécurité basée sur des politiques b. Flexibilité dans la gestion des habilitations accordées aux utilisateurs, notamment en donnant ou en retirant une habilitation spécifique c. Activation et désactivation des fonctionnalités en dehors des heures ouvrables d. Déconnexion après une certaine période d’inactivité e. Retrait forcé des habilitations d’administrateur aux utilisateurs connectés f. Mots de passe cryptés avec un algorithme de cryptage robuste. 7. Haut niveau de disponibilité éprouvé par des tests rigoureux et O garanti par un contrat de service de type SLA; Numéro en travers Condition critique Priorité Commentaires de réf. 8. Offrir à la BCM et aux participants, un moyen automatique de O traitement journalier d’incidents ainsi qu’un reporting d’incidents 9. Dimensionnement correspondant à la charge de travail prévue. O Dimensionnement en termes de débit à la sortie, de temps de réponse, et prenant en compte les pics et la croissance globale du volume des transactions Les sites et environnement suivants devront être prévus pour les O 3.2 ATS/CSD : a. Un site principal (environnement de production), celui qui sera utilisé pour un régime de fonctionnement nominal du système ; b. Un site de reprise après sinistre (site de secours) qui peut être activé en cas de panne ou de sinistre sur le site principal. Ce site devra fournir les mêmes fonctionnalités que le site principal; c. Un site de test et de développement (environnement de test et de développement) qui devra être une réplique fonctionnelle de l’environnement de production, devant être utilisé pour l'essai, le développement et la formation du personnel de BCM et des opérateurs de banques commerciale 10. Les systèmes ATS et CSD devront être construits selon les règles de l’état de l’art en la matière, avoir une très bonne utilisabilité, et présenter des interfaces graphiques uniformes construits conformément aux standards en matière de GUI. 11. Le système devrait fournir des outils complets de gestion d’incidents. Toute l'administration du système devra se Numéro en travers Condition critique Priorité Commentaires de réf. faire depuis un seul site. Le site de reprise après sinistre devra être automatiquement activé. Principe de conception de la composante RTGS : 3.3 La composante RTGS devra être conçue sur base des meilleures O pratiques internationales en la matière et devra se conformer aux principes de base suivants : 1. La composante RTGS et ses composants devront répondre aux normes internationales en la matière, y compris les formats de messages système, afin de faciliter l'intégration avec d'autres systèmes et infrastructures de la BCM, existant ou à déployer 2. La composante RTGS devra être développé suivant une architecture modulaire, afin de permettre une maintenance facile. Les interfaces entre les composants du système devront être clairement définies ; 3. Pour réduire au minimum les risques d’erreur humaine et les ruptures de service éventuelles, le fonctionnement du logiciel devra être automatisé le plus possible, avec des moyens permettant d’assurer l’exécution complète de chaque tâche, conditionnant le déclenchement des tâches suivantes 4. La composante RTGS devra présenter un haut niveau de fiabilité et en particulier un haut niveau d’intégrité des données, de sécurité et d'exécution opérationnelle 5. La composante RTGS devra fournir un haut niveau de disponibilité pendant ses heures de fonctionnement. 6. Le système devra permettre une utilisation optimale des infrastructures déjà déployées à la BCM et chez les participants 7. La composante RTGS devra fournir un niveau élevé de redondance. Le basculement vers le serveur de secours en cas de défaillance sur Numéro en travers Condition critique Priorité Commentaires de réf. le serveur nominal devra être automatique et sans indisponibilité pour les participants de système ; 8. La composante RTGS devrait fournir de diverses options de connectivité pour les participants : réseau privé et Swift. Le système devrait supporter des connexions simultanées de différents types. En cas d'échec sur une connexion, le système devra pouvoir basculer sur une autre connexion sans entraîner une rupture de service vis-à-vis des participants Les soumissionnaires devront fournir les détails techniques de la conception du système, sur base des exigences mentionnées dans les dossiers d’appel d’offre Principes de conception de la composante ACH : La composante ACH devra s’aligner sur les mêmes principes de conception que la composante RTGS. Mais il est important de O 3.4 mentionner que les exigences de l'ACH en termes de performance (temps de réponse) et de disponibilité sont par nature plus souples que celles du RTGS. La conception de l’ACH devra observer les principes : 1. La conception de l'ACH devra tenir compte du fait que l’ACH ainsi O que les postes de travail et systèmes connexes devront s’accomoder au site principal de la BCM, 2. La composante ACH devrait inclure des points d’accès par lesquels O les paiements seront envoyés au système central. Les entités des banques commerciales se connecteront aux points d’accès pour lancer des ordres de paiement, à travers le réseau de communication Numéro en travers Condition critique Priorité Commentaires de réf. interne des banques, et ou à leurs sièges respectifs, et recevoir par le même canal les relevés des opérations. 3. La composante ACH, ses composants, ses interfaces ainsi que le O format des messages devront être aux standards internationaux en la matière. Le format des messages de l’ACH devra être compatible à celui du RTGS. Dans le cas contraire, l’ACH devra intégrer un module de conversion de format 4. La composante ACH devrait être développé selon un mode O extensible et modulaire. Les interfaces entre ses composants doivent être bien définies. La structure modulaire d'ACH devrait être orientée pour prolonger la fonctionnalité et l'exécution de système si nécessaire 5. Le fonctionnement de la composante ACH devra être automatisé O autant que possible afin de réduire au maximum les risques d'erreur humaine 6. La composante ACH devra présenter un haut niveau de fiabilité et O en particulier un haut niveau de sécurité et d’intégrité des données 7. La composante ACH devra fournir un niveau acceptable de O disponibilité pendant ses heures de fonctionnement 8. Des technologies modernes doivent être employées pour la conception de l’ACH, notamment l’environnement logiciel de développement (langage de programmation de troisième génération, etc.) et l’environnement matériel de développement (équipement modernes, technologies, etc.) ; 9. La composante ACH doit permettre le basculement du site principal vers le site de secours sans entraîner une rupture de service vis-à- vis des participants. Lorsqu’il est actif, le site de secours devra être Numéro en travers Condition critique Priorité Commentaires de réf. capable de communiquer avec les applications du système d’information de la BCM actifs sur le site principal. 10. L’ACH devra supporter différents types de connexions pour ses participants (réseau privé, SWIFT, etc..). Il devra permettre également des connexions simultanées des différents types de connexion supportés. 3.5 Contrôle des transactions et du traitement des fichiers Les transactions entrantes et les fichiers doivent être analysés pour O assurer que : 1. le type et le format soient corrects 2. la source est autorisée ; 3. l’identification, la date et, pour les fichiers, les totaux de contrôle soient corrects 4. le message ne soit pas un doublon Les transactions sortantes et les fichiers devront être analysés afin O que : 1. Aucune transaction ou fichier ne soit perdue 3.6 2. Les alertes soient lancées en cas de défaut d’accusés de réception 3. Il ne soit pas possible de transmettre deux fois un même message, sauf dans le cas où les deux parties conviennent de l’opportunité de réexpédier le message Contrôles de validation 3.7 Les contrôles de validation doivent inclure : O 1. La validation de différentes instructions de paiement de tous les types Numéro en travers Condition critique Priorité Commentaires de réf. 2. Validation des champs obligatoires dans des instructions de règlement 3. Authentification de l’expéditeur du message 4. Confirmation du message et de validité de l'expéditeur 5. Routines de validation flexibles Les soumissionnaires devront décrire les options de validation O offertes par leur solution et les aspects sous lesquels celles-ci peuvent être personnalisées par la BCM, et décrire également la surcharge de traitement que les controles de validation peuvent imposer au système dans un environnement à haut débit. Intégrité et responsabilité de message : 3.8 Les commandes doivent inclure ce qui suit : O 1. Chaque enregistrement d’ordre de paiement, et fichiers contenant O de tels ordres, doit être identifié de façon unique avec sa source physique, identification de l'utilisateur et date et heure d'entrée dans le système ; 2. Chaque ordre doit être exécuté selon les habilitations limitées ou O non limitées prescrites par l'administrateur et/ou les participants ; 3. Un plan de numérotation de message ainsi qu’un contrôle doit être O mis en place pour s'assurer qu'il n'y a aucune perte, duplication ou insertion non autorisée des messages ; 4. La non-répudiation est exigée pour tous les messages de O participant ; 5. Un accusé de réception au niveau applicatif est exigé pour toute O la gestion de messages ; Numéro en travers Condition critique Priorité Commentaires de réf. 6. Là où un opérateur a la capacité de modifier n'importe quel O message (par exemple les messages qui contiennent des instructions pour effectuer des paiements ou transférer des valeurs) ou des paramètres critiques pour le fonctionnement, le système devrait contrôler que l’ensemble des autorisations nécessaires ont bien été accordées ; 7. Il doit être possible que la gestion opérationnelle automatique O trace n'importe quelle transaction en entrée dans le système jusqu'à la livraison définitive avec des informations détaillées sur le délai écoulé entre l’envoi et le traitement qui s'est produit à chaque étape. L'information à cette fin devrait être gardée en ligne pendant une durée définie par la BCM, après quoi les données doivent être archivées de manière permanente 8. Il devrait être possible de suspendre les opérations des O composantes du système (par exemple les files d'attente ou certains flux de paiement) pendant les jours ouvrables et de reprendre les opérations sans perte ou duplication des messages ; 9. Dans le cas de panne menant à l'indisponibilité du site primaire, O la reprise du service du site secondaire devrait être réalisée dans un temps maximum de dix minutes avec une intervention minime de l’utilisateur. 3.9 Exploitation des systèmes : 1. Pour réduire au minimum le nombre des ruptures de service O occasionné par l’erreur humaine, le logiciel devrait avoir des fonctions automatisées qui, dans la mesure du possible, assureront la réalisation des tâches. Numéro en travers Condition critique Priorité Commentaires de réf. 2. Le logiciel devrait offrir une interface utilisateur graphique O cohérente pour permettre à la BCM de contrôler ses opérations. Le logiciel devrait fournir une gamme complète des paramètres définissable par l’utilisateur qui doivent être amplement décrits dans les offres ; 3. Pour assister la mise en place de la politique monétaire, le système O devrait pouvoir afficher un résumé de la situation de liquidité globale du système de la BCM, à l’instant t mais aussi en la comparant aux situations précédentes (heures, jours et semaines) 4. Tous les aspects du système doivent être exécutés par l'intermédiaire O d'un GUI simple ; 5. Les exigences techniques de gestion doivent être minimisées. Il est O particulièrement important que tous les messages d'erreur soient affichés de façon simple et faciles à comprendre pour le personnel d'exploitation afin qu’il puisse procéder aux actions nécessaires pour y remédier ; 6. Le système ne devrait exiger une intervention du personnel O technique pour des opérations normales notamment le démarrage, des opérations quotidiennes et l'arrêt ; 7. Le système devrait fournir une gamme d’alarmes et d’alertes avec O les possibilités suivantes : a. Proposer différents niveaux d’alertes (par exemple critique, sérieux, informationnel) ; b. Fournir plusieurs types d’alarmes (par exemple, un message clignotant au niveau d’un poste de travail d’un opérateur, un message SMS envoyé à un téléphone portable) ; c. Choisir plusieurs destinataires des alertes (par exemple personnel d'opérations de la DSP (Direction de Systèmes de Numéro en travers Condition critique Priorité Commentaires de réf. Paiement) de la BCM, les utilisateurs dans les banques participantes, etc.) ; 8. les évolutions du système seront vérifiées en environnement de test O et les procédures correspondantes intégrées dans cette offre. Ces vérifications devront être effectuées en utilisant un ensemble de standard de messages-tests qui seront développés en tant que composante de mise en œuvre du système et doivent inclure : a. Test et certifications des nouvelles révisions de logiciel/mises à niveau avant utilisation ; b. Tester et certifier les systèmes des nouveaux participants y compris le matériel, le logiciel, les communications et les procédures. Sécurité - surveillance et mesure Tous les accès au système, les transactions manipulées et les O 3.10 changements affectant des contrôles d'accès, les paramètres de système, les annuaires et les commandes affectant l’intégrité du système doivent être tracées et rapportés aux opérateurs de la BCM pour être récupérés et analysés quotidiennement. 1. Les informations suivantes doivent être fournies : O a. Contrôle des opérations totales dans un site ; b. Gestion de tous les utilisateurs du système (de la BCM ainsi que des participants) et de leurs droits d'accès ; c. L'accès non autorisé des postes de travail ; Numéro en travers Condition critique Priorité Commentaires de réf. d. La fréquence et l’origine des fichiers de transactions invalides ; e. N’importe quel comportement inhabituel d’un utilisateur pouvant indiquer une tentative de fraude. 3.11 Contrôles d'accès 1. L'accès à tout le système doit être limité au personnel O autorisé au moyen d'authentification forte. Les mesures d'authentification d'utilisateur doivent inclure l'authentification selon deux facteurs ; 2. Le système devrait supporter une structure hiérarchique d'utilisateur, de telle sorte qu’au niveau de chaque participant (et également dans les entités opérationnelles de la BCM) il peut exister un administrateur local disposant de certains droits supplémentaires (par exemple pour réinitialiser les mots de passe) ; 3. La séparation des tâches doit être strictement appliquée O pour tous les programmes et fonctions stratégique de métier. 4. Tous les accès doivent être enregistrés y compris O l'identification de l'utilisateur et l’heure de chaque accès afin de fournir un enregistrement d'audit clair pour la revue en cas de violation accidentelle ou délibérée des contrôles de sécurité ; Numéro en travers Condition critique Priorité Commentaires de réf. 5. Les procédures journalières de démarrage du système O doivent inclure le lancement direct des systèmes interfacés ainsi que l'authentification de chaque système interfacé; 6. Les utilisateurs ne doivent pas être en mesure de voir les O options de menu pour lesquelles ils ne sont pas autorisés à accéder ; 7. Le système doit mettre en place une gestion rigoureuse des O mots de passe. Cela inclut la mise en application de mots de passe forts, l’expiration des mots de passe après un intervalle de temps donné, la désactivation des comptes après un nombre paramétrable de tentatives sans succès, ainsi que l’impossibilité de réutilisation d’un mot de passe récemment utilisé. 8. Les applications au niveau des postes de travail doivent O permettre par paramétrage la fermeture de session de manière automatique dans le cas où la session reste inactive pour une période plus longue que spécifiée afin de prévenir l’accès non-autorisé d’une personne tierce lorsque le poste n’est pas occupé. Technologie moderne : le système ATS doit être élaboré en utilisant des technologies O 3.12 modernes dans le développement de logiciels, y compris dans la conception logicielle et dans les tests. Des langages de programmation modernes doivent être utilisés pour le développement du système. Modularité et Flexibilité 3.13 O Numéro en travers Condition critique Priorité Commentaires de réf. Le système doit être flexible et conçu en utilisant une architecture modulaire. La modularité du système est caractérisée par les éléments suivants : 1. Le système sera composé de plusieurs modules indépendants qui peuvent être activé/désactivé selon les besoins de la BCM. 2. Chaque module devrait fournir la possibilité d’être testé/ dépanné à titre individuel. 3. Chaque module peut être mis à jour à titre individuel afin d’étendre les fonctionnalités du système. 4. La conception doit être centrée sur la flexibilité du système afin de fournir les fonctionnalités suivantes : a. .Pouvoir être configurable sans reprogrammation. Le comportement du système doit être défini dans la mesure du possible par des paramètres b. Le système devra permettre une implémentation harmonieuse de nouvelles fonctions (par exemple le changement de règle de gestion, le routage de message ainsi que la logique du métier) c. Le système doit être évolutif et prédisposé à accueillir des fonctionnalités supplémentaires (add -ons), par exemple, lors du dimensionnement basé sur des critères changeant, d. : i. changement du nombre des participants ATS, changement du statut ii. augmentation du volume des transactions iii. changement d'horaire en ce qui concerne les jours ouvrables iv. modification du calendrier de la journée d’échanges 5. .Le système de génération de rapports ou de développement O nouveaux devrait être automatisé autant que possible afin d'éviter Numéro en travers Condition critique Priorité Commentaires de réf. les opérations de programmation fastidieuses chaque fois qu'il y a un nouveau besoin. Ces rapports seront générés à partir des données enregistrées par le système. 6. Le système proposé doit fonctionner correctement sans restriction liée au nombre de comptes et de transactions, etc. 7. le système devrait être évolutif afin d'être compatible avec tout nouveau matériel et logiciel susceptibles d’arriver sur le marché et permettre aux banques d'effectuer leurs opérations sans adaptation 8. Le système doit être en mesure d'effectuer des restaurations automatiques pour toutes les transactions incomplètes sans intervention de l'utilisateur. 9. Le système doit avoir les utilitaires suivants: - archivage des données : déplacer des données anciennes depuis la base de données en production vers une base de données d'archivage - Archivage et récupération - Utilitaire de restauration Evolutivité Il est estimé au départ, que le trafic journalier sera en moyenne de O 25.000 transactions de paiements transitant par la composante ACH de l’ATS. Le débit dans les heures de pointe durant les jours ouvrables est estimé à 50.000 opérations de paiement. Le système doit être dimensionné avant l'implémentation afin de prendre en compte les transactions durant les heures de pointe, ainsi que le traitement lié au règlement via la composante RTGS de l’ATS de plus de 2000 Numéro en travers Condition critique Priorité Commentaires de réf. transactions de paiement par jour. On estime que la progression des volumes est de 20% par an pour chaque composante. Les offres doivent inclure un dimensionnement détaillé ainsi que des informations sur les performances de la solution proposée (logicielle et matériel) indiquant la capacité maximale attendue du système en termes de messages de paiement et d'autre types ainsi que les hypothèses sur lesquelles le dimensionnement est basé après une période de trois ans la performance du système peut être améliorée en ajoutant des capacités supplémentaires au système (évolutivité horizontale). Il devrait être possible de configurer les composants supplémentaires du système (de nouveau serveur d'accès, par exemple) afin de partager la croissance du trafic de données de type financier. Architecture ouverte l'architecture logicielle du système doit être ouvert dans la mesure du O possible afin de s'assurer que : 1. Des protocoles standards ouverts soient utilisés pour l'intégration 3.14 du système ainsi que pour l'interconnexion entre le SNP et les systèmes externes. 2. La solution ATS doit se conformer aux normes internationales afin d'assurer un niveau élevé de sécurité ainsi qu'une facilité de gestion. Facilité d'utilisation Le système doit être facile à utiliser afin de réduire les possibilités de O dysfonctionnement du système suite à une erreur humaine. 3.15 L'utilisation du système ne doit pas exiger des compétences spéciales des opérateurs. Le système devrait inclure des outils de dépannage qui peuvent être utilisés par des opérateurs sans expérience dans le développement de logiciel. Les outils doivent permettre la résolution Numéro en travers Condition critique Priorité Commentaires de réf. des problèmes technique et de logique métier. Les écrans de saisie et de surveillance devront être conviviaux, et l'aide nécessaire devrait être disponible en ligne. Les caractéristiques suivantes devront être implémentées : 1. L'interface utilisateur doit fournir de l'aide en ligne pour touts les formulaires 2. Des listes de consultation des valeurs possibles et de remplissage automatique devront être implémentées, dans le cas échéant, 3. Les messages d'erreur devront être suffisamment explicites et être en Français. Architecture et conception matérielle Le fournisseur retenu sera tenu de tester tout le matériel, le système O logiciel, les middlewares ainsi que des produits et autres équipements qui seront nécessaire pour la bonne marche du système. Les 3.16 soumissionnaires devront fournir des preuves ainsi qu'une garantie écrite assurant que l'équipement proposé prendra en charge le volume de travail prévu conformément au niveau de performance requis et que tout autre élément y répondant sera fourni par le soumissionnaire, sans aucun frais pour la BCM. 3.17 Architecture et conception matérielle - Architecture générale l'architecture matérielle du système ATS devrait reposer sur les O . principes suivants : 1. Les normes et standards approuvés par l'industrie ainsi que des plates-formes des fabriquants majeurs 2. Le matériel doit être ultra moderne et disponible dans la ligne de produit du fabriquant. Il doit être supporté par le fabriquant pour une période d'au moins cinq ans après son installation au sein de la BCM. Numéro en travers Condition critique Priorité Commentaires de réf. 3. Une solution de marque unique (dans la mesure du possible) afin de minimiser les coûts d'entretien. 4. Supporter des solutions logicielles modernes et évolutives afin d'améliorer les performances ou l'implémentation de nouvelles fonctionnalités (évolutivité verticale) 5. Offrir un haut niveau de disponibilité des services en utilisant des technologies modernes (haute disponibilité, mise en miroir des données, réplication, les composants de rechange, etc.) 6. La fourniture du matériel devra comprendre : a. Une infrastructure d'onduleurs UPS b. Une infrastructure réseau fiable et sécurisée, ainsi que des équipements permettant d'établir des connexions sécurisées pour les participants c. Une infrastructure reposant sur les technologies SAN (de préférence avec fibre optique ou le protocole iSCSI) d. l'installation des postes de travail pour administrateur e. L'installation des postes de travail pour les participants (les imprimantes y compris) aux standards industriels utilisés généralement et les plates-formes les plus usitées des principaux fournisseurs ; f. L'installation des équipements liés à la sécurité (jetons, cartes intelligentes (smart cards), HSM etc) 7. Le matériel devra se conformer aux critères de performances de la BCM, avec entre autre la capacité de stockage et les exigences liées au volume de traitement de transaction pendant au moins les cinq prochaine années à compter de l'installation. 8. L'architecture matérielle devra être intégrée à l'infrastructure existante de la BCM ainsi qu’à d'autres systèmes logiciels et matériels du SNP. Numéro en travers Condition critique Priorité Commentaires de réf. 9. Les servers ainsi que les autres équipements qui leurs sont associés devront être « rackables » 10. Les soumissionnaires devront donner des détails sur les exigences environnementales (climatisation, et espace), d'alimentation électrique pour tous les sites (production, reprise après sinistre et de formation/développement), d'équipements du côté des participants ainsi que des postes de travail des opérateurs. 11. Les soumissionnaires doivent détailler tous les éléments matériels à prendre en compte, nécessaire à l'exploitation de la solution proposée. Cela devra inclure des informations sur n'importe quel matériel qu’il faudra peut être installer par les organisations participantes. 12. Tous les composants du système seront suffisants pour son bon fonctionnement sans recourir aux mises à jour pendant une période d'au moins cinq ans à compter de la date des débuts des opérations et le matériel doit être dimensionné en conséquence. Les offres matérielles devront comprendre tous les services associés. 3.18 Caractéristiques des racks et serveurs Le matériel ATS devrait être livrés dans des racks qui devront inclure O des câbles, des systèmes de ventilation, etc. Les racks doivent contenir les éléments suivants : 1. Full height rack – 42 U 2. Moniteur KVM, 3. Clavier KVM 4. switch 5. Accessoire de distribution d’énérgie Numéro en travers Condition critique Priorité Commentaires de réf. 6. Onduleur d’une autonomie d’au moins 30 minutes (l’onduleur doit être dimensionné pour supporter tous les éléments qui s’y logent). 7. Un système de cooling propre à l’onduleur 8. Un système de monitoring de la température du rack. 3.19 Serveurs : 1. Les serveurs devront être systématiquement dupliqués et O configuré en utilisant la technologie de cluster afin de fonctionner en mode haute disponibilité. Le passage d'un serveur défaillant à un serveur d'archivage au niveau de chaque site (De production et de secours) devrait être automatique et sans interruption de service pour les participants du système. 2. chaque serveur doit être au minimum équipé d'une alimentation O redondante, d'une carte réseau gibabit redondante, un système de ventilation ainsi que des liaisons redondantes au système d'archivage. 3. Chaque serveur doit être équipé d'un système protégé de stockage O interne RAID qui sera utilisé pour la bonne opération des fichiers des systèmes 4. Tous les composants redondants du système devront être activés O automatiquement en cas de panne d'un composant primaire. Tous les composants redondants devront être échangeables à chaud et être capable d'être remplacés sans arrêter l'équipement et sans interruption de service pour les participants. 5. Il est recommandé que tous les serveurs utilisent la même version O du logiciel système pour les opérations Numéro en travers Condition critique Priorité Commentaires de réf. 6. Le système devrait provenir de l'un des fabriquants majeur avec O une expérience dans le support logiciel en MAURITANIE. 7. Le type de serveurs haut de gamme suivant sont attendus par ordre E de préférence : • HP • IBM 8. Les offres devront indiquer en détail tous les composants serveurs O proposé, ainsi que tout autre élément nécessaire pour une connexion au système d'information de la BCM. 9. Les serveurs doivent être dimensionnés pour fonctionner dans les régions tropicalisées. 3.20 Archivage de données : Le système d'archivage doit disposer d’un grand espace de stockage O ainsi qu'un niveau élevé de protection de données nécessaire pour cinq années de fonctionnement sans problème. Le système d'archivage devra être équipé de composants de rechange O semblable aux serveurs RTGS (disque durs, alimentations, contrôleurs, interfaces SAN) 3.21 Stockage de données : La solution d'archivage de données devra être basée sur les normes des O logiciels d'entreprise venant d'un éditeur majeur de logiciel. Le système d'archivage (lecteur de bande magnétique, par exemple) devra être offert avec l’ensemble des supports pour contenir 3 années d'archivage de données. Numéro en travers Condition critique Priorité Commentaires de réf. L'offre doit préciser en détail la capacité de stockage des données et O des équipements proposés. Ceci doit être appuyé par un dimensionnement minutieux, nécessaire pour contenir toutes les copies des données dans la base de données. Les commutateurs KVM pour écran et clavier devront être connectés O à tous les serveurs installés dans les racks, ainsi qu’à d'autre équipement réseau. Chaque rack devra avoir en sa possession un ensemble KVM dédié 3.22 Onduleurs UPS : L'onduleur doit être capable de fournir au moins 30 minutes environ O d'autonomie en production, pendant les procédures de récupérations ainsi que durant les procédures de test/développement des équipements de communication. 3.23 Équipement réseau : tout le matériel réseau nécessaire (commutateurs, routeurs, pare-feu, O serveurs d'accès) doit être fourni Les équipements réseau qui seront utilisés pour les sites opérationnels O primaires devront être configurés afin d'opérer en mode de haute disponibilité. Les équipements de rechange devront être activés automatiquement en cas de panne de l'équipement principal sans interruption de services pour les participants. Tous les câbles devront être dûment étiquetés. O Actuellement, la BCM utilise uniquement des routeurs et O commutateurs Cisco. Les composants de réseau concernés à fournir au titre du présent approvisionnement doit assurer l'interopérabilité et la compatibilité avec l'environnement réseau existant. Numéro en travers Condition critique Priorité Commentaires de réf. 3.24 Autre matériel : Le soumissionnaire devra inclure le matériel non mentionné ci-dessus O nécessaire à sa solution. 3.25 Caractéristiques des postes de travail Les postes de travail proposés doivent être en mesure de répondre aux O exigences de performance de la BCM ainsi que les exigences suivantes: 1. Utiliser le système d'exploitation Microsoft Windows avec licence OEM. 2. Format Mini Tour 3. Utiliser les navigateurs modernes, tels qu’Internet Explorer, Mozilla Firefox, etc. 4. Les écrans de type LCD doivent être au moins 17 pouces; 5. Les claviers devront être en français (AZERTY) 6. Memory: 8 GB 1600 MHz DDR3 7. Stockage: min 500 GB 7200 tour/min SATA 8. Lecteur optique: SATA Super-Multi DVD 9. Cartes réseaux Gigabit Ethernet ( minimum 2 cartes) si le logiciel proposé nécessite des utilisateurs de postes, les O soumissionnaires devront clairement indiquer en détail les configurations nécessaires des postes ainsi qu'un nombre suffisant d'unité qui permettra de répondre aux besoins énoncés. Caractéristiques de logiciel de participants : 3.26 En plus du logiciel requis à la BCM, les soumissionnaires devront O spécifier en détail, tous les produits logiciels (obligatoires et Numéro en travers Condition critique Priorité Commentaires de réf. facultatifs) qui pourront être installé si le besoin est, par chacune des organisations participantes ainsi que les exigences liées au Straight Through Processing (STP) Logiciel système : En plus du système d'exploitation du serveur, les propositions doivent O 3.27 clairement préciser dans les moindres détails tout autre logiciel système qui sera nécessaire pour la bonne marche des applications du système de paiement. Logiciel de base de données Les offres doivent énoncer tous les produits logiciels de gestion de O bases de données relationnelles (SGBDR) qui fonctionneront sur le système. Cela devrait inclure la version ainsi que des modules optionnels proposés, et (si souhaité) la solution de base de données (SGBDR) recommandée par le soumissionnaire. La base de données du système ATS devra utiliser des bases de 3.28 données relationnelles interopérables d'un éditeur majeur de système de gestion de base de données. Les soumissionnaires doivent fournir une description de chaque fonctionnalité du logiciel de gestion de base de données utilisé par leurs applications, par exemple la réplication automatique de la base de données afin de permettre la haute disponibilité. Générateur de rapport Les soumissions devront inclure des outils standards de génération de O 3.29 rapports de base de données qui seront facile à utiliser pour un développement rapide des rapports afin de satisfaire aux besoins qui pourront apparaître. Les soumissions devront également indiquer si ces Numéro en travers Condition critique Priorité Commentaires de réf. outils sont fournis en tant que partie intégrante du logiciel proposé ou offert séparément. - Le système ne doit pas permettre au générateur du rapport de mettre à jour la base de données. - Le système devrait également permettre aux utilisateurs de définir leurs propres rapports. Conception réseau Le système devrait être offert avec tous les équipements réseau ainsi O que les logiciels requis pour les trois sites : le site de production, le site de reprise après sinistre (secours), ainsi que le site de test et développement. Les soumissionnaires devront fournir tous les détails concernant l'infrastructure réseau : 3.30 1. Les spécifications de l'équipement 2. La conception du réseau avec schéma topologique et plan d'adressage IP 3. Les spécifications des protocoles de réseau (tels que VPN, le protocole NTP, pare-feu, etc.) 3.31 Redondance Tous les composants de gestion de réseau doivent être O systématiquement reproduits pour s'assurer qu'aucun point de défaillance n'existe Le câblage interne devrait employer des câbles de catégorie 6, et tout O l'équipement de réseau devrait supporter de Gigabit Ethernet. 3.32 Zones de réseau : L'infrastructure en réseau de l'ATS devrait être basée sur le LAN de la O BCM (VPN pour les sites distants) et fournir des zones de sécurité de Numéro en travers Condition critique Priorité Commentaires de réf. sorte que la violation de la sécurité d'une zone ne compromette pas la sécurité du reste du système. La sécurité de réseau devrait être assurée par firewalling des zones de réseau. Les serveurs et les postes de travail d'ATS ne doivent pas avoir de O connexion à l'Internet: plutôt toutes les ressources nécessaires (telles que LDAP, NTP, mail, etc.) doivent être disponibles localement 3.33 Interfaces externes : Les sites de production et de secours du système ATS auront les O interfaces suivantes : 1. Interfaces LAN de la BCM ; 2. connexions VPN interbancaires ; 3. Connexion SWIFT. Deux ports Gigabit Ethernet seront utilisés pour connecter O physiquement le site RTGS « au monde externe » au LAN BCM et au VPN interbancaire. Le type de VPN sera défini en collaboration avec le fournisseur de VPN. La plateforme SWIFT et l'adapteur SWIFT de RTGS doivent être utilisés pour connecter l'ATS à SWIFTNet aux sites de production et de secours. Des détails de connexion physique de SWIFTNet seront définis par la BCM en collaboration avec le fournisseur du réseau SWIFT. 3.34 Sécurité d'accès au système L'ATS devrait fournir la fonctionnalité pour le contrôle d'accès de O système. Toutes sortes d'accès (physique et logique) doivent être contrôlées et limitées. Le système devrait supporter le ` rôle créateur Numéro en travers Condition critique Priorité Commentaires de réf. et vérificateur ' pour le traitement des transactions si le STP n’est pas mis en œuvre. Tout accès doit être noté O 1. Authentification - peut être basé sur la combinaison de l'utilisateur/du mot de passe et/ou du certificat d'utilisateur. L'utilisation du mécanisme single sign-on est préféré (comme indiqué sous A à G) 2. Autorisation - mécanisme qui permet la gestion de privilège fine- grain et la gestion de profil pour des utilisateurs d'ATS. Les utilisateurs ne doivent pas pouvoir voir des options de menu pour les fonctions qu'ils ne sont pas autorisés à employer ; 3. Chiffrage - toutes les informations financières sensibles et les mots de passe d'utilisateurs dans la base de données doivent être stockés dans un mode chiffré irréversible 4. L'enregistrement d'audit de toute l'activité d'utilisateur dans le système devrait être disponible. (comme indiqué sous `a à c') L'architecture de sécurité l'ATS sera être basée sur une infrastructure O de clef publique afin de sécuriser tout accès et d'échange de données dans le système. Cette PKI sera livrée avec le système et sera partagée avec le dépositaire titre (CSD) 3.35 Audit de système Le système devrait fournir la fonctionnalité audit d'actions O d'utilisateurs'. Tout l'accès au système, des transactions manipulées par le système et O les changements affectant des contrôles d'accès, des paramètres Numéro en travers Condition critique Priorité Commentaires de réf. système, des répertoires et contrôles similaires et des fonctions d'intégrité devrait être noté et être accessibles pour la recherche autorisée L'enregistrement d'audit doit être également protégé contre l'accès non O autorisé et la délégation. Il ne doit pas être possible de changer le contenu d'aucun log d'audit. O L'information devrait être rapportée aux opérateurs de la BCM O quotidiennement. L'information précise à enregistrer dépend du type de transaction. O Chaque enregistrement dans l'enregistrement d'audit doit inclure, au minimum, l'utilisateur impliqué, l'action exacte effectuée, période de l'action, les données changées (avant et après). La fonctionnalité d'enregistrement d'audit devrait être donnée pour le O système central (ATS) ainsi qu’aux participants. 3.36 Chiffrage de données : Des modules pour le chiffrage des données seront déployés pour le O système afin de s'assurer que des données échangées entre les participants et le système ni ne sont changées ni lues par n'importe quelle partie non autorisée. Le système devrait s'assurer qu'aucun message ne peut être envoyé O dans un réseau non encrypté. Le chiffrage de message sera implémenté en plus, et indépendamment, O du service en réseau VPN. 3.37 Protection contre la perte, la modification, la répétition ou le reniement O Numéro en travers Condition critique Priorité Commentaires de réf. Car le système traitera des informations financières sensibles, le système devrait garantir qu'aucune transaction ne sera : 1. Perdue- le système devrait fournir le mécanisme interne pour éviter la perte de message dans au niveau du transport ou de l'application ; 2. Modifiée - des transactions financières doivent être protégées contre la modification pendant le transfert comme pendant le traitement par le système et le stockage dans la base de données après traitement ; 3. Répétée- le système devrait surveiller les instructions doubles qui peuvent se produire en raison des problèmes techniques comme dus à l'erreur d'un opérateur ; 4. Niée- le système se fondera sur PKI pour s'assurer que digitalement signées, les instructions de paiement exécutées sont finales, irrévocables ou testées. 3.38 Surveillance et mesure : 1. Tous les accès au système, des transactions manipulées par le O système et les changements affectant des contrôles d'accès, des paramètres de système, des répertoires et contrôles et des fonctions semblables d'intégrité doivent être notés et rapportés aux opérateurs de la BCM, et soient accessibles pour la récupération et l'analyse autorisées, quotidiennement. Il ne doit pas être possible de changer le contenu d'une notation d'audit ; 2. Les informations suivantes doivent être fournies : O a. Totaux de contrôle pendant une journée d’échange dans un endroit ; Numéro en travers Condition critique Priorité Commentaires de réf. b. Gestion de tous les utilisateurs du système (de la BCM et des participants) et de leurs privilèges d'accès ; c. Tentative d'accès rejeté aux postes de travail ; d. Le nombre, la fréquence et la source de transactions invalides et de fichiers ; e. Tous modèles de comportement peu communs par un utilisateur autorisé, indiquant le risque accru et/ou la fraude essayée. 3.39 Continuité du système : 1. Le système doit fournir le plus haut niveau de la disponibilité. Il O devrait donc être configuré de telle manière qu'il puisse récupérer automatiquement de n'importe quelle défaillance, et sans interruption de service ; 2. En outre, le système doit pouvoir compléter le traitement de toutes les transactions pour le jour dans un maximum de deux heures après fin de journée normale. 3.40 Résilience opérationnelle Tous les serveurs doivent être conçus et configurés pour fournir des O niveaux élevés de fiabilité, de résilience et de disponibilité. Le système du site de traitement primaire devrait maintenir le système du site alternatif mis à jour (et vice versa) en temps réel de sorte que, en cas d’une défaillance sur un site, l'autre site puisse continuer de traiter avec de préférence aucune intervention manuelle. En tant qu'élément du cycle normal d'opération, le système devrait être O régulièrement permuté entre les emplacements primaires et alternatifs pour examiner que tous les systèmes fonctionnent correctement. Quand le site alternatif agit en tant que processeur principal, il doit Numéro en travers Condition critique Priorité Commentaires de réf. maintenir la base de données au site primaire entièrement synchronisée. La préférence de la BCM est pour que les deux sites fonctionnent de O telle manière que les deux emplacements exécutent le service de phase avec la répartition de la charge de traitement (ou l'équivalent) entre eux. De cette façon, une défaillance d'aucun serveur, sur le site primaire ou alternatif, n'interrompra pas le fonctionnement du système. 3.41 Environnement de test/de développement : La solution d'ATS devrait inclure l'environnement à employer pour O tester et développer le système. La plate-forme de test devrait être entièrement identique à celle de production du point de vue fonctionnel. Un environnement de test devrait être disponible à tout moment pour O prendre en compte les tests des changements de système prévus (installation de nouveaux patches), ou de test de l'interface du participant. Les soumissionnaires doivent décrire comment ils accompliront les tâches principales suivantes : 1. Gestion des changements impliquant le matériel, le logiciel système et le logiciel d'application, couvrant tous les participants comprenant la BCM et les banques ; 2. Opération des composants de système ci-dessus ; 3. Essai des modifications de paramètre apporté par l'opérateur du système. On s'attend à ce que l'installation initiale du système suive ce processus. 3.42 Performance du système La conception de système devrait incorporer `' l'évolutivité verticale et O horizontale `'. Numéro en travers Condition critique Priorité Commentaires de réf. 1. L'évolutivité horizontale devrait être fournie par le logiciel système et le matériel. 2. L'évolutivité verticale devrait être supportée par l’architecture matérielle. Le système devrait pouvoir manipuler les volumes prévus de O transactions sans dégradation de toutes les autres fonctions système Le système devrait répondre aux critères suivants, mesurés aux sites O de la BCM : 1. 95% (par le nombre) de transactions de paiement et de requêtes en temps réel simples devrait être accompli dans 600 ms pendant le trafic maximal ; 2. Le temps de réponse maximum de connexion au RTGS ne doit pas dépasser 8 secondes ; 3. Le temps de réponse maximum pour la reconnaissance d'arrivée de message ne devrait pas dépasser 6 secondes ; 4. Le temps de réponse maximum pour l'avis de la livraison de message ne devrait pas dépasser 10 secondes. Les soumissionnaires doivent indiquer si et dans quelle mesure O l'infrastructure réseau existante doit être améliorée pour réaliser ces normes. 3.43 Réplication de données Le système devrait fournir la réplication de données de la base de O données de production à la base de données de secours sur le site de récupération après sinistre. Le système met en place la surveillance des données pour sauvegarder la base de données de production. Numéro en travers Condition critique Priorité Commentaires de réf. En mode de surveillance chaque ensemble de transactions est validé simultanément dans les bases de données de production et de support (de réserve), de sorte que les deux soient synchronisées automatiquement. Il est recommandé que le système se fonde sur des outils et des fonctions de réplication fournis par le SGBD pour monitorer les données. La base de données de récupération peut être peuplée en envoyant des O copies des instructions de participants' ou par production des logs de changements de la base de données. La conception de système s'assurera que la base de données du site de O récupération des pertes sera synchronisée avec la base de données de production en cas de n'importe quelle défaillance de ce dernier (au moyen de transfert de données électroniques ou médias physiques). Les fournisseurs doivent décrire les options de réplication de données O mises en application par leurs systèmes. Des procédures de réplication et de restauration de données doivent documenter de manière claire et exhaustive et totalement tester, et le personnel responsable de la BCM devrait être bien formé. 3.44 Défaillance du site principal de l'ATS Le système doit fournir le plus haut niveau de disponibilité, et doit O pouvoir récupérer n'importe quelle défaillance dans un maximum de deux heures. Il devrait inclure la fonctionnalité nécessaire pour supporter le plan d'urgence avec les caractéristiques suivantes : 1. En cas de défaillance mineure ou partielle, le service devrait O demeurer sur le site de production en utilisant le matériel et le logiciel de secours et/ou la base de données de secours ; 2. En cas de défaillance majeure sur le site de production, si le O service ne peut pas reprendre en utilisant des moyens de secours Numéro en travers Condition critique Priorité Commentaires de réf. sur le site de production, le site de secours devrait assurer toutes les opérations pendant le temps nécessaire pour réparer le site de production. Le procédé de changement devrait normalement prendre 30 minutes et devrait exiger l'intervention minimum d'utilisateur. 3.45 Défaillance de la plate-forme du participant La conception de système devrait inclure des méthodes facultatives de O sauvegarde des participants. En cas de défaillance du site primaire de travail ou du sous-système d'un participant, le site de secours devrait être activé. La BCM peut mettre en application un service bureau ' à ses site pour O des participants sans moyens de secours. Un service bureau est un ensemble site de travail de participants ' situés aux sièges sociaux de la BCM qui fournissent le même niveau de fonctionnalité que les sites de travail standard sauf qu'ils peuvent être partagés par plusieurs banques. Le LAN du service bureau sera relié au réseau de production de l'ATS O et aux emplacements de recouvrement des pertes. 3.46 Gestion technique (administration et surveillance opérationnelle) : La solution d'ATS doit inclure tous les composants exigés pour O l'administration et la surveillance technique. Les sites de travail administratifs de système doivent être faciles à utiliser et ne doivent pas exiger des qualifications spéciales des administrateurs du SNP. Les instruments suivants doivent être fournis avec le système : 1. Instruments pour contrôler le lancement du système, l'arrêt, l'entretien, le support de données et le failover au site de secours ; Numéro en travers Condition critique Priorité Commentaires de réf. 2. Outils pour la surveillance technique de tous les composants de système (caractéristiques de fonctionnement, consommation etc. de capacité de traitement) ; 3. Outils pour la gestion de la configuration de système ; 4. Outils pour la gestion de sécurité d'application ; 5. Outils pour le dépannage de système. Les soumissionnaires sont tenus de fournir la documentation appropriée qui contient la description détaillée des procédures de gestion-système. 3.47 Gestion des données (données historiques et archivage) Le système devrait inclure l'instrumentation pour la gestion des O données qui fournit les spécificités suivantes : 1. Commande d'uniformité de données au niveau applicatif dont le système d'aide reprend ses opérations en cas de défaillance 2. Dispositifs et instruments d’historiques de gestion de l'information. L'information historique devrait être disponible sur des sites de travail de l'ATS dans le mode inaltérable. Le système d'ATS devrait inclure des mécanismes pour assurer O l'uniformité de données. Le mécanisme de commande d'uniformité devrait être activé automatiquement lors du démarrage du système ou manuellement à partir des sites de travail administratifs de l'ATS. 4. Dépositaire central de Titres, DCT (CSD) N° en Condition Critique Priorité Commentaires Travers de réf 4.1 Principes de conception pour le système CSD : Le but primaire du CSD sera de permettre d’avoir un registre précis des O transactions concernant les titres sur les marchés monétaires et financiers. A cet effet il y’aura trois modules principaux ; Dépôt, marché primaire (enchères) et marché secondaire (commerce) Les composants du CSD doivent être considérés comme composants d'un O système unifié et en tant que tels doivent être basés sur la meilleure pratique internationale et être conformes aux principes suivants : 1. Se conformer aux conventions standards de l'industrie et des interfaces O qui permettent au système d'être interfacé facilement avec d'autres systèmes, et / ou élargi soit par module fonctionnel ou par la capacité; 2. Offrir un coût bas et une facilité dans la mise en œuvre des O raccordements techniques pour les sites participants externes soit sur un terminal distant ou hôte-à-hôte pour l'ensemble du trafic du système; 3. Supporter différents et multiples rôles des participants tel que : O a. Conservateur ; b. Courtier (agent d’échange); c. Émetteur ; d. Administrateur ; e. Régulateur/contrôleur ; f. Bénéficiaire ; g. Titulaire. Le système doit en outre supporter différents types d'utilisateur comprenant, O y compris les Négociants : 1. Négociants agissant en tant que bénéficiaire ; 2. Négociants agissant pour le compte d’un autre bénéficiaire; 3. Les activités menées par des négociants doivent être enregistrées dans la catégorie « type commerce ». Chaque commerçant doit être en mesure d'agir dans les deux sens. 4. Capacité à gérer des obligations à taux fixe et de la révision du taux des O obligations à taux variables selon les algorithmes déterminés par les autorités de délivrance. 5. Capacité à gérer des obligations à taux fixe et de la révision du taux des O obligations à taux variables selon les algorithmes déterminés par les autorités de délivrance. 6. Le montant de l'intérêt doit être réconcilié par rapport au portefeuille original d’émission et transmis à l'ATS pour le paiement au propriétaire bénéficiaire concerné par le truchement du compte de l'intermédiaire ou de la banque commerciale des bénéficiaires. 7. Tenir à différentes niveaux, un registre de l'ensemble des contreparties O (détenteurs de valeurs mobilières et les courtiers), en précisant si le déposant est direct ou indirect, et toutes les informations pertinentes statiques telles que: nom, adresse physique, adresse e-mail, téléphone, numéro d'immatriculation fiscale, etc. Tous les contreparties doivent être identifiés par des codes qui permettront de faciliter la recherche de ces informations; Possibilité que le même emprunt obligataire soit ré-ouverte aux souscriptions ultérieures jusqu'à ce qu'un volume prédéterminé de souscriptions soit atteint. Dans ces cas, le CSD doit mettre à jour toutes les données appropriées d'identification et de synthèse d’émission, y compris les nouvelles souscriptions à l’occasion de la prolongation ou de la réouverture de la procédure. 8. Capacité à gérer des conventions de rachat (y compris la capacité à gérer O plusieurs titres en une seule prise en pension) en enregistrant le changement de propriété et l'obligation associée à des prises en pension en nombre de jours convenu. La mise en pension ne peut pas arriver à maturité après celle d'un des actifs sous-jacents. 9. Permettre une personnalisation facile des paramètres en tenant compte O de nouvelles règles qui régissent les différentes fonctions, par exemple créer un nouveau type de message, créer un nouveau type d’instrument, etc; 10. Permettre à la BCM de définir et gérer son propre portefeuille d'actifs O financiers. 11. Prise en charge de la classification des différents types de O l'utilisateur / Trader, y compris, pour négociants: a. Négociant agissant en tant que Bénéficiaire; b. Négociant agissant pour le compte d'autres Bénéficiaire; c. Les activités menées par des négociants doivent être enregistrées dans la catégorie « type commerce ». Chaque négociant doit être en mesure d'agir dans les deux sens. 12. Avoir une application de règlement étroitement liée avec le O composant d'ATS, pour le règlement des opérations des marchés primaires et secondaires, opérations de marché libre de la BCM et opérations intra journalières de liquidité, afin de garantir que les principes de la livraison contre le paiement (DvP) et le traitement de bout en bout (STP) sont respectés. Cette application de règlement devrait également servir à payer des intérêts et des maturités sur des titres de créance ; 13. Intégrer une capacité à gérer le marché primaire de l'émission de O toutes valeurs mobilières pertinentes; 14. Intégrer une plate-forme électronique secondaire de négociation sur O un marché des titres; 15. Être capable de prendre en charge une connexion à tout futur système de négociation électronique interbancaire des titres pouvant servir de collatéraux, en mettant en application les principes de DvP et STP ; 16. Adhérer aux formats de messages ISO 15022 afin de garder la O conformité avec les normes internationales pour les messages générés, tel que prévu par les normes recommandées par la BRI; 17. Fournir une vue unique et intégrée de la position de chaque négociant O pour le suivi, la supervision et le contrôle de la liquidité de chaque concessionnaire; 18. Générer des rapports de synthèse et détaillés avec la capacité de O disposer d’un aperçu avant impression et d’une fonction d’exportation vers les applications externes; 19. Permettre les enquêtes par la BCM et le ministère des finances ; 20. Pouvoir connecter l’application à d’autres plate-formes de O négociation et des systèmes dépositaires au fur et à mesure qu'ils sont intégrés. 4.2 Enregistrement des détenteurs Les détenteurs doivent être uniques dans le système. L’enregistrement du détenteur contiendra des informations basiques aux fins de s’assurer que n'importe quel détenteur est enregistré une seule fois dans le système. Les courtiers s’attendront à ce que cette information soit mise à jour, mais une information supplémentaire pourrait être maintenue sur leurs systèmes connectés à l’enregistrement du détenteur dans le CSD. L’enregistrement du détenteur doit inclure : 1. Une identité de l’utilisateur (UID) qui est unique dans le système, et O a la capacité d'être validé à l'aide d'une routine de validation appropriée 2. Des champs de contact normal tel que le nom, prénom, adresse, O numéro de téléphone et adresse e-mail, dont chacun est consultable; 4.3 Fonctionnalité du propriétaire bénéficiaire et détenteur O .La fonctionnalité suivante doit être disponible : 1. Un négociant doit être en mesure d'afficher uniquement les véritables O propriétaires et détenteurs pour lesquels ce courtier est le dépositaire; 2. Toute instruction de mouvement des valeurs mobilières doit O mentionner le véritable propriétaire et les références du détenteur; 3. Le système doit être capable de générer des messages au véritable O propriétaire bénéficiaire et / ou le détenteur quand un mouvement de valeurs mobilières a eu lieu; 4. Les agents BCM autorisés doivent être en mesure de voir toutes les O possessions dans le CSD par propriétaire bénéficiaire et détenteur ; 5. Il doit y avoir une fonction de vérification de la présence possible de O doublons afin de réduire la possibilité qu'une personne soit plus d’une fois enregistré comme détenteur ; 6. Le système doit avoir la capacité de calculer les obligations fiscales O en fonction des paramètres définis sur l'UID individuel. 4.4 Module primaire des enchères La CSD doit contenir un module principal intégré pour gérer le marché des O titres publics. Ce module principal d'enchères devrait inclure les fonctionnalités suivantes : 1. Acquisition des offres soumises électroniquement, par émission, des O participants à partir de sites distants (via des connexions de télécommunications sécurisées), avec affichage de ces offres dans le système jusqu'à ce que le délai officiel de clôture des offres est atteint. Les soumissions reçues ne doivent pas être consultables tant que la clôture des soumissions n’est pas prononcée. 1. La capacité pour que la BCM fixe des limites sur la valeur totale des O offres à accepter de chacun des soumissionnaires sur une émission particulière quelconque. 2. La possibilité d'inclure ou d'exclure un soumissionnaire enregistré de sorte que certaines émissions peuvent être limitées à un sous-ensemble de tous les soumissionnaires enregistrés sur le marché 1. La possibilité de calculer l’acceptation et le rejet des offres selon les O prix des offres les plus élevées et la valeur totale et la composition de l’émission à allouer aux adjudicataires. 3. La clôture automatique de la réception dès que la durée paramétrée par le système pour cette émission est atteinte. Ce délai pour le dépôt des offres doit être paramétré au niveau de l'écran par la BCM, pour chaque émission 4. Le système d'appel d'offres doit être capable de s'adapter à la fois à des O enchères à prix multiples ou à prix unique. 5. Sur le prix de soumission à la clôture, le système de négociation du marché primaire doit calculer l’attribution de l’émission aux soumissionnaires retenus selon les prix offerts, adaptée aux limites financières du soumissionnaire. 6. Il doit pouvoir déterminer un pourcentage de l’émission qui peut être réservée en vente spéciale à d'autres candidats qui ont proposé des offres moins disantes. 4.5 Module de Marché secondaire Le CSD doit inclure un module pour contrôler un marché secondaire des valeurs de secteur public. Les offres doivent contenir des informations complètes sur un module de négociation électronique pour les opérations du marché secondaire pour la compensation et le règlement des échanges : 1. Les opérations d’achat/vente sont soumises électroniquement via des connexions de télécommunications sécurisées à la BCM pour le règlement et la compensation (DVP). 2. Le système doit supporter l'architecture 3 tiers avec l'accès à l'information basé sur un accès WEB au système, avec un écran normalisé pour l'achat/vente des titres du gouvernement créant de ce fait un marché au comptant. 3. Les écrans doivent inclure mais sans s'y limiter, les renseignements O suivants : nom d'acheteur, nom de vendeur, quantité, prix, date commerciale, échéance, nom du titre, numéro d'identification unique de valeurs, nom de la banque débitrice, numéro de compte à la banque débitrice, numéro de compte de client, nom du client. 4. Heures de Clôture automatique et calendriers de négociation maintenus sur la plate-forme marchande comme établi par la BCM. 5. Un très haut niveau de disponibilité et de fiabilité; O 6. Garantie d’aucune perte de données aussi bien lors de la transmission O qu’après une défaillance. 5. Service et support La table ci-dessous contient une liste de service et de support y compris les exigences de gestion de projet pour la mise en marche du projet. Vous êtes prié de s'y conformer ou pas et le préciser dans la colonne réponse. Dans la colonne commentaire, décrivez s'il vous plaît comment vous comptez réaliser chaque besoin. Si la table ne permet pas d'écrire vos commentaires, vous pouvez utiliser votre propre format pour expliquer en détail, en y inscrivant un numéro de référence. Vous êtes également prié de mentionné d'autre besoins liés au service offert nécessaire à la réalisation du projet. Numéro de Condition Priorité Réponse relatée du soumissionnaire référence 5.1 Gestion du projet La solution offerte doit garantir que chaque étape de O configurations, paramétrage/personnalisation, de test, de conversion/migration, d'intégration et d'implémentation y compris de formation, doit être effectuée comme convenu avec la BCM et devra respecter les délais convenus avant le début du projet. On s'attend à ce que la participation du soumissionnaire à cette activité soit un facteur de réussite déterminant. Le soumissionnaire doit préciser en détail son rôle afin de garantir que l'opération de configuration, de migration et de mise en œuvre marche convenablement. 5.2 Gouvernance du Projet les attentes de la BCM concernant l'ensemble de la E gouvernance du projet sont détaillées ci-dessous. Les soumissionnaires sont tenus de se prononcer sur le projet de gouvernance proposé par la BCM et de proposer des variantes ou modification comme bon leur semble. Les soumissionnaires devront décrire leur processus de O gestion de projet, ainsi que leurs procédures afin d'assurer une révision continue efficace de l'état d'avancement du projet ainsi que des décisions opportunes sur les questions qui peuvent avoir une incidence sur les résultats attendus et le planning. Pendant toute la période d'exécution du projet, le Directeur O de projet du fournisseur soumettra au Directeur de Projet de la BCM un rapport mensuel portant sur l’état d’avancement du projet. 5.2.2 Organisation de l'équipe de projet Pour assurer un transfert maximum de connaissances, O l'équipe de projet du fournisseur doit être organisée de manière à travailler avec ses homologues au sein de la BCM. Le Directeur de projet du fournisseur agira par le biais du O directeur de projet de la BCM. Les soumissionnaires sont invités à décrire : 1. L'organisation de leur équipe de mise en œuvre proposée O 2. Les rôles et responsabilités des membres de leur équipe O 3. Leurs attentes par rapport à l'organisation et à la gestion E de l'équipe de la BCM ainsi que les rôles et responsabilités. Les offres devront comporter les CV de l'ensemble du O personnel clé proposé. Les soumissionnaires sont tenus de fournir un curriculum vitae du chef de projet ainsi que du personnel technique et devront rendre disponibles ces personnes pendant la durée de vie du projet. Le fabriquant doit garantir un support continuel pendant la O phase de personnalisation et d'intégration tout en maintenant un niveau d'expertise approprié. Dans le cas où une de ces personnes devient indisponible, le O fournisseur devra nommer des une ou des ressources alternatives ayant au moins les mêmes compétences et expérience, ceci avec le consentement de la BCM. 5.3 Services de conseil : A la lumière du fait que l'acquisition de l'ATS est un nouveau O développement pour la BCM et que la BCM a par conséquent très peu de connaissance et d'expérience dans ce domaine, la BCM s'attend à ce que le soumissionnaire retenu fournisse un haut niveau de conseil en plus du support technique tout au long de la durée du projet, en utilisant son expérience internationale dans la mise en œuvre des systèmes de paiement. Les offres devront donc inclure des propositions concrètes dans ce domaine, en couvrant spécifiquement des aspects tels que l'élaboration de règles et procédures opérationnelles, les régimes de tarification du système ainsi que d'autres domaines où le soumissionnaire estime qu'il peut offrir des conseils sur les bonnes pratiques et éviter les pièges. 5.4 Plan du projet : Le soumissionnaire retenu devra produire, maintenir et O communiquer un plan de projet détaillé de tous les éléments du projet qui montre clairement les attentes sur une échelle de temps. Les soumissionnaires devront inclure un plan de projet O réaliste préliminaire décrivant les méthodes leur permettant de mener à bien l'ensemble des responsabilités liées à la gestion et la coordination en cas d’attribution du marché, des ressources humaines et autres, qu'il se propose d'utiliser. Le plan de projet préliminaire doit indiquer ce qui est attendu O de l’équipe de la BCM en terme de charge de travail lors de la mise en œuvre et comment le soumissionnaire se propose de coordonner les activités de toutes les parties concernées le plan préliminaire du projet doit contenir un calendrier O détaillé du déploiement du personnel professionnel, par exemple un calendrier de répartition par personne / spécialité du personnel proposé pour la durée du projet. Ce planning doit indiquer pour chaque membre de l'équipe, une charge de travail (par date, durée, et activité prévue) sur le projet ATS repartis entre le temps passé sur place à Nouakchott et le temps passé hors site. 5.5 Conception du système Le soumissionnaire retenu devra produire un document de O haut niveau sur la conception du système afin d'inclure toutes les phases de la mise en œuvre du projet. Ce document sera soumis à une approbation officielle de l'équipe de projet de la BCM 5.6 Personnalisation du système le soumissionnaire devra décrire la méthodologie de O développement du système à utiliser dans la personnalisation de la solution logicielle proposée. Les offres incluront la confirmation des besoins des utilisateurs pour la personnalisation, la construction et les tests, la documentation et les tests ainsi que le déploiement. 5.7 La migration des données Pendant cette phase, le soumissionnaire retenu devra O travailler avec la BCM dans le transfert de données à la fois statiques et dynamiques des systèmes existants vers les nouveaux systèmes. Cela exigera du soumissionnaire retenu d'avoir identifié ces données dans les phases antérieures, de conseiller et de travailler avec la BCM afin de s'assurer que toutes les données nécessaires sont migrées. 5.8 Installations et tests de recette : Cette phase couvre tous les aspects de la mise en œuvre, y O compris l'installation à la BCM ainsi que dans les banques et autres institutions participantes au besoin. Il comprend également la formation de tous les personnels, le développement de la documentation, et les tests de bout en bout, en impliquant progressivement tous les participants par le biais de la recette définitive du système 5.9 Général Le processus d'installation et d'essai O 5.10 Test de validation Le fabriquant doit fournir des plans de test standard et O exécuter des scripts associés afin de démontrer la mise en œuvre du logiciel de base. Le fabriquant doit gérer toutes les phases de test du projet, y O compris la phase des tests unitaires, fonctionnels, systèmes, intégrations, volumes/charge, plan de secours et tests de réception définitive, avec l'aide de l'équipe de mise en œuvre du projet à la BCM. 5.11 Situation des tests de validation O Les tests de validation et de conception : tous les tests de validation seront effectués par les équipes O opérationnelles de la BCM et le personnel technique, et seront surveillés et pris en charge par le fournisseur à chaque étape 5.12 Correction des défauts Le fournisseur sera responsable de la correction de tous les O défauts trouvés lors de la validation des tests en moment opportun afin que le programme du projet dans son ensemble ne soit pas affecté 5.13 Basculement du système et support sur site Après avoir réussi tous les tests, la validation opérationnelle O et formelle de tous les systèmes par la BCM ainsi que les institutions participantes, le système va basculer en mode de production 5.14 Période de garantie Cette phase durera 36 mois après la validation opérationnelle. O Au cours de cette période, le soumissionnaire fournira des services de garantie. 5.15 La formation Les soumissionnaires doivent décrire tous les modules de O formation proposés, le nombre de personnes qui auront besoin d'être formés et ainsi que la durée de chaque module de formation Les fournisseurs doivent préciser les conditions qui doivent O être remplies avant le début de la formation. Les propositions de formation doivent concerner non seulement la BCM, mais toutes les organisations participantes. La formation devrait inclure des modules spécifiques pour : 1. Le personnel de gestion à la fois pour la BCM et les participants 2. Le personnel de supervision et d'exploitation pour la BCM et les participants 3. Le personnel d'audit 4. La formation technique et opérationnelle pour les formateurs 5. La formation technique pour le personnel de développement des systèmes et de test 6. Formation technique pour le personnel d'exploitation du système et d'entretien 7. formation pour la création de rapports et dans l'utilisation de tout générateur de rapport 8. Toute autre formation importante pour les utilisateurs : 1. Le matériel, système d'exploitation et le matériel de communication livré 2. Le système de gestion de base de données utilisé par les systèmes ATS et CSD Veuillez joindre les détails du plan du cours de la formation 5.16 Transfert de connaissance Les soumissionnaires doivent décrire en détail comment ils O comptent atteindre un degré élevé de transfert de connaissances. Les soumissionnaires doivent conduire des formations pour O la BCM et pour le personnel technique de l'implémentation et de l'exploitation afin de simplifier le transfert de connaissance. 5.17 Documentation Tous les documents doivent être en français et adaptés aux O besoins de la BCM. Ils devraient comprendre au minimum : o Documentation du produit o Guide utilisateur o Règles et procédures opérationnelles o Documentation technique o Documentation des processus opérationnels 5.18 Période de garantie O Le support opérationnel sera assuré par le fournisseur sur le site principal et sur le site de secours durant la période d’implémentation pendant les trois premiers mois suivant la réception du système Le support à l’ATS et au CSD sera fourni gratuitement après O la réception des systèmes sur une période de trois ans (période de garantie). Durant la période de garantie, le fournisseur devra offrir un support complet (assistance technique et matériel) afin d’assurer un fonctionnement sans interruption du système fourni (matériel, réseau, système d’exploitation, système de gestion de bases de données, logiciel d’application, etc.). Les heures de fonctionnement du système et le temps de prestation de service seront négociés avec le soumissionnaire retenu. Les soumissionnaires sont tenus de présenter lors des négociations avec la BCM, le niveau de service qui devra être respecté. 5.19 Centre de service de maintenance Au cours de la période de garantie, le fournisseur établira un O point de contact unique pour tous les problèmes liés au matériel, au logiciel ou tout support connexe. Le point de contact sera disponible tout au long de la journée O d’échange (07.00 à 19.00, de lundi à samedi, exception faite des jours fériés). Les termes relatifs aux heures supplémentaires de support, seront convenus à l’issue des négociations. Les soumissionnaires devront inclure à leurs propositions l’avant-projet des termes applicables. Durant la phase d’installation et de test, les ingénieurs support O devront être disponibles immédiatement après qu’ils aient été appelés, durant les heures de services réglementaires en MAURITANIE 5.20 HelpDesk (Assistance) Le fournisseur devra assister la BCM dans la mise en place O d’un service Helpdesk. Ce service devra fournir le support de niveau applicatif à tous les utilisateurs durant la journée d’échange. Les propositions devront contenir les recommandations pour la mise en place et la gestion du service HelpDesk, incluant la formation du personnel, la documentation, les procédures opérationnelles, etc. 5.21 Reporting d’incidents : Les soumissionnaires doivent également expliquer comment O le personnel de la BCM peut surveiller et signaler régulièrement les incidents. 5.22 Gestion des changements et des configurations Les soumissionnaires devront décrire leurs technologies de O mise à niveau tant du matériel que du logiciel durant le cycle de vie du système afin d’assurer une formation complète sur les changements et améliorations, et la continuité de service pendant les mises à niveau 5.23 Maintenance de logiciel O Tous les codes sources détenus par le fournisseur, que ce soit pour des applications standard ou de modifications spécifiquement développés pour la BCM seront déposés chez un tiers de confiance. 5.24 Licence de logiciel La BCM exige une licence unique pour les logiciels installés O sur les sites principal, de secours et de test/développement….. 5.25 Accord de niveau de service (SLA) La BCM exige un très haut niveau de fiabilité et de O disponibilité du système. Le système devra fonctionner sur deux sites afin d’assurer un haut niveau de fiabilité et de disponibilité. Après la période de garantie, la BCM va conclure une convention de service (Service Level Agreement SLA) avec le fournisseur. Les attentes de la BCM sur l’accord de niveau de service comprennent : 1. Pour le logiciel, il n'y aura pas plus d'un total de trois O défaillances logicielles sur une période de 12 mois, et pas plus d'une défaillance dans un mois donné. Une défaillance logicielle est définie comme étant un événement où une composante de l'application ne répond pas aux instructions de l'opérateur et ne parvient pas à remplir sa fonction normale, et nécessite un redémarrage manuel ou ne parvient pas à redémarrer. Dans tous les cas, le temps de reprise sur incident ne doit pas dépasser 30 minutes 2. Pour le matériel et le logiciel du système, l'attente de la O BCM en rapport avec la disponibilité du système est de 99,5 % (où les temps d'arrêt sont définis comme une indisponibilité totale du système). Les soumissionnaires sont priés de fournir des détails sur la fiabilité attendue en chiffres indiquant la disponibilité pour la configuration (matériel, logiciels, etc.) qu'ils proposent pour le système RTGS 3. Les soumissionnaires devront joindre à leur proposition O d'appel d'offres un modèle de convention de services basé sur les critères cités ci-haut. Infrastructures A. Serveurs : N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement Serveur : A.01 ▪ Marque ▪ Modèle ▪ Quantité Processeur : ▪ Type A.02 ▪ Fréquence (gigahertz) ▪ Nombre de processeurs ▪ Nombre maximum de processeur pouvant être contenus Mémoire : ▪ Mémoire cache ▪ RAM (gigaoctet) ▪ Extensibilité de RAM (Go) A.03 ▪ Type de mémoire (SDRAM/ECC/EDO.) ▪ Nombre total de slots pour mémoire ▪ Nombre de slots inutilisés (slots pour mémoire) ▪ Vitesse du bus avant (MHz) Architecture A.04 ▪ Bus local (PCI/PCIx) ▪ Bus de données (BCI/PCIx) A.05 Contrôleur SCSI N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement ▪ ContrôleurUltra/Wide SCSI intégré (oui/non) Nombre de ports : A.06 ▪ Parallèle ▪ Série ▪ USB Contrôleur RAID (oui/non) A.07 ▪ Nombre de canaux ▪ Niveaux de RAID supportés(0,1,10,5) ▪ Taille du cache (MB) Disque dur ▪ Nombre de disques durs ▪ Capacité de chaque disque (gigaoctet) ▪ Type (SCSI pouvant être branché à chauds) A.08 ▪ Nombre maximum de disque pouvant être branchés à chaud ▪ Capacité maximum de disque pouvant être supportée ▪ Temps d'accès des disques (ms/rpm) Disquette A.09 ▪ Type ▪ Capacité Moniteur A.10 ▪ Type (LCD/CRT) ▪ Dimensions(pouces) ▪ RAM vidéo (MB) Lecteur optique A.11 ▪ Type (SCSI/IDE) ▪ Lecteur CD-RW DVD-ROM (oui/non) N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement Lecteur de bande magnétique A.12 ▪ Type (DAT/DLT) ▪ Capacité (gigaoctet) Carte réseau A.13 ▪ Nombre de cartes ▪ Modèle et type (intégré ou amovible) ▪ Vitesse (10/100/1000 Mbps) Dispositifs d'entrée A.14 ▪ Clavier standard (USB,…) ▪ Souris standard (USB….) BIOS A.15 ▪ BIOS Flash (oui/non) ▪ Pouvant être branché à chaud (oui/non) Nombre de slots d’extension A.16 ▪ PCI ▪ PCI/ISA partagé ▪ Autre (AGP etc.) Systèmes d’exploitation avec licences A.17 d’exploitation (Unix est obligatoire) (Prière de mentionner le nom et la version) Autres systèmes d’exploitation utilisés A.18 (Prière d’énumérer) Mécanismes de sécurité ▪ Complexité des mots de passe (oui/non) A.19 ▪ Mot de passe administrateur (oui/non) ▪ Contrôle de la procédure de démarrage (oui/non) N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement ▪ Protection de la disquette de démarrage (oui/non) Dispositifs matériels additionnels A.20 ▪ Contrôleur RAID rédondant (oui/non) ▪ Alimentation électrique redondante (oui/non) ▪ Ventillateur rédondant (oui/non) A.21 Rackable (oui) Tension d'alimentation (220V C.A., 50Hz A.22 (oui/non) A.23 Cable d’alimentation électrique : Câble d’alimentation de type Schuk A.24 (oui/non) Documentations : CD contenant les pilotes, disquettes, outils logiciel de diagnostic, manuels A.25 d’utilisation, fiche technique, etc. (oui/non) Prière de préciser A.26 Autres dispositifs – Prière d’énumérer B. Composants logiciels système Tableau 8 N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement Système d'exploitation pour clients (Windows B.01 obligatoire) (Spécifier la version du SE) Système d'exploitation pourserveurs (Unix B.02 obligatoire) (Spécifier la version du SE) Système de gestion de bases de données proposé B.03 (système de gestion de bases de données relationnelles - obligatoire) Nom et numéro de version du Système de Gestion de B.04 Bases de Données proposé Indiquer toute dépendance matérielle et système des B.05 composants logiciels système mentionnés B.06 Specifier l’utilitaire generateur de rapports Documentations : CD contenant les pilotes, disquettes, outils logiciel de diagnostique, manuels B.07 d’utilisation, fiche technique, etc. (oui/non) Prière de préciser Toute autre exigence logicielle système devra être B.08 mentionnée par le soumissionnaire C. PC & Scanners Tableau 9 N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement Ordinateur : Marque C.01 Modèle Quantité (50 postes de travail/PCs) Type : C.02 Ordinateur de bureau/tour Processeur C.03 Type (Pentium.) Fréquence (gigahertz) Mémoire Mémoire cache (KB) Capacité de la RAM (MB) C.04 Extensibilité de la RAM (MB) Nombre total de slots pour mémoire Nombre de slots libre (slots pour mémoire) Vitesse du bus avant (MGz) Nombre de ports Parallèle C.05 Série USB N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement Disque dur C.06 Interface (IDE/SATA etc.) Capacité (Go) Disquette C.07 Type Capacité Moniteur Type (affichage à cristaux liquides) C.08 Dimensions (pouces) RAM vidéol (MB) C.09 Lecteur optique - vitesse et type (boîte) Carte réseau Type (intégré ou amovible) C.10 Marque/modèle (SMC/3Com/NE2000/…) Vitesse (10/100/1000 Mbps) Périphériques d’entrée C.11 Clavier standard Azerty (oui/non) Souris standard (oui/non) BIOS C.12 BIOS Flash (oui/non) Pouvant être branché à chaud (oui/non) Nombre de slots d’extention C.13 PCI N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement Autre (AGP) Système d’exploitation Windows préinstallé avec licence d’exploitation. CD et documentation C.14 (obligatoire) Licence (oui/non) Mécanismes de sécurité C.15 Contrôle de la procédure de démarrage (oui/non) Dispositifs matériels additionnels C.16 Kits Haut-parleur (interne, etc.) C.17 Câble d’alimentation : C.18 Câble d’alimentation de type Schuko (oui/non) C.19 Tension d’alimentation (220V C.A., 50Hz) (oui/non) Documentations : CD contenant les pilotes, disquettes, outils logiciel de diagnostic, manuels C.20 d’utilisation, fiche technique, etc. (oui/non) Prière de préciser Scanner Type de produit/ marque modèle Quantité : C.21 Vitesse de numérisation Technologies de Lecture simultanée MICR et/ou OCR (oui/non) module d'impression intégré (oui/non) N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement normes Autres dispositifs – Prière d’énumérer C.22 D. UPS pour serveurs (site nominal et site de secours) Tableau - 12 N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement D.01 UPS : D.02 Faire/marque Modèle Quantité D.03 Capacité (VA) D.04 Temps de recharge N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement D.05 Temps de chargement complet (min.) D.06 Plage de tensions nominales D.07 Nombre de sorties (2/4/6…) D.08 Port de communication (Serial/RJ45/USB…) D.09 Protection D.10 AVR intégrée (oui/non) D.11 Variation de puissance (oui/non) D.12 Surcharge (oui/non) D.13 Court-circuit (oui/non) D.14 Dispositif d'arrêt de réseau (oui/non) D.15 Protection contre les pics de tension (oui/non) D.16 Protection pendant les régimes transitoirese (oui/non) D.17 Câbles D.18 Numéro du câble de sortie (2/4…) D.19 Cable RS-232 (oui/non) D.20 Câble d’alimentation (type Schuko…) D.21 Rackable (oui/non) D.22 Prise en charge d’un dispositif de Shunt (oui/non) D.23 Offre une autonomie de 30 minutes (oui/non) D.24 Tension d'entrée 220V AC, 50 hertz (oui/non) N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement D.25 Documentations : CD contenant les pilotes, disquettes, outils logiciel de diagnostique, manuels d’utilisation, fiche technique, etc. (oui/non) Prière de préciser D.26 Autres dispositifs – Prière d’énumérer E. Switch gigabit Réponse du Description de N° Caractéristiques techniques soumissionnaire l’équipement E.01 Switch gigabit : E.02 Type de produit/marque Modèle : Quantité E.03 Processeurs E.04 Mémoire DRAM E.05 Mémoire Flash E.06 Ports Ethernet E.07 Ports amovibles de dimensions réduites E.08 Câble d'interconnexion Réponse du Description de N° Caractéristiques techniques soumissionnaire l’équipement E.09 Quantité E.10 Principales caractéristiques E.11 IEEE 802.3af cou support de PoE (oui/non) E.12 1RU Fixe-Configuration, switch multicouche (oui/non) E.13 IEM (Enhanced multilayer Software image) installé.(oui/non) E.14 Routage IP avancé (oui/non) E.15 Accessoires E.16 câble pour moniteur (oui/non) E.17 Kit de fixation complet (oui/non) E.18 Câble d’alimentation de Type Schuko (Y/N) E.19 Tension d'alimentation E.20 Documentations : CD contenant les pilotes, disquettes, outils logiciel de diagnostic, manuels d’utilisation, fiche technique, etc. (oui/non) Prière de préciser E.21 Autres dispositifs – Prière d’énumérer F. Routeur Réponse du Description de N° Caractéristiques techniques soumissionnaire l’équipement F.01 Routeur : F.02 Type de produit/marque Modèle : Quantité F.03 Processeurs F.04 Mémoire DRAM F.05 Mémoire Flash F.06 Interfaces Ethernet F.07 Interfaces WAN F.08 Ports amovibles WIC F.09 Principales caractéristiques F.10 Routage IP avancé.(oui/non) F.11 expansion des services F.12 sécurité d’entreprise F.13 Accessoires F.14 câble pour moniteur (oui/non) F.15 Kit de fixation complet (oui/non) F.16 Câble d’alimentation de Type Schuko (Y/N) F.17 Tension d'alimentation Réponse du Description de N° Caractéristiques techniques soumissionnaire l’équipement F.18 Documentations : CD contenant les pilotes, disquettes, outils logiciel de diagnostic, manuels d’utilisation, fiche technique, etc. (oui/non) Prière de préciser F.19 Autres dispositifs – Prière d’énumérer G. Firewall Réponse du Description de N° Caractéristiques techniques soumissionnaire l’équipement G.01 Parefeu : G.02 Type de produit/marque Modèle : Quantité G.03 Processeurs G.04 Mémoire DRAM G.05 Mémoire Flash G.06 Ports Ethernet G.07 Câble d'interconnexion G.08 Quantité G.09 Principales caractéristiques Réponse du Description de N° Caractéristiques techniques soumissionnaire l’équipement G.10 IEM (Enhanced multilayer Software image) installé.(oui/non) G.11 Routage IP avancé.(oui/non) G.12 Débit du firewall G.13 Débit du VPN G.14 Nombre de tunnels VPN IPSec homologues, homologues en VPN SSL G.15 Firewall rackable (oui/non) G.16 Accessoires G.17 câble pour moniteur (oui/non) G.18 Kit de fixation complet (oui/non) G.19 Câble d’alimentation de Type Schuko (Y/N) G.20 Tension d'alimentation G.21 Documentations : CD contenant les pilotes, disquettes, outils logiciel de diagnostic, manuels d’utilisation, fiche technique, etc. (oui/non) Prière de préciser G.22 Autres dispositifs – Prière d’énumérer H. Armoire N° Caractéristiques techniques Réponse du soumissionnaire Description de l’équipement H.01 Armoire H.02 Modèle H.03 Largeur (millimètres) H.04 Hauteur H.05 42U, 920mm (oui/non) H.06 Accessoires H.07 socle de stabilisation extensible de 100 mm de hauteur H.08 Etagère fixe ventilé standard (oui/non) H.09 Mise à la terre (oui/non) H.10 Unités de distribution d'énergie filtrées (oui/non) H.11 Plateau de ventillateurs thermostatiquement commandé (oui/non) H.12 Support de câble (oui/non) H.13 Vérouillage (oui/non) H.14 Couverture à moteur ventilé (oui / non) H.15 Porte vitrée à cadre ventillé (oui/non) H.16 Autres dispositifs – Prière d’énumérer 6. Exigences techniques du logiciel ATS Fiches techniques du logiciel ATS. 6.1. Architecture du logiciel ATS Réponse du N° Caractéristiques techniques Description de l’équipement soumissionnaire 1. Nom de la solution d'ATS a proposée 2. Nombre de version et de releases de la solution d'ATS proposée 3. Standard d’architecture des systèmes ouverts modernes 4. RDBMS entièrement intégré 5. Base de données ODBC compatible 6. Tous les modules entièrement intégrés au cœur du système 7. Entièrement paramétrable 8. Interface (utilisateur) graphique pour tous les modules 9. Architecture N-tiers 10. Certifié ISO 9001 ou plus 11. Noyau et composants tournant sur une architecture de 32 12. bits des modules extensibles Ayant 13. Nombre de décimaux paramétrable par l’utilisateur 14. Supporte un algorithme d'arrondissement pour les devises locales et étrangères 15. Offre des rapports standards personnalisables par l’utilisateur 16. Offre des rapports ad hoc personnalisable par l'utilisateur Réponse du N° Caractéristiques techniques Description de l’équipement soumissionnaire 17. Offre de menus personnalisables par l’utilisateur 18. Support des raccourcis vers les valeurs fréquemment fournies en entrée 19. Support de la définition des valeurs par défaut afin de réduire les frappes sur clavier 20. Offre une interface en ligne et en temps réel au grand livre 21. Offre une interface avec la suite MS Office (mot, Excel, etc.) pour l’extraction des rapports 22. Offre des moyens de mise à jour globale 23. Offre des menus contextuels 24. Offre des moyens d’exportation de données 25. Support multidevises et multi-langues 26. Support multi-banque et multi-entité 27. Support de la gestion en temps réel des liquidités 28. C Compatibilité à SWIFT 1. Envoi et du traitement des messages au format SWIFT 2. Paiement sécurisé et transmission des messages utilisant les services SWIFT et communication interactive pour le contrôle et la gestion de file d’attente 29. Support des paiements de petits et gros montants 30. Support DVP (Delivery Verses Payment) 31. Support PVP (Payment Verses Payment) 32. Permet de façon continue et en temps réel, la finalité et l’irrévocabilité du règlement des virements bancaires Réponse du N° Caractéristiques techniques Description de l’équipement soumissionnaire 33. Permet la mise en fil d’attente centralisée des paiements en attente de disponibilité des fonds 34. Offre une décongestion automatique des files d’attente 35. Permet le contrôle des soldes des comptes et offre un reporting pour la BCM et les participants 36. Support de la gestion des crédits et avances intrajournalières 37. Offre une base de données des statistiques ainsi que des moyens de reporting 38. Offre un accès sécurisé aux données au moyen des signatures numériques et des mécanismes de cryptage à clé publique 39. Offre des mécanismes paramétrable de définition des frais, commission, intérêt, etc. 40. Autres fonctionnalités – Prière d’énumérer et d’expliquer dans la colonne des commentaires. 6.2. Gestion d’accès utilisateurs au logiciel ATS Réponse du N° Caractéristiques techniques soumission Description de l’équipement naire 1. Offre un système de supervision centrale de l’identification des utilisateurs au moyen de mots de passe 2. Exige à l’utilisateur, le changement de mot de passe à la première connexion au système 3. Permet l’enregistrement du nom d’utilisateur et d’autres informations relatives à l’utilisateur 4. Permet à l’utilisateur de changer son mot de passe 5. Autorise la connexion en cas d’oubli de mot de passe, exclusivement à l’administrateur système 6. Permet de grouper les utilisateurs suivant les similarités de profils 7. Enregistre la date de la première configuration et celle de la dernière modification 8. Permet de contrôler les accès aux informations confidentielles 9. Permet de contrôler l’accès aux transactions, procédures et routines sensibles 10. Permet de limiter l’accès au système sur base des niveaux d’habilitation des utilisateurs 11. Bloque un compte utilisateur après trois tentatives de connexion d’un utilisateur non autorisé avec un mot de passe erroné 12. Permet la modification d’attributs et la suppression d’un utilisateur par l’administrateur système 13. Exige à l’utilisateur de changer régulièrement son mot de passe 14. Mots de passe à huit caractères alphanumériques (au moins) 15. Exige à l’utilisateur de définir un mot de passe contenant à la fois les caractères numériques et alphanumériques Réponse du N° Caractéristiques techniques soumission Description de l’équipement naire 16. Permet la rétention de mot de passe sous forme crypté 17. Permet l’enregistrement du nombre d’échecs de connexion, depuis la dernière connexion réussie 18. Empêche la réutilisation de mot de passe par analyse de la liste des mots de passe antérieurement utilisés 19. Permet la déconnexion d’un utilisateur après une période déterminée 20. Permet de contrôler le temps de connexion des utilisateurs sur une base journalière, hebdomadaire, etc. 21. Prévenir la connexion d’un utilisateur sur plus d’une station de travail 22. Autres fonctionnalités – Prière d’énumérer et d’expliquer dans la colonne des commentaires. 6.3. Dispositifs de sécurité et de contrôle du logiciel ATS Tableau - 17 Réponse du N° Caractéristiques techniques soumissionn Description de l’équipement aire Accès utilisateur à l'ATS 1. Noms d'utilisateur avec caractères alphabétiques, numériques ou alphanumériques 2. Interdit l'utilisation des caractères spéciaux/ cachés 3. Définit les tailles maximal et minimal des noms d’utilisateurs et de mots de passe 4. Noms d’utilisateurs et mots de passe sensibles à la casse Réponse du N° Caractéristiques techniques soumissionn Description de l’équipement aire 5. Noms d’utilisateurs définis par le système 6. Mots de passe définis par l'utilisateur 7. Changement forcé de mot de après période définie 8. Restriction d’accès aux fonctions et aux données au moyen de mot de passe de complexité élevée 9. Rejet d’un mot de passe lorsqu’il est utilisé par un autre utilisateur ; le mot de passe devant alors être changé 10. Rejet de mot de passe après expiration au bout d’une période définie 11. Rejet de mot de passe déjà utilisé 12. Limiter le nombre de tentatives de connexion 13. Droits d'accès configurés au niveau utilisateur, poste de travail, compte et fonction 14. Fermeture de session obligatoire 15. Désactivation automatique après une période déterminée d'inactivité 16. Limiter la connexion d’un utilisateur à une seule station de travail à un moment donné ARCHIVAGE ET EFFACEMENT 1. Archivage des états des comptes et d'autres rapports en accord avec les exigences en la matière 2. Effacement des états des comptes et d'autres rapports en accord avec les exigences en la matière 3. Sauvegarde manuelle et automatique Réponse du N° Caractéristiques techniques soumissionn Description de l’équipement aire 4. Sauvegarde incrémentale et différentielle 5. Restauration manuelle des données assignée exclusivement au personnel habilité 6. Autres fonctionnalités – Prière d’énumérer et d’expliquer dans la colonne des commentaires.