MPC - OPE - IT - Cahier de Charges - V0.1 (Enregistré Automatiquement)

Section VII.
Modèles des formulaires 1
PROJET SWITCH MONETIQUE

Section VII. Modèles des formulaires 2
1 – DESCRIPTION ET CONTEXTE DU PROJET
Présentation générale de Multipay CONGO
Multipay CONGO est une société proposant le premier service monétique interbancaire en RDC, ayant a pour
mission l’étude, la mise en place, la normalisation, la promotion, la supervision et le développement des solutions de
paiements Interbancaires, et vise à devenir le leader dans le secteur des services interbancaires liés à la monétique
en RDC et apporter au cœur de l'Afrique des solutions innovantes et modernes sensées révolutionner le secteur
financier.
Des amples détails sur la société sont disponibles sur leur site web : www.multipay.cd
Description générale du projet
Après 5 ans d’existence, à bâtir une expérience terrain solide et après avoir compris les problématiques et
contraintes du secteur, Multipay veut se doter d’un Switch Monétique Interbancaire à mesure de faire face de
manière efficace aux défis qui lui sont propres et être à même de porter ses ambitions de développements futurs.
L’objectif de Multipay CONGO est de mettre en œuvre dans une première phase un switch monétique interbancaire
complet privatif en remplacement de l’actuel dans le même périmètre et conforme aux normes internationales en la
matière et ensuite capable donc de s’adapter aux évolutions futures.
Le besoin d’acquérir un Switch Monétique interbancaire consiste en la fourniture et la mise en œuvre opérationnelle
des outils matériels et logiciels nécessaires à assurer :
 Le routage des autorisations et la compensation des opérations de paiement et retrait par cartes
interbancaires domestiques ;
Le Switch devra fournir des services à deux niveaux :
 services monétiques interbancaires (interopérabilité des transactions).

 services monétiques bancaires par délégation (délégation permanente pour les
banques, établissements financiers et postaux qui sont équipés ou non de systèmes
monétiques d’une part et les services de secours et/ou de back-up pour ceux qui
disposent de leurs propres systèmes).
 La gestion du système d’information nécessaire à la supervision, à la sécurité et au bon fonctionnement du

système monétique interbancaire.
Le présent cahier de charge vise à acquérir un système « clés en main » conforme aux standards internationaux
(fonctions couvertes, procédures de traitement, procédures sécuritaires, performances).
Cette solution doit répondre à l’ensemble des besoins d’un Switch Monétique Interbancaire. La solution doit couvrir
le périmètre fonctionnel défini dans ce cahier des charges, dans un contexte d’évolutions réglementaires liées
principalement à Europay, Master Card et Visa (EMV) avec un objectif de pérennité, d’évolutivité, de qualité de
service et de sécurité.
Il est demandé que le système proposé soit déjà opérationnel au minimum dans un autre pays. Il s’agit d’un critère
obligatoire, éliminatoire si non rempli.
Les fonctionnalités additionnelles fournies par le logiciel mais non explicitement demandés dans le présent cahier
des charges feront implicitement partie intégrante de offres des soumissionnaires.
Les matériels et composants logiciels de télécommunications (y compris les équipements de réseaux tels que les
Firewalls et les routeurs) ne feront pas partie de l’appel d’offre.
Le soumissionnaire devra néanmoins, dans la mesure où il ne répondrait pas en complément au lot ‘Equipements
réseaux et intégrateur’, préciser dans sa réponse les spécifications techniques des équipements et protocoles de
télécommunications compatibles avec son système et nécessaires pour garantir les performances attendues.
2 – OBJET DU MARCHE
L’objectif de ce marché est la fourniture, l’implémentation et l’intégration complète de logiciels pour la gestion d’un
système monétique contenant :
- une offre technique détaillée de la solution ;

- une offre financière (contrat logiciel, maintenance et prestation);
- Une offre des matériels, contenant : des serveurs et tout autre équipement nécessaire pour la mise en œuvre
de la solution.
- Une offre service après-vente
3 – description de l’Existant
a. Infrastructures de télécommunication
Les caractéristiques techniques de ressources des liaisons utilisées sont :
Type : Router, filaire fibre optique, Radio Wimax, Micro-onde, GSM et VSAT
Protocoles : TCP/IP.
b. Type des cartes

Les cartes acceptées sont soit des cartes privatives à puce/piste ou à piste, soit des cartes des émetteurs
internationaux, principalement VISA et Mastercard.
c. Parc de DAB/GAB2
Nombre de DAB/GAB : + 480

Protocoles : NDC+, APTRA NDC. Mode
de fonctionnement : ON-LINE.
Services offerts : Retrait d’espèces, Solde Minute, Mini-relevé.
d. Parc de TPE3
Nombre de TPE : + 6186

Protocoles : CB2A.
Mode de fonctionnement : ON-LINE.
Services offerts : Paiement de proximité, Cash Advance.
e. Services Monétiques
Services offerts aux porteurs de la banque : Retrait d’espèces, Solde Minute, Mini-relevé, paiement, cash
advance, débit immédiat et débit différé etc.
Services aux commerçants : acquisition d’autorisations, paiements marchand télécollecte.
Services sur automates DAB/GAB : Retrait d’espèces, Solde Minute, Mini-relevé.
f. Banques
Actuellement, on dénombre 3 banques commerciales au réseau Multipay qui émettent des cartes et
fournissent des services de paiement à cartes. Indépendamment de l'acceptation des cartes internationales
(Mastercard et visa), le service Multipay assure interopérabilité entre les bornes de carte (ATMs et TPE) de
ces banques.
Le Switch est interfacé à l’ATS et aura pour fonction de compenser tous les paiements et retraits déplacés,
calculer le solde net et le déverser dans le système RTGS de l’ATS pour règlement.
g. Volumétrie
Nombre des transactions par mois : 100 000 transactions, environ 1,200,000.00 opérations/an
Nombre de paiements par mois : 74920 paiements, environ 899,040.00/an
h. Internet Banking
Deux banques du réseaux Multipay offrent des opérations bancaires par Internet mais seulement pour des
transactions privatives.
i. Interbancarité
La solution monétique devra être capable d’assurer en toute aisance :
 La gestion des référentiels BIN et des oppositions ;
 Le routage des requêtes (demandes d’autorisations) vers le centre d’autorisation de la
banque du porteur et le réacheminement de la réponse vers l’initiateur du flux (TPE,
DAB/GAB) ;
 La gestion des opérations et le règlement à travers le RTGS mis en place par la BCC ;
 Le traitement des litiges (gestion des impayés/rejets techniques/demandes de
justifications, recouvrement des frais) ;
 La gestion du risque (suivi de lutte contre la fraude) ;
 La Gestion du Centre d’Appel.
4- Spécifications Techniques et Fonctionnelles
La RDC a une croissance économique régulière (plus de 9% en moyenne) depuis 2012. Cette croissance entraine une
augmentation de besoins des paiements liés à l’activité économique. Ainsi donc Il nous faut prévoir des systèmes et
moyens de paiement en phase avec les besoins des acteurs économiques pour permettre de réaliser des paiements
de façon pratique et efficiente pour l’ensemble de l’économie.
Le Switch Monétique devra offrir :
a. Services interbancaires :
• Retrait rapide ou normal sans choix de compte, à débit immédiat.
• Retrait avec choix de compte, à débit immédiat.
• Retrait rapide ou normal sans choix de compte, à débit différé.
• Retrait avec choix de compte, à débit différé.
• Cash advance au guichet, à débit immédiat.
• Cash advance au guichet, à débit différé.
• Paiement à débit immédiat.
• Paiement à débit différé.
• Consultation de solde minute.
• Edition des derniers mouvements.
• Demande d’impression de RIB
•Dépôts espèces.
b. La gestion des cartes
• L’émission des cartes,
• la gestion des BIN,
• les règles d’échange,
• la gestion des litiges,
• la gestion des oppositions,
• la lutte contre la fraude,
• le commissionnement.
• Gestion du service clients (réclamations, historique, opposition/main levée etc.) ;
• Monitoring des GAB et TPE ;
• Traitement de fin de journée ;
• Reporting etc.
c. Transactions
a. DAB/GAB :
• Retrait d'espèces ;
• Paiement en espèces ;
• Paiement des factures ;
• Transferts de fonds ;
• Consultation Solde
• Mini-Relevé
• Changement de PIN
• à réaliser en « On Us » et en interbancaire.
b. TPE :
• Retrait d'espèces (Cash Advance) ;
• Paiement chez les commerçants ;
• à réaliser en « On Us » et en interbancaire ;
• les recharges ;
• Loyalties ;
• Cash-back ;
• Transferts, ...
c. INTERNET :
• Transactions e-Commerce ;
• Le paiement de factures d’eau ;
• Le paiement de factures d’électricité ;
• Le paiement de factures de téléphone ;
• Le paiement des impôts ;
• Le paiement des droits de douane et taxes assimilés ;
En plus des services mentionnés ci-dessus, le soumissionnaire est invité à proposer d’autres services qui
seraient actuellement disponibles au niveau de sa solution tout en étant éprouvés sur le marché.
(i) Gérer le fonctionnement d'un système intégré et interopérable de distributeur automatique

(DAB/GAB)/point de vente (TPE), y compris le routage et la compensation des transactions
DAB/GAB pour le compte des banques membres ;
(ii) Être compatible avec les DAB/GAB et TPE à installer, les serveurs monétiques des cartes, DAB/GAB et
TPE existants, d'autres applications bancaires du pays, des solutions de paiement via le mobile et
des solutions de e-commerce ;
(iii) Contrôler le routage et le traitement des transactions au niveau TPE pour les banques affiliées ;
(iv) Permettre le dénouement sécurisé des transactions sur Internet ;
(v) Fournir diverses options d'authentification du porteur de la carte comprenant la signature, PIN 3D
Secure, Verified by Visa, Secure Code, l’OTP (One Time Password), etc.;
(vi) Avoir des interfaces avec des réseaux régionaux et internationaux de carte pour régler des
transactions avec les émetteurs et les acquéreurs locaux, régionaux et internationaux ;
(vii) Avoir des mécanismes intégrés qui garantissent des pistes de vérifications électroniques,
récupération automatique, annulation de la transaction, réconciliation des transactions,
remboursements ;
(viii) Pouvoir s’interfacer avec l’ATS, RTGS de la BCC ;
(ix) Etre Conforme aux normes EMV comprenant entre autres la sécurité et les méthodes de
traitement ;
(x) Donner des options pour une liaison au système de gestion des cartes de marque internationale ou au
système de gestion des cartes fournies par les fournisseurs à installer au niveau des banques
émettrices des cartes et des banques acquéreuses des cartes ;
(xi) Avoir des interfaces avec les plateformes Mobile Banking des opérateurs télécoms du Congo et
aussi permettre l’interopérabilité entre les MNO’s. Pendant la période de mise en œuvre du projet,
trois interfaces pilotes au minimum doivent être établies ;
(xii) Intégrer avec d'autres produits tels que les systèmes de gestion de carte et la détection de la
fraude, pour faciliter l’émission, l'acquisition, le traitement et la gestion des transactions par
n'importe quel canal ;
(xiii) Supporter un volume élevé, et garantir une haute disponibilité grâce à une architecture logicielle à
tolérance de pannes et évolutive qui fonctionne sur plusieurs plates-formes ;
(xiv) Intégrer aux systèmes d’information bancaires des banques commerciales àsavoir, Misys, Iflex,
Oracle Flexcube, Globus Temenos, DeltaSopra, (Rubikon,Orbit) Neptune, ALTBANK etc... Avec des
normes d'interface ouvertes ;
(xv) Rendre le plus paramétrable possible l’application, en donnant aux utilisateurs la capacité de
définir la logique de fonctionnement de l'application telle que l'authentification et le traitement
des transactions sans devoir modifier le code source ;
(xvi) MobileFaciliter une productivité élevée avec une interface utilisateur conviviale afin de simplifier
les opérations de gestion ;
(xvii) Offrir une solution mBanking sécurisé avec toutes les fonctions et qui pourra aussi permettre
l’interopérabilité entre les Télécoms ;
(xviii) Offrir des solutions pour le Centre de personnalisation et production des cartes.
d. Gestion du Mobile Payment
Le mBanking, transfert interbancaire de fonds à l’aide du mobile encaissant ces transactions. Chaque
opération doit être sous forme de transfert en temps réel des fonds entre les comptes du débiteur et celui
du bénéficiaire (exception : paiement en espèces). La solution devrait supporter le MOBILE PAYMENT
(Services Transactionnels de Paiement accessibles via le mobile, sans lien direct avec un établissement
financier, et le MOBILE BANKING (Produits ou Services Financiers accessibles via le mobile, dans une
logique multi canal, et en relation directe avec un établissement financier).
La plateforme monétique devra avoir un module qui permettra aux Institution Financières d’offrir des
produits et services bancaires à leurs clients en utilisant le téléphone portable en liaison ou non avec les
comptes bancaires de ces derniers. La solution devra aussi offrir l’interopérabilité entre les institutions de
téléphonie mobile offrant le mBanking.
Les services seront les suivants :
 La création du porte-monnaie sur le téléphone ;
 La consultation du solde de son porte-monnaie mobile ;
 La consultation du solde de ses comptes bancaires des banques et institutions financières
participantes ;
 Réception des salaires ;
 Transfert d’argent de personnes à personnes ;
 Paiement de factures ;
Les informations de monitoring comme :
 la consultation de soldes ;
 la demande de mini relevés ;
 la demande de chéquiers ;
 la demande d’opposition sur les formules du chéquier ;
 la demande d’activation et/ou de désactivation d’une carte de paiement ;
 l’envoi de messages mails liés aux opérations de paiement par téléphones mobiles etc.
Les fonctionnalités minimales de ce module devront comprendre, sans limitation, celles relatives à :
 Retrait sur GAB/DAB en utilisant son téléphone portable et sans recourir à la carte bancaire ;
 Effectuer le transfert d’argent via le GAB/DAB ou via le téléphone en envoyant un simple SMS et
cela aussi bien au niveau national qu’au niveau international ;
 Retrait de cash au niveau d’un point de vente ;
 Virement de compte à compte, de compte à cash, de cash à compte et de cash à cash ;
e. Règlement interbancaire
Le module de règlement doit inclure des mécanismes mais non limité :

 Pour calculer le solde net émetteur, acquéreur et les totaux pour chaque banque membre;
 Pour calculer des charges imputables et commissions perçus par chaque émetteur et
acquéreur ;
 Prendre en charge les cycles de compensation multiples, supporter la compensation en temps
réel et les modes de compensation par lot basés sur le règlement de type de transactions.
Supporter les règlements basés sur divers niveaux de l'agrégation pour une banque ou un
groupe de banques. La livraison spécifique des fichiers de compensation et des rapports de
règlement par un mécanisme de « push ». Des rapports de compensation et de règlement
doivent être disponibles dans divers formats y compris le format XML.
f. Gestion de litiges
Le logiciel doit fournir une interface web aux banques membres acquéreur et émetteurs pour :
 Rechercher les transactions appartenant à ses clients ou à ses points de services ;
 Emettre un Charge-back en référence avec la transaction ;
 La banque membre ne doit exiger aucune entrée manuelle, juste sélectionner la transaction et
écrire la raison et les commentaires du Charge-back ;
 L’option messagerie doit être disponible de sorte que l'autre banque membre impliqué dans
le contentieux peut recevoir la transaction rejetée en boîte emails ;
 Une fois que les parties enclenchent le processus de gestion des charge-back, les fonds
initialement perçus auprès d’une banque au profit d’une autre banque doivent être restitués
dans les prochains règlements interbancaires ;
 L’émission ou comme la réception d’un Charge-back se fait en temps réel ;
 Établir les différents droits d'accès pour chaque utilisateur ;
 Gérer les habilitations avec les participants ;
 Produire un fichier des notifications en temps réel et en différé par cycle de vie des Charge-
back ;
 Supporter la résolution des litiges en 2 étapes (Charge-
back+présentation+Arbitrage) ;
 Prendre en charge l'échange en temps réel de la documentation accompagnant le litige ;
 Tous les rapports doivent être disponibles à cette fin ;

 Afficher le sommaire des litiges actifs (comme acquéreur et émetteur) ;
 Afficher le détail des litiges actifs :
 Afficher l’historique des litiges.
g. Interfaçage aux systèmes de banque participant
1. Interfaçages avec les participants domestiques
Le Système National de Paiement fournira un numéro dépôt et droits d’accès aux participants (selon les
critères d'accès régis par des règles d'exploitation).
Le soumissionnaire et le fournisseur du côté des participants seront responsables de développer des
interfaces avec des Switches / Passerelle / Réseaux etc., pendant la période d'exécution du projet, le
soumissionnaire sera aussi responsable des interfaces avec toutes les banques, le ATS, et autres
participants.
2. Réseaux Internationaux de Carte de Paiement
MULTIPAY aura une interface avec tous les réseaux internationaux, par exemple, VISA, MasterCard, AMEX
etc.
Chaque interface supporte un protocole international déterminé. Il y aura autant d’interfaces que de
connexions avec les différents émetteurs internationaux : VAP (Visa Access Point) pour VISA, MIP
(Mastercard Interface Processor) pour MasterCard, etc.
Avec ces réseaux internationaux, MULTIPAY aura un rôle limité car il ne sera pas un émetteur, ni un
acquéreur. Il pourra traiter, envoyer et recevoir des fichiers de règlement pour le compte des banques
participants pour toutes les transactions réglées/routées par le SMIC.
MULTIPAY pourra régler en devises les transactions faites par des cartes émises ou acquises en RDC. Pour
les transactions faites par des cartes en émission ou en acquisition internationale, les transactions seront
faites grâce aux échanges entre les réseaux internationaux et la SMIC.
Durant la période d'exécution du projet, au moins trois interfaces VISA, Mastercard, AMEX doivent être
établie par le soumissionnaire.
3. Institution Financières et autres Participants
Au regard des services que MULTIPAY est appelé à offrir au public, les participants seront principalement
constitués des banques commerciales, des établissements financiers, des IMF autorisées par la loi bancaire
ou le cas échéant habilités par la BCC, des opérateurs de téléphonie mobile ainsi que des fournisseurs
d’accès au réseau de télécommunication.
Tout acteur local habilité à gérer des DAB/GAB, des comptes clientèles, due-Commerce, des opérations
bancaires sur Internet, des solutions de mobile banking; des solutions opérateurs (processeur sous-traitant
technique, en revenue sharing, etc.) doivent être connectés au Switch Monétique National. L'accès au
Switch National peut être direct ou indirect via une plateforme institutionnelle qui consolide les dispositifs
des plusieurs participants. Un établissement qui se connecte directement au Switch National pourra
bénéficier des services en délégation (outsourcing).
La Banque centrale du Congo recevra, via le système ATS (RTGS), les soldes nets multilatéraux du système
monétique et pourra jouer le rôle de régulateur en même temps qu’elle offre un cadre approprié pour la
promotion et la surveillance du système.
Le MULTIPAY doit aussi permettre à l’administrateur du système de pouvoir intégrer de nouveaux

participants qui ne seront pas disponibles dès son démarrage pourvu que ces derniers remplissent les
conditions de participation convenues.
4. Interface de paiement sur Internet (e-Commerce)
Multipay doit fournir une interface standard pour accepter la demande de connexion d'un système de
paiement sur Internet qui sera mis en œuvre à l'avenir. Il doit supporter le traitement des transactions e-
commerce effectuées par les clients sur Internet, en utilisant leurs cartes prépayées, de crédit ou de débit.
Ces transactions e-Commerce sont de type « Carte Non Présente ». Le Switch National doit donc, pour des
mesures de sécurité, supporter des méthodes additionnelles d'authentification et de détection de fraude.
L’authentification des détenteurs de carte doit inclure l'utilisation des outils de sécurité CVV2/CVC, 3D-
secure, Secure Code ou équivalent.
La MULTIPAY doit adopter des normes internationales d’interfaçage du secteur. Celles-ci doivent inclure
des normes techniques telles que HTTPS, XML, Web services ou services équivalents pour le transport des
messages inter systèmes, aussi bien que l'utilisation des normes d'ISO8583 pour le traitement des
requêtes/réponses du paiement.
5. Intégration avec les systèmes bancaires des participants
Le système doit fournir une connexion standard pour permettre le traitement de bout en bout pour tous
les types de paiement. Ceci exigera clairement à chaque banque de mener à bien les travaux nécessaires
de systèmes pour intégrer son système bancaire au Switch national.
On s'attendra à ce que le fournisseur du Switch national retenu travaille avec les banques participantes
pour les aider à se connecter ; ce qui dans certains cas peut probablement nécessiter que le fournisseur du
Switch national effectue des travaux de développement et d'intégration pour les banques. Les
soumissionnaires doivent indiquer le coût pour connecter le Switch national au système d’information
bancaire de la banque participante dans leur proposition.
Le soumissionnaire retenu fournira les pré requis et caractéristiques détaillés d'interfaçage pour cette
connexion et aucune autre charge ne sera demandée à la banque participante.
h. Intégrité
Les deux sites doivent fournir :
1. L'intégrité financière permettant de vérifier à tout moment que le cumul des soldes
net de règlement est nul ;
2. Des vérifications d'intégrité de traitement afin d'assurer que le nombre d'éléments
financiers en entrée soit égale au nombre d'élément financier en sortie à n'importe
quel moment et que chaque site de traitement puisse se concilier à une position
donnée à n'importe quel moment ;
3. Des rapports cohérents et réguliers pour le traitement financier, les journaux (logs) de
sécurité, les positions de règlement calculées, brut et les valeurs de règlement net, les
numéros de lot et le fichier de traitement, etc. qui peuvent être rapportés à la fois
localement et au niveau central pour démontrer l'intégrité du système et la
réconciliation dans l'ensemble du système ;
4. Enregistrement local de tous les messages envoyés, en attente et reçus chaque jour ;
5. Cryptage de tous les flux de données ;
6. Audit de fin de journée et les rapports d’activités ;
7. Capable d'effectuer des récupérations locales ;
8. Sécurité des messages avec un haut niveau d'authentification du message, d'intégrité
des données et de confidentialité ;
9. Aucun arrêt du système ni perte de données n’est autorisé pendant la mise à jour du
logiciel ;
10. Un niveau très élevé de disponibilité et de fiabilité ;
11. Garantie de non perte de données par retransmission après un échec.
Les fonctions de gestion du système doivent être pleinement intégrées. Par exemple, la définition d'un
paramètre qui peut être applicable à tous les composants du système, ne peut être que paramétrable une
fois. Toutes les informations du système en mouvement entre les composants devront être transparentes
aux opérations du système.
i. Intégrité de message et responsabilité
Le contrôle devra inclure ce qui suit :

1. Chaque enregistrement de modifications d’instruction ou d’instruction de paiement ainsi
que le fichier contenant des instructions similaires devront être identifié de manière
unique avec leur source physique, identifiant utilisateur, date et heure de leur
enregistrement dans le système ;
2. Chaque instruction devra être exécuté suivant un ou plusieurs niveaux d’autorisation fixée
par l’administrateur et/ou les membres participants ;
3. Un schéma de numéro de séquence des messages et une procédure de contrôle devront
être implémentés pour qu’il n’y ait ni perte, ni duplication ou insertion non autorisée des
messages.
4. La non-répudiation est exigée pour tous les messages des participants ;
5. Les acquittements des messages au niveau applicatif est nécessaire en tant que
composante obligatoire de tout traitement de message ;
6. Là où un opérateur a la possibilité de faire n'importe quel changement sur n'importe quel

message (par exemple des messages de valeur ou des messages qui contiennent des
instructions pour effectuer des paiements ou transférer des valeurs) ou des paramètres
critiques du système, le système devra tenir compte des autorisations multiples (c'est-à-
dire plusieurs niveaux de validation) ;
7. Il devra être possible que la gestion opérationnelle puisse tracer automatiquement

n'importe quelle transaction à partir d’un point d'entrée du système jusqu'à la livraison à
sa destination finale avec des informations complètes sur le temps où le message a été
reçu et délivré, et le traitement effectué à chaque étape à chaque endroit où la transaction
/ le fichier a été manipulé. A cette fin, les informations devront être gardées en ligne
pendant un nombre de jours paramétrable par le Switch national après lesquels les
données devront être archivées hors line en permanence.
8. La suspension du traitement des composants du système (par exemple, les files d'attente
de paiement sélectionnées ou flux) devra être possible au cours de la journée d’échange
ainsi que leur reprise sans perte ni duplication des messages ;
9. En cas de panne conduisant à l'indisponibilité du site principal, la reprise du service dans

le site secondaire devra être effectuée dans un délai maximum de dix minutes avec une
intervention minimale de l'utilisateur.
j. Exploitation du Système
1. Afin de minimiser le risque d'erreur humaine qui pourrait provoquer des interruptions de
service, le fonctionnement du logiciel devraient être automatisé dans la mesure du possible
avec des mécanismes de contrôles afin de garantir la réussite de chaque tâche comme
condition pour l'initiation des séquences de tâches ultérieures ;
2. La plateforme doit offrir une interface graphique cohérente (GUI) qui permet de superviser ses
opérations dans l'ensemble. L'interface devrait fournir une gamme complète de paramètres
définissables par l'utilisateur qui devront être décrites dans les offres ; fournir une interface
graphique GUI via le client léger (interface Web) où toutes les tâches opérationnelles et
d'administration de la solution peuvent être effectuées par le personnel de MULTIPAY;
3. Tous les aspects du système doivent être commandés par l'intermédiaire d'une interface
graphique ;
4. Les exigences techniques de gestion doivent au minimum être réduites. Il est particulièrement
important que tous les messages d'erreurs soient affichés de manière explicite afin de
permettre aux personnels exploitant le système de réagir en conséquence ;
5. Le système devrait exiger au minimum (ou de préférence ne pas exiger) une intervention par
le personnel technique informatique pour les opérations normales y compris les mises en
service, les opérations quotidiennes et les arrêts ;
6. Le système devrait fournir une gamme d'alarmes et d'alertes avec comme option :
a. Différents niveaux d’alertes (par exemple critique, sérieux, informationnel- seulement) ;
b. La nature des alarmes disponibles (par exemple un message clignotant au niveau d'un
poste de travail de l'opérateur, des alertes sonores, des messages électroniques, des
messages SMS vers un téléphone mobile);
c. Destinataires des alertes (par exemple operateurs de la SMIC, et des utilisateurs de
banque de participant, etc.) ;
7. Les mesures de certifications qui se dérouleront en utilisant l'environnement de test, devront
être mises en place dans le contexte de cette acquisition. Elles doivent être effectuées en
utilisant un ensemble de message de test standard qui seront développés dans le contexte de
la mise en œuvre globale du système et qui devrait inclure :
a. De nouveaux tests et certification par suite de mises à jour de l’application et ce, avant
son utilisation ;
b. De nouveaux tests et certification des systèmes avec les systèmes tests des
participants en ce qui concerne le matériel, le logiciel, les communications et les
procédures.
k. Sûreté & Sécurité
1. Conditions Générales
Le système doit avoir des équipements de sécurité pour contrôler l'accès aux données et au
traitement conformément au PCI-DSS. La sécurité et le cryptage employés par le système
doivent être compatibles avec les normes internationales.
a. Accès au système
1) Mots de passe liés par individu ;
2) Mots de passe stockés et transmis dans un format chiffré ;

3) La fréquence maximum de changement de mot de passe doit être définie ;
4) le terminal doit être désactivé après trois tentatives non réussies de connexion ;
5) Désactivation automatique d'une connexion après un temps d’inactivité pré défini.
Chaque utilisateur a un menu adapté, qui fournit les taches auxquelles il a accès. Les profils
d'utilisateur doivent être définis sur le système central.
L’accès à toutes les fonctions centrales du système, est assujetti aux besoins de sécurité.
b. Audit
1) Accès individuel pour être surveillé et évalué ;
2) Identification de l'utilisateur ;
3) Heure de déconnexion ;
4) Temps de travail ;
5) Délais d’inactivité du terminal ;

6) Nombre de terminaux (postes de travail) ;
7) Nombre de tentatives de connexion non réussies ;

8) Journal de tous les messages et annulations d'erreurs ;
9) Les rapports sur les actions des utilisateurs doivent être disponibles :
tentatives de connexion, création, déplacement, mises à jour de données,
etc.
La mise à jour en temps réel de données statiques doit être contrôlée à des fins de sécurité, toutes
les modifications doivent être incluses avec des références dans les pistes d'audit de traitement de
fin de journée(TFJO), à la date d'utilisation et à l'heure de toutes les modifications.
c. Transmission de Données
1) Toutes les transactions doivent être sécurisées conformément aux recommandations
de la norme PCI-DSS ;
2) La détection des modifications non autorisées dans une transaction, par exemple
pendant sa transmission sur le réseau, doit être assurée ;
3) La solution proposée doit pouvoir employer les deux mesures de sécurité basées sur le
logiciel et le matériel de sécurité (HSM).
c.1. Sûreté :
1) Tout équipement ne doit pas excéder70décibels de bruit ;
2) Tout l'équipement électronique qui émet de l'énergie électromagnétique doit être

certifié conformément aux normes d'émission en vigueur, par exemple, FCC des USA
classent B ou en 55022 et en 50082-1 ou équivalent ;
3) Le serveur (base de données, application, test et développement) doit être de type 64

bits RISC ou processeur équivalent capable de traiter300 transactions par seconde sur
le Switch Monétique National, et de traiter la transaction en moins de 5 secondes ;
4) 19 pouces comme taille standard du châssis 47 U, le RoHS conforme, le KVM avec
16 ports minimum et doit être capable de prendre en, charge le clavier et le dispositif
de pointage.
c.2. Surveillance et mesure

1. Tous les accès au système, aux transactions traitées par le système et les
changements affectant les contrôles d'accès, les paramètres du système, les
annuaires et les commandes et fonctions d'intégrité doivent être notés et rapportés
aux opérateurs du Switch national, et accessibles pour la récupération et l'analyse
quotidienne. Il ne doit pas être possible de modifier le contenu des informations
d'audit ;
2. Les informations suivantes doivent être fournies :
a. les contrôles des transactions journalières ;

b. Gestion de tous les utilisateurs de système (du Switch national et des
participants) et de leurs privilèges d'accès ;
c. Les tentatives d’accès non réussies ;
d. Le nombre, la fréquence et la source de transactions échouées et de fichiers

erronés ;
e. Tout comportement inhabituel d’un utilisateur autorisé, indiquant le risque

accru et/ou les tentatives de fraude.
c.3. 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'authentification forte de système, de dispositif
et d'utilisateur. Les possibilités d'authentification d'utilisateur doivent inclure
l'authentification par deux-facteurs ;
2. Le système doit permettre une structure hiérarchique d'utilisateur, telle qu'à
chaque participant (et également dans la région opérationnelle du Switch
national) il peut y avoir un administrateur local avec certains droits

additionnels (par exemple pour la réinitialisation du mot de passe) ;
3. La séparation des fonctions doit être strictement observée pour tous les
programmes et fonctions sensibles ;
4. Tous les accès doivent être évalués pour inclure le système ou l'identification
de dispositif physique, l'identification d'utilisateur et la période de chaque
accès afin de fournir une vérification rétrospective claire pour la revue en cas
de violation accidentelle ou délibérée des règles de sécurité ;
5. Le système doit imposer la gestion saine de mot de passe. Cela inclut

l'utilisation de mots de passe suffisamment complexe ;échéance périodique
prédéfinie de changement obligatoire des mots de passe; suspension
automatique du compte après un nombre prédéfini de tentatives non réussies
de connexion; ne pas permettre la réutilisation des « n » derniers mots de passe
précédemment utilisés(« n » étant prédéfini);
6. Des postes de travail d'accès à l’application doivent se déconnectés
automatiquement après une période d’inactivité, pour empêcher l'accès par les
tiers non autorisés si le poste est laissé sans surveillance ;
7. Les procédures d’ouverture de journée de système doivent inclure le

déclenchement des systèmes, la confirmation des systèmes directement
connectés et l’authenticité de chaque système connecté.
c.4. Opération Fiable

1. Le système doit fournir un très haut niveau de disponibilité. Le système doit
donc être configuré pour pouvoir récupérer automatiquement n'importe quelle
défaillance et ce, sans l'interruption de service ;
2. Le système doit pouvoir finaliser le traitement de toutes les transactions du
jour dans un maximum de deux heures après une fin de journée normale.
5.2.1. Exigences de Traitement

La MULTIPAYexige le niveau le plus élevé de l'exécution, de la disponibilité et de la fiabilité
du système. Le système sera donc mis en œuvre pour fonctionner à deux emplacements.
D’autres environnements pour le test, les statistiques, la formation, etc. seront également
déployés sur le site principal.
En outre, la MULTIPAYcopiera régulièrement toutes les données sur des cassettes de manière
quotidienne, hebdomadaire, mensuelle, semestrielle et annuelle ;et les stocker dans un endroit
sécurisé hors du site nominal.
a. Résilience Opérationnelle
Tous les serveurs doivent être conçus et configurés pour fournir les niveaux élevés de fiabilité, de
résilience et de disponibilité. Le système du site primaire doit mettre à jour en temps réel le site
de secours (et vice versa) de sorte que, en cas d'un incident à un emplacement, l'autre
emplacement puisse continuer de fonctionner de préférence sans intervention manuelle.
Durant l’exploitation, un basculement régulier doit être effectué entre le site primaire et le site de
secours pour s’assurer que tous les systèmes fonctionnent correctement. Quand le site de secours
agit en tant que centre principal, il doit garder la base de données à l'emplacement primaire
entièrement synchronisé.
La préférence est que La Société Monétique Interbancaire du Congo fonctionne en parallèle sur
les deux sites avec une répartition de charge (ou l'équivalent) entre eux. De cette façon, l’échec
d'un serveur, à l'emplacement primaire ou alternatif, n'interrompra pas l'opérationnalité du
système. De plus, aucune interruption de service ne doit être constatée durant la mise à jour du
système.
Les soumissionnaires doivent préciser clairement les pré requis, et faire des recommandations
appropriées pour atteindre ce haut niveau de disponibilité et de la fiabilité du Switch National.
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 de service exigés. Elles
doivent également inclure les scénarios des cas extrêmes exigeant un basculement complet vers
un site (primaire ou de secours).
b. L'environnement de test
Un environnement de test doit être disponible à tout moment pour les tests des changements de
système prévus, ou les tests d'interfaçage des participants. 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 SMIC, la BCC,
ACB, les institutions financières, les organismes gouvernementaux et tout autre
système des tiers ;
2. Test des opérationssur tous les composants du système ;
3. Test des changements de paramètre faits par l'opérateur du système.
On s'attend à ce que l'exécution initiale du système suive ce processus.
5.2.2. Matériel, logiciel et communications

Le fournisseur retenu devra examiner tout le matériel, logiciel système, logiciel personnalisé et
autres produits et équipements nécessaires pour exploiter le système.
a. Matériel
Les soumissionnaires doivent indiquer les détails complets de tous les éléments du matériel
nécessaires au fonctionnement de leur solution. Ceci doit inclure les détails de tous les matériels
qui peuvent être nécessaires pour être installés par les participants.
Tous les composants du système devront fonctionner sans une nécessité de mise à niveau durant
une période de trois ans minimum à partir de l'acceptation opérationnelle. Les offres matérielles
doivent inclure tous les services relatifs et couvrir (comme applicable) les services de
maintenance et de support.
b. Caractéristiques des supports et des serveurs

Les matériels du Switch national doivent être livrés dans des supports qui doivent inclure tous les
composants nécessaires dans son environnement tels que des fils, des câbles et des systèmes de
ventilation. Les supports doivent contenir les composants suivants :
1. Serveurs ;
2. Stockage de données ;
3. Protection de données ;
4. Switch de KVM, affichage à cristaux liquides de KVM et clavier ;
5. Alimentation d'énergie non interruptible ;
6. Équipement de réseau ;
7. Autres Matériels.
b.1. Serveurs
Les propositions doivent indiquer en détail tous les composants des serveurs proposés, ainsi que
tous les articles nécessaires pour la connexion à l'environnement informatique existant pour les
membres de l'ACB, d'autres participants, ainsi que la BCC.
Des serveurs doivent être systématiquement reproduits et configurés en réseaux pour fonctionner
en mode de haute disponibilité. Le basculement du serveur en panne vers le serveur de secours à
chaque emplacement (rétablissement de production suite à un sinistre) doit être automatique sans
perte de service aux participants du système.
Chaque serveur doit être équipé d’une alimentation électrique spécifique, de cartes réseaux
redondants, des ventilateurs redondants et des baies de stockage redondants. Chaque serveur sera
équipé d’un système de stockage interne protégé qui sera utilisé pour des fichiers de logiciel
d'exploitation. Tous les composants complémentaires spécifiques doivent être activés
automatiquement en cas d'échec d'un composant primaire. Tous les composants complémentaires
doivent être changeables à « chaud » c'est-à-dire remplacés sans interruption de service.
Les soumissionnaires doivent décrire toutes les options du logiciel d'exploitation,

version/variante, niveau de compensation, tous les modules additionnels et facultatifs, et (si
désiré) leur option préférée. La proposition financière de ces options doit être incluse dans l’offre.
Les propositions doivent indiquer en détail tous les composants de serveur proposés, ainsi que
tous les articles nécessaires pour la connexion à l'environnement existant.
b.2. Stockage de données

Les propositions doivent indiquer en détail la capacité et l'équipement de stockage de données
approprié. Ceci doit supporter la volumétrie actuelle et prévisionnelle défini dans le présent appel
d’offre et prendre en compte les copies de la base de donnée(s) du système.
b.3. Protection de données

La solution de protection de données doit être basée sur le logiciel d'un des principaux
fournisseurs de système de gestion de bases de données relationnelles. Les différentes options
sécuritaires et de protection des données de cette solution doivent être mise en œuvre.
b.4. Onduleur
L'onduleur doit pouvoir avoir au minimum 30 minutes d'autonomie pour le matériel et les
télécoms installés sur le site de production, ainsi que l’environnement de reprise en cas de sinistre
et les environnements de Test/Développement.
c. Caractéristiques de réseau et de communications

(i) Spécifications de Switch de ferme de Serveur :Le commutateur de couche 3
Cisco48 ports Gigabit PoE avec 4 SFP Uplink et module ou équivalent est
permis ;
(ii) Spécifications de Switch d'accès :Le commutateur Cisco 10/100 48 ports PoE
comprenant 2 ports SFP Uplink;
(iii) Spécifications des routeurs :Le routeur Cisco avec interface WIC suffisante (2
ports fibre optique avec le module, 18 Ethernet rapides, 4 Ethernet gigabit) pour
relier les banques, non banques et l'infrastructure existante de la BCC;
(iv) Pare-feu ou spécifications de dispositif de sécurité : pare-feu Cisco avec ports

Gbps disponibilité élevée Actif-Actif avec les interfaces suffisantes (ports fibres
avec modules, FastEthernet, gigabitEthernet) pour relier les banques, non
banques et infrastructure existante de la BCC et de MULTIPAY;
(v) Les spécifications HSM : conforme à RoHS, un HSM capable d'effectuer 1200
opérations par seconde, qui prend en charge l'algorithme de cryptographie de clé
asymétrique RSA et une large gamme de signature numérique (3DES, SHA-1,
ANSI X9, etc.), et de connectivité (Série, Ethernet Raw 8803 ISO, TCP/IP sur
Ethernet) sera en mesure d'utiliser des certificats numériques émis par toutes les
autorités de certification.
Tous les équipements réseaux (routeurs, firewalls, serveurs d'accès, etc.) doivent être fournis.
L'équipement réseau qui sera utilisé pour la production et les emplacements de DR
(DesasterRecovery) doit être configuré pour travailler en mode de haute disponibilité.
L'équipement de secours doit être automatiquement activé en cas d'échec de l'équipement
primaire sans interruption de service ni pertes de données des participants. Tous les câbles seront
dûment marqués. Les prises électriques seront câblées et alimentées par deux sources
indépendantes d’énergie.
d. Autre Matériel
Les offres doivent inclure des détails de tout autre matériel exigé par leur solution.
e. Caractéristiques logicielles
(i) Utilitaires de système logiciel et de système de gestion :s’agira de la version la plus
récente de 64 bits avec les licences requises ;
(ii) Le soumissionnaire doit fournir la protection anti-virus conforme à celle que la BCC
et les Banques utilisent actuellement ;
(iii) Les soumissionnaires doivent préciser le nombre de client optimal pour la base de
données ;
(iv) Oracle 11g entreprise ou équivalent, ou version plus récente 12c. La méthode de
licence utilisée pour les serveurs de production, les serveurs de test et de
développement sera basée sur le nombre d’utilisateurs (minimum de 50 utilisateurs).
La base de données sera montée en cluster.
e.1. Logiciel du Participant

En plus du logiciel requis pour le Switch Monétique National, les soumissionnaires doivent
spécifier en détail tous les produits logiciels (requis et optionnels) qui seront installés auprès de
chaque organisation participante, y compris les exigences pour faire le traitement de bout en bout
(STP).
e.2. Logiciel système

En plus des systèmes d’exploitation des serveurs, les soumissionnaires doivent clairement
spécifier en détail tout autre logiciel système dont ils auront besoin pour exécuter les applications
de la monétique.
e.3. Logiciel de base de données

Les offres devront énoncer tous les logiciels de gestion de base de données (SGBD) sur lequel
leur système proposé fonctionnera. Ceci devrait inclure le niveau de version/release et tous les
modules facultatifs proposés, et (si désiré) le SGBD préféré/recommandé du soumissionnaire.
De détails complets d'évaluation devraient être donnés pour tous les produits de SGBD, options
et détails d'autorisation pour les serveurs de base de données proposés et n'importe quel autre
matériel affecté.
Les soumissionnaires devraient fournir une description de toutes les fonctionnalités spéciales du
logiciel de gestion de base de données qui sont utilisés par leur application, par exemple, la
réplication automatique de base de données pour faciliter la haute disponibilité.
f. L’éditeur de rapport
Les offres devront inclure des outils standards de production d'états de base de données faciles à
utiliser et qui peuvent être utilisés pour le développement rapide des rapports afin de satisfaire
aux besoins qui peuvent surgir. Les offres devraient également indiquer si ces outils sont fournis
en tant qu'une partie intégrante du package(s) proposé du logiciel d'application ou sont offerts
comme produit distinct.
g. Facturation
Réponse attendue : le soumissionnaire devra préciser, dans son offre, les options possibles des
services facturés, aussi bien par la MULTIPAYelle-même que par les participants, le mode de
calcul des frais ainsi que la possibilité, pour l’administrateur, de pouvoir configurer, par
paramétrage, les différentes possibilités offertes par le système et convenues entre participants.
h. Conception du réseau et de télécoms

MULTIPAYdevrait être fourni avec tous les équipements et logiciel nécessaires de gestion de
réseau pour les deux sites : production et secours. Les soumissionnaires devront fournir les détails
complets concernant l'infrastructure réseau :
1. Caractéristiques des équipements ;
2. Conception de réseau avec des diagrammes de topologie et des configurations IP ;

3. Caractéristiques de logiciel relatif au réseau (telles que VPN, NTP, pare-feu, etc.).
i. Redondance
Tous les composants de gestion de réseau devraient être systématiquement dupliqués pour
s'assurer qu'aucun point de défaillance n'existe. Les soumissionnaires sont invités à fournir le
diagramme schématique détaillé qui s'applique à leur solution. Le diagramme devrait montrer
l'architecture du site principal et du site de secours. Le câblage interne devrait utiliser des câbles
de la catégorie 6 ou plus récente, et tout équipement télécoms devrait supporter du gigabit
Ethernet ou une technologie plus récente.
j. Zones réseau
L’infrastructure réseau du Switch national doit se baser sur des LAN standards (VPN pour les
sites distants) et fournir des zones de sécurité de sorte qu'ouvrir une brèche de sécurité d'une zone
ne compromette pas la sécurité du reste du système.
La sécurité du réseau devrait être assurée par « firewalling » (mise des pare-feu) des zones de
réseau. Les serveurs et les postes de travail ne devraient pas avoir des connexions à Internet mais
uniquement aux ressources nécessaires (telles que LDAP, NTP, courrier, etc.)si disponible
localement.
k. Interfaces avec les autres logiciels

Le soumissionnaire devra fournir la description technique détaillée sur les interfaces en ce qui
suit :
1. La MULTIPAYdoit avoir des interfaces avec tous les DAB/GAB, TPE, Gateway
e- Commerce, l’Internet Banking, et toute solution déployée par une banque, un
groupe de banques ou un fournisseur tiers de service de payement ;
2. Le MULTIPAYdoit avoir des interfaces avec les opérateurs télécoms du pays
faisant le Mobile Banking ;
3. Le MULTIPAYdoit avoir des interfaces avec les réseaux internationaux dont
VISA international et MasterCard ;
4. Le MULTIPAYaura une interface avec l'ATS de la BCC et éventuellement le
système de gestion des risques ;
5. Le MULTIPAYaura une interface avec les Institutions de Micro finance et avec la
Banque Postale.
l. Interfaces réseaux externes

Les sites de production et de secours du Switch national auront les interfaces suivantes :
1. Interfaces LAN ;
2. Connexions VPN Interbancaires ;

3. Connexion à l'ATS de la BCC ;
4. Connexion SADC, COMESA ;

5. Connexion IPS.
Deux ports Gigabit Ethernet seront utilisés pour relier physiquement le site du Switch national au
"monde externe" - au LAN et au VPN interbancaire. Le type de connexion au réseau
interbancaire sera défini en coopération avec le fournisseur dudit réseau. par fibre avec la bande
passante de backup si disponible pour relier physiquement MULTIPAYet Connexion les
plateformes monétiques des banques participantes.
m. Sauvegarde et Restauration (Backup/Recovery)

Le site de secours aura les mêmes configurations matérielles et logicielles que le site de
production. En cas de défaillance sur le site primaire, les terminaux DAB/GAB/TPE doivent
automatiquement accéder au site de secours. La réplication des données doit se faire en temps
réel.
Le soumissionnaire remettra un plan de formation répondant aux articles énumérés ci-dessous :
 Conception de formation avec syllabus et planning ;
 Formation de l'équipe d'implémentation ;
 Formation des personnels IT ;
 Formation des personnels métiers.
La formation préalable à la livraison du système est basé sur un mélange des cours de formation
technique/opérationnelle à l’étranger et au pays pour la BCC ainsi que pour les
banques/institutions participantes. La formation des utilisateurs de la BCC et d'autres participants
s'étendra sur les opérations, la mise en œuvre, l’exécution et la maintenance des systèmes.
13.1.1. Assistance au Démarrage et a

l’accompagnement.
Le soumissionnaire déléguera le personnel technique adéquat pour préparer le système au
fonctionnement opérationnel une fois la plateforme sera fonctionnelle.
Par ailleurs, le soumissionnaire délèguera le personnel d’exploitation adéquat auprès du
MULTIPAYpendant une période de 12 mois calendaire à compter du Go Live du système, afin
d’assister les équipes de la MULTIPAYà la gestion de celui-ci et effectuer le transfert de
compétences dans ce domaine.
Le soumissionnaire déterminera les conditions pour une assistance similaire à l’endroit des
banques participantes (durée et coûts).
13.2. Documentation
D’autant plus que l’introduction de l’interopérabilité des systèmes monétiques est nouvelle au
Congo et que l’évolution des technologies est rapide dans ce domaine, la BCC s’attend à ce que
le contractant fournisse de très hauts niveaux de services de consultance et de conseil, en plus du
support technique, tout au long de la période de projet, en se basant sur son expérience
internationale d'implémentation des systèmes similaires.
Les soumissionnaires doivent donc fournir des détails du support qu'ils fourniront dans ce
domaine, non seulement en finalisant les caractéristiques fonctionnelles spécifiques du système,
mais en prenant également en charge les aspects tels que le développement des règles et des
procédures opérationnelles, des systèmes de facturation, et de tous autres domaines où le
soumissionnaire estime qu'il peut offrir des conseils sur les bonnes pratiques et la manière d'éviter
des pièges, et ce, en conformité avec les pratiques internationales. En particulier, le contractant
sera requis de fournir de la documentation d'exemples / de solutions types concernant des règles
du système, des accords avec les participants, les modes d’exploitation et les politiques de
facturation. Une pondération significative sera attribuée à cet aspect des propositions durant le
processus d’évaluation.
Toute la documentation doit être fournie en français. A certain minimum, la documentation
fournie devra inclure :
13.2.1. Manuel de Produit

Ceci devra décrire les différents composants de système, matériel et logiciel, qui indiquent les
volets fonctionnels et les pré-requis techniques de cette fourniture.
13.2.2. Documentation d'utilisateur

Ceci devra couvrir les documents suivants : guides d'opération, manuels opérationnels, et
manuels d'utilisateur standard. L'aide en ligne doit être fournie pour tous les modules du système.
13.2.3. Règles et procédures opérationnellesainsi que le

manuel de risque
Les propositions devraient couvrir la fourniture de consultance, de conseil fonctionnel, de
recommandations et de documentation modèle pour le développement des règles et des
procédures opérationnelles pour le système, basées sur une expérience précédente du
soumissionnaire. Les recommandations faites et la documentation modèle assurée devraient être
conformes aux meilleures pratiques internationales.
13.2.4. Documentation Technique

La documentation technique appropriée du matériel et aux systèmes qui sont fournis doit être
rendue disponible en format imprimé et électronique (Cd-rom, la clé USB, etc.).Un engagement à
fournir des versions mises à jour doit être donné.
Les manuels de procédures fonctionnels (imprimé et électronique) : Le soumissionnaire doit
fournir des manuels standards de procédés fonctionnels décrivant des procédures entières
fonctionnelles comprenant des procédures d'accès, procédures de contrôle, les vérifications
rétrospectives, etc. Le soumissionnaire doit fournir toutes les mises à jour de la documentation :
 La documentation devra être conforme aux normes internationales ;

 La documentation devra être facile à utiliser ;
 La documentation devra être ordonnées ;
 Des diagrammes et des schémas devront être fournis si possible pour faciliter la
compréhension pratique.
En outre elle devrait aussi inclure :
1. Caractéristiques fonctionnelles et descriptions de logiciel utilitaire ;

2. Caractéristiques et descriptions fonctionnelles de logiciel d'application ;
3. Documentation couvrant l'environnement de test ;

4. Instructions pour la protection, la restauration et la restauration sélective ;
5. Instructions pour commuter le traitement à ou vers le site alternatif ;

6. Documentation finale qui inclut les options retenues et les paramètres de
configuration ;
7. Guide de mise en place et d'installation ;
8. Guide d'utilisateur comprenant :

(i) Dispositions d'écran et dispositions de rapport ;
(ii) Sécurité de système et guide d'accès ;
(iii) Guide de vérification rétrospective de système ;
(iv) Toute autre documentation technique que la BCC devra employer pour le
fonctionnement sûr et efficace de l'environnement de traitement.
9. Plans d’interface/intégration pour l’ATS, le système comptable de la BCC et les
systèmes monétiques des banques participantes ;
10. Glossaire des termes.
13.2.5. Documentation des processus opérationnels

La documentation fournie par le soumissionnaire dans le cadre de la mise en œuvre de sa solution
doit être livrée en Français. Ceci devrait inclure :
o Manuel de Normes, procédures, protocole interbancaire ;
o Règles Interbancaires ;
o Guide Tarifaire Interbancaire ;

o Documentation Gestion de Litige (Dispute Mangement) ;
o Les manuels d’utilisation ;

o Les Guides d’installation et d’exploitation ;
o Les guides de références techniques relatifs aux aspects de développement autour

de la solution.
13.3. Période de garantie et Support continu

13.3.1. Période de Garantie
Service de Garantie : Tous les équipements matériels (serveurs) et logiciels doivent avoir une
période de garantie qui est en conformité avec les spécifications fournies dans les spécifications
techniques. Pendant la période de garantie, le fournisseur sera responsable de la réparation/du
remplacement/du support de tous les équipements fournis dans cette offre, ayant de défauts de
fonctionnement.
L’Acheteur exigera un support sur site pour la période de garantie comme décrit sur la table A-
les réparations et/ou le remplacement d'équipement devront être réalisé avec satisfaction de
l'acheteur dans les temps indiqués dans le Tableau B-). Une pénalité d'un pour cent (1%) du coût
de l'équipement relatif sera chargée par jour pour non-conformité de matériel et de logiciel
fournis avec le tableau mentionné ci-dessus.
Le soumissionnaire doit soumettre en tant qu'élément de leur proposition un plan détaillé de
support au matériel et logiciel fournis. Le fournisseur doit également assurer les incidents
suivants:
• Le soumissionnaire devra fournir la documentation appropriée du fabriquant de

produit qui se conforme au support continu 24x7x365 ;
• Le soumissionnaire devra fournir un support hot-line24x7x365 ;
• Le soumissionnaire devra entreprendre des actions immédiates de réparation en cas
de défaillance logicielle causant une interruption partielle ou totale de
fonctionnement des systèmes du centre serveur et/ou d’agence ;
• Le soumissionnaire doit informer la BCC de toutes les erreurs logicielles détectées
et les corriger dans les meilleurs délais possibles ;
• Le soumissionnaire devra offrir les nouvelles versions/releases du logiciel et
superviser leur implémentation dans des délais convenues ;
• Si une nouvelle version du logiciel est disponible et que l’acheteur utilise une
version antérieure, le soumissionnaire devra s’engager à fournir toute l’assistance et
support nécessaire à la version employée par l’acheteur pour une période d’au
moins 5 ans après la date De mise en service.
Le support sur les services logiciels doit être conduit sans compromettre la sécurité, ni
l’intégrité/perte des données et sans compromettre la disponibilité et la qualité de service
apportées aux banques et aux clients.
Tableau - A :Périodes de Garantie
Assistance aux utilisateurs/ligne directe (Hot-Line) : Le soumissionnaire devrait être en mesure

d’assister les utilisateurs de la CMM à distance grâce à la mise en place d’une ligne directe.
Le représentant local du fournisseur devra être formé, expérimenté et certifié techniquement,
pour fournir le support selon les conditions spécifiées dans le Tableau-B. le représentant local
doit fournir le service de Helpdesk pour le support et la garantie du logiciel et du matériel.
Ces conditions doivent être passées en revue mensuellement avec les actions satisfaisantes de
l’acheteur. Des actions d’inventaire de statuts des matériels de rechange devront être maintenues
et passées en revue par l'acheteur mensuellement.
La disponibilité de tous matériels de rechange de la même version ou de version plus élevée

compatible doit être assurée pour un minimum de 6 (six) années dès la date de la recette du
système.
Le soumissionnaire est responsable de la notification et de l'installation des nouvelles
versions/releases de logiciel pendant la durée convenue.
13.3.2. Support Continu

Pendant la phase d'essai d'homologation et d'installation, le personnel nécessaire de support
devrait être disponible pendant les heures de travail normales.
Au cours de la recette opérationnelle, le fournisseur établira un seul point de contact pour tous les
problèmes, matériel, logiciel ou équipement connexe. Le point de contact sera disponible tout au
long de la journée opérationnelle du système, qui sera convenue entre la BCC et le fournisseur
pendant l'exécution. Les offres devraient inclure des propositions pour le service de support
continu.
13.6.2.1. Help-Desk de la SMIC

Le fournisseur devra assister la BCC en établissant un service d’assistance aux utilisateurs pour
fournir le support de niveau application à tous les utilisateurs pendant les journées de
fonctionnement. Les propositions devront contenir des recommandations pour l'établissement et
le fonctionnement du help-desk, y compris le niveau du personnel requis, formation,
documentation, modes opératoires,...
13.6.2.2. Mises à niveau

Les soumissionnaires devraient également décrire leur méthodologie des mises à niveau,
d'approvisionnement en matériel et en logiciel pendant le cycle de vie du système afin de
s'assurer que la pleine formation est fournie sur les changements et des améliorations, et que la
continuité de service est garantie pendant les mises à niveau, les ajouts ou les changements de
logiciel.
L'entretien annuel commencera après que la garantie incluant toutes les mises à jour, les
correctifs de logiciel VISA/MasterCard/AMEX et les autres changements seront exempts de coût.
13.3.3. Gestion de Problème/Incident

Il devra être faciles pour la BCC d’enregistrer de manière continue les détails des problèmes avec
le fournisseur, pendant le projet, la période de garantie ou aux termes de n'importe quel accord de
niveau de service. Le reportage régulier devrait être un dispositif standard du système et devrait
inclure :
1. Le nombre d’incidents relatif à une rupture de service sur n’importe quelle période
choisie, selon la cause de la rupture et le nombre total des incidents ;
2. Le nombre d’incidents non relatif à une rupture de service signalé sur n’importe
quelle période choisie ;
3. Le temps pris pour la reprise de service normal après chaque rupture du service
enregistrée ;
4. Heure moyenne de réparer pour des échecs de matériel et de logiciel.
Les soumissionnaires devront également expliquer comment le personnel du Switch national peut
surveiller les problèmes et les signaler de façon régulière.
13.3.4. Contrat de Service

La BCC s'attend à un niveau très élevé de fiabilité et de disponibilité de tous les systèmes à
fournir, et le Switch monétique sera particulièrement crucial à cet égard. Comme précédemment
indiqué, le système fonctionnera en mode deux-sites, afin d’assurer le niveau très élevé de
fiabilité et de disponibilité.
La BCC signera un accord de niveau de service (SLA) avec le fournisseur pour le fonctionnement
continu des systèmes. Les attentes de la BCC pour le SLA incluent :
1. Pour le logiciel, il n'y aura pas plus de trois échecs de logiciel tolérés par an, et pas plus
d'une fois par mois. Un échec de logiciel est défini comme un événement où un
composant de l'application ne répond pas aux instructions de l’opérateur et n'exécute pas
sa fonction normale, et exige d’être manuellement remis en marche ou ne se remet pas en
marche. Dans tous les cas la durée de récupération d'un dysfonctionnement ne dépassera
pas 30 minutes.
2. Au cas où la performance du système est dégradée, cet incident doit être résolu en une
heure et ne doit pas retarder les traitements de fin de journée de plus de 30 minutes. Il n’y
aura pas plus d’un incident de ce genre par mois ou encore pas plus de trois incidents de
ce genre par an.
3. Pour le matériel et le logiciel système, la tolérance générale de disponibilité exigée par la

BCC est de 99.95% (où le temps d'arrêt est défini en tant qu'indisponibilité totale du
système). Les soumissionnaires sont priés de donner des détails des chiffres prévus de
fiabilité et de disponibilité pour la configuration réelle (matériel, logiciel etc…).
Page 32 sur 37
Multipay CONGO CAHIER DES CHARGES
------------------------------------------------------------------------------------------------
3.2.1 Fonctionnalités du switch monétique
3.2.1.1 Fonctionnalités de base du switch monétique :
Front-Office
- Front-Office TPE (avec possibilité à un agent de visualiser via un PC les informations d’une carte)
- Gestion du parc de TPE,
- Gestion des oppositions,
- Gestion de la sécurité des transactions,
- Interface avec le système d’information d’ADVANS BANQUE CONGO (ORBIT)
- Interface avec le serveur vocal de déclaration des oppositions,
- Délivrance d’autorisation,
- Gestion du risque.
Back-Office
- Gestion des porteurs,
- Gestion des autorisations,
- Gestion de la personnalisation (production des fichiers de personnalisation…),
- Gestion du risque,
- Gestion des aspects réglementaires (oppositions, incidents, déclarations,…),
Reporting
- Enumérer tous les types de reporting disponibles.
3.2.1.2 Fonctionnalités supplémentaires à prévoir :
- Interface avec le futur CTM (Centre de Traitement Monétique Interbancaire),

- Interface vers les réseaux internationaux (VISA/MASTERCARD) au travers du CTM ou en direct,
- Interface avec des opérateurs Télécom ...
3.2.1.3 Protocole :
Tous les protocoles livrés devront être à la norme EMV.
3.2.1.4 Normes :
La solution doit être conforme aux standards les plus répandus notamment ISO 8583 et EMV.
3.2.2 Fonctionnalités des TPEs
Les TPE offriront les fonctionnalités suivantes :
- Paiement sur carte bancaire en on-line ou off-line selon le plafond commerçant paramétrable,
- Télécollecte des transactions.
3.2.3 Analyse de l’activité monétique
Dernière M.A.J. : 08/02/2023 11:51

Page 33 sur 37
La solution proposée devra permettre de disposer de toutes les informations et de tous les rapports
nécessaires à une bonne analyse de l’activité monétique.
3.2.4 Liaisons avec le système d’information de ADVANS BANQUE CONGO
 Le serveur doit pouvoir fonctionner dans les configurations suivantes :

- en mode dégradé sur la base des soldes des comptes des porteurs de ADVANS BANQUE
CONGO ;
- en mode on-line avec une connexion permanente sur le système d’information.
 Le passage vers l’un ou l’autre mode se fera automatiquement.
 L’interface monétique et le serveur monétique vont s’échanger des messages permettant de connaître le
statut de l’interface ADVANS BANQUE CONGO (en ligne, déconnecté etc.)
 La remontée des avis d’autorisation délivrés en mode délégation se fera automatiquement dès la
disponibilité de l’interface ADVANS BANQUE CONGO
 Il est impératif que les modifications apportées à la base client du système d’informations de ADVANS
BANQUE CONGO soient prises en compte automatiquement par le système monétique. Il peut s’agir de
fermeture de compte, de mise en opposition etc.
3.3 SPÉCIFICATIONS TECHNIQUES

3.3.1 Localisation des terminaux utilisateurs et des serveurs informatiques
Le centre de traitement informatique de ADVANS BANQUE CONGO est localisé à son siège. Tous les
autres sites sont distants et sont reliés au centre de traitement par des liaisons spécialisées.
Tous les terminaux qui se connectent doivent pouvoir se connecter au serveur monétique.
Dernière M.A.J. : 08/02/2023 11:51

Page 34 sur 37
3.3.2 Localisation des serveurs monétiques
Les serveurs monétiques seront localisés au centre de traitement informatique.

Ils seront composés de façon optimale :
- d’un serveur de production et d’un serveur de backup fonctionnant en nominal/backup,
- d’un serveur de test, à défaut
- d’un serveur de production et de backup/test .
La mise à jour du serveur de backup se fera de manière optimale en temps réel ou à défaut en différé.
Le soumissionnaire pourra proposer toute autre option de manière à assurer une haute disponibilité du
système monétique.
3.3.3 Protocoles de communication
La solution devra s’appuyer sur les réseaux IP ou GSM/GPRS.

La connexion entre les TPE et le serveur se fera via le réseau IP ou GSM/GPRS
3.3.5 Equipements de base
Le soumissionnaire devra préciser :
- Le matériel nécessaire pour la mise en œuvre optimale de sa solution

o Type de serveurs,
o Equipements de communications,
o Equipements de sécurité (HSM par exemple),
o Etc.
- Licences de logiciels à acquérir

o Base de données,
o Système d’exploitation,
o Etc.
3.3.6 Equipements additionnels (et/ou équipements à mettre à jour)
Le soumissionnaire devra préciser le matériel additionnel à acquérir :
- Equipements de sauvegardes,
- Logiciels de sauvegarde,
- Postes de travail,
- Etc.
3.3.7 Volumétrie cible au démarrage
Au démarrage, ADVANS BANQUE CONGO projette de mettre en place 1 TPE par agence et
5.000 cartes.
A l’horizon de la 3ème année d’exploitation, elle compte atteindre 21.000 cartes. Et peut être
installer des entre 4 et 200 TPEs
Dernière M.A.J. : 08/02/2023 11:51

Page 35 sur 37
3.3.8 Types de cartes
ADVANS BANQUE CONGO envisage d’émettre des cartes à puce pour plus de sécurité. Elle pourrait
cependant émettre des cartes à pistes/puces dès la mise en place du projet, si la nécessité s’en fait sentir
(obligations liées à l’interbancarité).
L’évolution des cartes à pistes vers des cartes à pistes/puces pourra être décidée à tout instant si nécessaire.
La décision finale sera prise lors des études préalables d’implémentation du logiciel.
3.3.9 Outils de sécurisation des transactions et des serveurs
Le soumissionnaire devra préciser les équipements et logiciels nécessaires pour la sécurisation des
transactions et des serveurs.
3.3.10 Procédures, outils et ressources pour la gestion et la maintenance du système
Prière préciser quels sont les outils et procédures qu’il met en œuvre pour la maintenance du système.
Il peut s’agir par exemple :
- d’un support Hot-Line,
- d’une prise de contrôle à distance,
- d’un déplacement sur site,
- d’envoi de CD et de procédures de mise à jour,
- etc.
3.3.11 Performances
ADVANS BANQUE CONGO souhaite une très haute disponibilité de son serveur monétique.
Prière devra préciser :
- les temps de disponibilité moyens de son système,
- la fréquence et le nombre d’arrêts programmés en exploitation,
- la fréquence moyenne des mises à jour du logiciel,
- Quels sont les outils et l’architecture qu’il propose pour assurer une haute disponibilité du
système ?
3.3.12 Evolutivité de la solution
 La solution devra être modulaire et prendre en compte sans modification majeure, toutes les
évolutions techniques du secteur monétique.
 Elle devra être ouverte à d’autres services monétiques tels que le E-Commerce, le M-Commerce
etc.
 Le soumissionnaire donnera les possibilités d’évolution technologique ou fonctionnelle de son

propre logiciel ainsi que les coûts y afférent.
3.3.13 Plan de formation
 Fournir un plan de formation des utilisateurs et des administrateurs du système.

 Préciser les compétences et pré-requis des administrateurs du système.
3.3.14 Documentation requise
Dernière M.A.J. : 08/02/2023 11:51

Page 36 sur 37
- Le prestataire devra fournir toute la documentation nécessaire à une bonne gestion du système
monétique.
3.3.15 Impact sur l'organisation
Le prestataire doit fournir tous les documents techniques et organisationnels permettant à ADVANS
BANQUE CONGO de mieux apprécier les impacts sur son organisation.
3.3.16 Facteurs de qualité:

Le prestataire devra fournir un document qui explique la démarche qualité qui sous tend le projet.
3.4 SPÉCIFICATIONS DE RÉALISATION
3.4.1 Standards techniques
La solution devra être conforme aux standards les plus répandus notamment ISO 8583 et EMV.
3.4.2 Ressources
La solution devra se baser sur l’architecture réseau existante.
3.4.4 Calendrier des prestations
Le prestataire devra fournir un calendrier détaillé des prestations : début, fin, phases, check-points.
3.4.5 Contenu et calendrier des réceptions provisoires et définitives du projet
Le prestataire précisera la méthodologie, le plan et les outils requis pour effectuer les tests:
o fonctionnels, de performance et de qualité,
o de montée en charge du réseau et des applications, d'ergonomie,
o des fonctions de sauvegarde et de reprise;
3.4.6 Intégration
Le fournisseur retenu jouera le rôle d’intégrateur. Il travaillera en étroite collaboration avec le responsable
du projet désigné par ADVANS BANQUE CONGO et sera co-maître d’œuvre pour la suite du projet
notamment l’acquisition du matériel (serveurs, GABs, TPEs), l’intégration des différentes composantes,
l’interfaçage des différents logiciels informatiques concernés (notamment GABs et système d’information
de ADVANS BANQUE CONGO -
3.5 SPÉCIFICATIONS ADMINISTRATIVES

3.5.1 Solution complète :
Elle doit répondre au cahier des charges et former une entité complète, fonctionnelle, performante,
utilisable et de qualité (selon l'état de l'art en la matière).
3.5.2 Détail des coûts
- Licence du produit,
Dernière M.A.J. : 08/02/2023 11:51

Page 37 sur 37
- Frais d’ingénierie,
- Frais de la maintenance et du support,
- Durée de la garantie.
3.5.3 Détail du matériel à acquérir
Le soumissionnaire devra préciser le détail du matériel à acquérir pour la mise en œuvre de sa solution
conformément aux paragraphes 3.3.5 et 3.3.6.
3.5.4 Détail des logiciels à acquérir :
Le soumissionnaire devra préciser le détail des logiciels à acquérir pour la mise en œuvre de sa solution.
3.5.5 Modalités de paiement
Le soumissionnaire devra préciser les modalités de paiement.
3.5.6 Conditions d'exécution
Le soumissionnaire devra préciser la nature des travaux qui seront réalisés chez lui, et celle des travaux qui
seront réalisés à ADVANS BANQUE CONGO.
3.5.7 Clauses de confidentialité
Le demandeur s'engage à garder la confidentialité sur l'offre du soumissionnaire, le soumissionnaire

s'engage à garder la confidentialité sur le projet.
3.5.8 Documents administratifs
o Description du soumissionnaire (bilan, résultats, années d'existence, identification des

responsables, taille de la société…) ,
o Références et travail sur un projet similaire,
o Noms et curriculum des personnes proposées pour réaliser le projet,
o Partenariats éventuels dans le cadre du projet;
3.5.9 Conditions des offres
Les offres doivent être déposées à …………………………………
Elles sont valables pour 90 jours minimum à compter du ………………
Dernière M.A.J. : 08/02/2023 11:51

MPC - OPE - IT - Cahier de Charges - V0.1 (Enregistré Automatiquement)

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

MPC - OPE - IT - Cahier de Charges - V0.1 (Enregistré Automatiquement)

Transféré par

Droits d'auteur :

Formats disponibles

Section VII.

Modèles des formulaires 1

PROJET SWITCH MONETIQUE

1 – DESCRIPTION ET CONTEXTE DU PROJET

Présentation générale de Multipay CONGO

Description générale du projet

 services monétiques interbancaires (interopérabilité des transactions).

 La gestion du système d’information nécessaire à la supervision, à la sécurité et au bon fonctionnement du

- une offre technique détaillée de la solution ;

b. Type des cartes

Nombre de DAB/GAB : + 480

Nombre de TPE : + 6186

4- Spécifications Techniques et Fonctionnelles

(i) Gérer le fonctionnement d'un système intégré et interopérable de distributeur automatique

d. Gestion du Mobile Payment

Le module de règlement doit inclure des mécanismes mais non limité :

 Tous les rapports doivent être disponibles à cette fin ;

g. Interfaçage aux systèmes de banque participant

1. Interfaçages avec les participants domestiques

2. Réseaux Internationaux de Carte de Paiement

3. Institution Financières et autres Participants

Le MULTIPAY doit aussi permettre à l’administrateur du système de pouvoir intégrer de nouveaux

4. Interface de paiement sur Internet (e-Commerce)

5. Intégration avec les systèmes bancaires des participants

i. Intégrité de message et responsabilité

Le contrôle devra inclure ce qui suit :

6. Là où un opérateur a la possibilité de faire n'importe quel changement sur n'importe quel

7. Il devra être possible que la gestion opérationnelle puisse tracer automatiquement

9. En cas de panne conduisant à l'indisponibilité du site principal, la reprise du service dans

k. Sûreté & Sécurité

2) Mots de passe stockés et transmis dans un format chiffré ;

5) Désactivation automatique d'une connexion après un temps d’inactivité pré défini.

5) Délais d’inactivité du terminal ;

7) Nombre de tentatives de connexion non réussies ;

2) Tout l'équipement électronique qui émet de l'énergie électromagnétique doit être

3) Le serveur (base de données, application, test et développement) doit être de type 64

c.2. Surveillance et mesure

a. les contrôles des transactions journalières ;

d. Le nombre, la fréquence et la source de transactions échouées et de fichiers

e. Tout comportement inhabituel d’un utilisateur autorisé, indiquant le risque

c.3. Contrôles d'accès

national) il peut y avoir un administrateur local avec certains droits

5. Le système doit imposer la gestion saine de mot de passe. Cela inclut

7. Les procédures d’ouverture de journée de système doivent inclure le

c.4. Opération Fiable

5.2.1. Exigences de Traitement

1. Gestion des changements impliquant le matériel, le logiciel système et le

On s'attend à ce que l'exécution initiale du système suive ce processus.

5.2.2. Matériel, logiciel et communications

b. Caractéristiques des supports et des serveurs

Les soumissionnaires doivent décrire toutes les options du logiciel d'exploitation,

b.2. Stockage de données

b.3. Protection de données

c. Caractéristiques de réseau et de communications

(iv) Pare-feu ou spécifications de dispositif de sécurité : pare-feu Cisco avec ports

e.1. Logiciel du Participant

e.2. Logiciel système

e.3. Logiciel de base de données

h. Conception du réseau et de télécoms

2. Conception de réseau avec des diagrammes de topologie et des configurations IP ;

k. Interfaces avec les autres logiciels

l. Interfaces réseaux externes

2. Connexions VPN Interbancaires ;