Guide Participants ACP-ACH FR 22112013 GN V.1.0.2

Rue lac Ghar El Melh
Les berges du lac

1053 Tunis – Tunisie
Phone : +216 71 962.030
Fax : +216 71 961.299
www.bfigroupe.com
Ref.: BFI.WAMI.26062010. GUIPART.1.0.1
Auteur : BFI Date: 26/06/2010
ACP / ACH
GUIDE DES PARTICIPANTS
Version : 1.0.1 164 pages
Projet Système ACP /ACH Sous Projet Guide Participant

Statut Ebauche
Date de mise à jour 07/10/2010
En Cours de Validation
 Validé Page : 1/164
Ce document est la propriété intellectuelle de BFI.
Il ne peut pas être recopié, vendue, ni donné, en totalité ou par

extraits, en aucune façon ni via aucun média, sans l’autorisation écrite
et préalable de BFI.

Statut Ebauche
Rédaction, Vérification et Approbation du présent document
RÉDACTEURS VÉRIFICATEURS APPROBATEURS
NOM ET PRÉNOM DATE NOM ET PRÉNOM DATE NOM ET PRÉNOM DATE
BFI 26/06/2010 BFI WAMI
Diffusion
POUR ACTION POUR INFORMATION

NOM ET PRÉNOM INSTITUTION NOM ET PRÉNOM INSTITUTION
Equipe projet Banque Banque Centrale
Centrale de la Gambie de la Gambie
Equipe projet Banque de Banque de

Sierra Leone Sierra Leone
Equipe projet Banque Banque Centrale

Centrale de la Guinée de la Guinée
Institutions participantes
Historique des versions
Version Rédacteur Commentaires
1.0.0 BFI Rédaction du document

07/10/2010 : Mise à jour du document
- Mise à jour du planning de mise en œuvre (page

85)
- Ajout d’explications sur les séparateurs MICR :
CMC7 et E13B (page 92)
- Suppression de la description du champ code état
1.0.1 BFI
de la ligne MICR. (page 92)
- Correction des noms des fichiers data Cumules et
globaux (page 118).
- Ajout des contrôles logiques et réglementaires
(voir document des contrôles logiques et
réglementaires).

Statut Ebauche
Plan du document
1 Introduction_________________________________________________________________7
1.1 Définitions communes____________________________________________________________7
1.2 Extension des fichiers___________________________________________________________13
2 Presentation du project________________________________________________________16
2.1 Contexte du project_____________________________________________________________16
2.2 objectifs du Projet______________________________________________________________16
2.3 Intervenants du projet___________________________________________________________17
2.4 comités de pilotages_____________________________________________________________18
2.4.1 Comité de suivi des pré-requis___________________________________________________________18
2.4.2 Equipe Projet au sein de la Banque Centrale_________________________________________________18
2.5 Présentation du projet___________________________________________________________19
3 description Fonctionnelle du système ACP/ACH___________________________________21
3.1 Aspects Généraux_______________________________________________________________21
3.1.1 Codes pays et devises__________________________________________________________________21
3.1.2 Participants__________________________________________________________________________21
3.1.3 Moyens de paiement___________________________________________________________________22
3.1.4 Codes enregistrement/remises____________________________________________________________24
3.1.5 Codes Centre de compensation___________________________________________________________25
3.1.6 Propriétés des valeurs__________________________________________________________________25
3.1.7 Profil de journée______________________________________________________________________27
3.2 Architecture et schéma des flux___________________________________________________30
3.2.1 Sens aller Compensation________________________________________________________________30
3.2.2 Sens retour Compensation_______________________________________________________________31
3.3 Description fonctionnelle de la solution_____________________________________________32
3.3.1 Description fonctionnelle du module Barberousse Capture_____________________________________32
3.3.2 Description fonctionnelle du module Générateur de clés_______________________________________46
3.3.3 Description fonctionnelle du module Barberousse GIP________________________________________47
3.3.4 Description fonctionnelle du module Générateur de clés Siège__________________________________53
3.3.5 Description fonctionnelle du Module Autocollecte___________________________________________54
3.3.6 Description fonctionnelle du Module ADT__________________________________________________59
3.3.7 Description fonctionnelle du module Hannibal-PosteAdherent__________________________________74
4 Planning de mise en œuvre____________________________________________________87
5 Pre-Requis à la Mise en Place du système_________________________________________88
5.1 Normes des chèques et des effets__________________________________________________88
5.1.1 Format physique des chèques et grammage_________________________________________________88
5.1.2 Structure de la ligne MICR des Chèques___________________________________________________89
5.1.3 Formatage de la ligne MICR E13B/CMC7__________________________________________________90
5.1.4 Normes des Effets_____________________________________________________________________93
5.2 Format des RIB________________________________________________________________93
5.3 Clés de contrôle (MODULO 97)___________________________________________________93
5.3.1 Clé de contrôle du compte (Modulo97)_____________________________________________________93
Statut Ebauche
5.3.2 Clé de contrôle MICR (Modulo97)________________________________________________________94
5.4 Gestion des échanges____________________________________________________________96
5.4.1 Formats d’Echange____________________________________________________________________96
5.4.2 Contrôle des fichiers___________________________________________________________________98
5.5 Equipements__________________________________________________________________101
5.5.1 Équipements fournis par les Banques Centrales_____________________________________________101
5.5.2 Equipements à acquérir par les Participants________________________________________________102
5.6 Réseau_______________________________________________________________________103
5.7 Sécurité______________________________________________________________________103
5.7.1 Sécurité d’Accès physique_____________________________________________________________103
5.7.2 Sécurité Réseau______________________________________________________________________104
5.8 Interfaçage entre ACP/ACH et le système d’information de la banque (CBS)____________104
5.8.1 Génération des fichiers ENV de virements_________________________________________________104
5.8.2 Génération des fichiers ENV de prélèvements______________________________________________105
6 Interfaçage Participants______________________________________________________107
6.1 Interfaçage des applications Agence avec le système d’information_____________________107
6.1.1 Système d’information agence vers les modules agence______________________________________107
6.1.2 Modules agences vers le SI de l’agence___________________________________________________110
6.2 Echanges entre les modules Siege et le SI de la banque_______________________________112
6.2.1 SI de la Banque vers les modules du siège_________________________________________________112
6.2.2 Modules du siège vers le SI de la Banque__________________________________________________113
7 Désignation de l’équipe projet_________________________________________________115
8 Planification des formations__________________________________________________116
8.1 Formations assurées par BFI____________________________________________________116
8.1.1 Formations des utilisateurs_____________________________________________________________116
8.1.2 Formations des administrateurs__________________________________________________________116
8.1.3 Formations des informaticiens__________________________________________________________117
8.1.4 Formations des installateurs____________________________________________________________117
8.2 Formations à assurer par les participants__________________________________________117
9 Annexes___________________________________________________________________118
9.1 Structures de noms des fichiers__________________________________________________118
9.1.1 Structure des noms des fichiers (.DATA)__________________________________________________118
9.2 Structure des noms de remises numériques (.ENV/ RCP)_____________________________119
9.3 Structure des noms de fichiers image CAT & PAK__________________________________119
9.4 Structure de noms des autres fichiers émis par le centre de compensation_______________120
9.4.1 Structure de nom de fichiers des rejets règlementaires (.RJT)__________________________________120
9.4.2 Structure de nom de fichiers des Situations nette détaillées____________________________________120
9.4.3 Structure de nom de fichiers de Situation nettes Globales_____________________________________121
9.4.4 Structure du nom de fichier échéancier de règlement (.ECH)___________________________________121
9.4.5 Structure du nom de fichier compte rendu (CRS/CPR)_______________________________________122
9.4.6 Structure du nom de fichier compte rendu opération (CRO)___________________________________122
9.5 Structures des fichiers de données des présentations, de rejets et d’annulations__________123
9.5.1 Structure des fichiers DATA (.Data)______________________________________________________123
9.5.2 Virements / Virements représentés_______________________________________________________128
9.5.3 Virements en provenance de l’Etranger (ENV/RCP)_________________________________________132
9.5.4 Prélèvements (ENV/RCP)______________________________________________________________136

Statut Ebauche
9.5.5 Chèques____________________________________________________________________________139
9.5.6 Lettre de change_____________________________________________________________________143
9.5.7 Transactions Cartes___________________________________________________________________148
9.5.8 Message libre________________________________________________________________________151
9.5.9 Avis de Non paiement_________________________________________________________________153
9.5.10 Attestation de Reconstitution de Provision_______________________________________________157
9.5.11 Structures des Remises de rejets techniques______________________________________________160
9.5.12 Structures Des Comptes rendus_______________________________________________________161

Statut Ebauche
1 INTRODUCTION
Le présent document constitue un guide des participants qui permet aux institutions
participantes d’avoir un aperçu général du nouveau système ACP/ACH. Ce document permet
aux participants d’identifier les changements apportés par ce nouveau système et qui doivent
être pris en charge lors de la phase d’implémentation.
Ce document expose les éléments suivants :
 Contexte du Projet
 Présentation du Système
 Normes et formats d’échange
 Description fonctionnelle des modules de la solution
 Etapes et planning du projet
 Pré-requis des participants
1.1 DÉFINITIONS COMMUNES
ACP Automated Cheque Processing: traitement automatisé des

chèques
ACH Automated Clearing House: Chambre de compensation

automatisée.
ADT Automatic Data Processing : Permet le traitement automatique

des fichiers à image et des fichiers de .ENV reçus à partir du
système d’information ou des agences de la banque.
Adresse IP Champ numérique propre à chaque machine lui servant

d’identifiant dans un réseau.
Algorithme Algorithme qui permet le cryptage des données et des images

asymétrique RSA avec une clé publique et le décryptage avec une clé privée.
Algorithme symétrique Algorithme qui permet le cryptage et le décryptage avec la

DES même clé (la clé triple DES).
Altération Modification ou perte des données d'une image chèque ou lettre

Statut Ebauche
de change.
Archivage des clés Stockage des clés dans une base de données.
Authentification Opération de vérification de l'intégrité d'une image chèque ou

lettre de change.
Bac de rejet Emplacement au niveau du scanner où seront acheminées les

valeurs présentant une anomalie lors de la scannérisation.
Bac principal Emplacement au niveau du scanner où seront acheminées les

valeurs scannées avec succès.
Boîte aux lettres BAL - Structure informatique dans laquelle sont échangées les
fichiers entre les différents modules de la solution.
BAL IN Boite aux lettres dans laquelle sont déposés les fichiers reçus.
BAL OUT Boite aux lettres dans laquelle sont déposés les fichiers à
envoyer.
BAL TMP Boite aux lettres temporaire utilisée par une application.
Banque destinataire La contrepartie de la banque remettante, i.e. celle dont le

compte sera impacté par l’opération de compensation. La
banque destinataire et la banque réceptrice sont les mêmes pour
les remises reçues par le participant direct pour son propre
compte.
Banque présentatrice Banque qui présente la remise au système de compensation. Elle

est obligatoirement un participant direct. La banque remettante
et la banque présentatrice sont les mêmes pour les
présentations faites par le participant direct pour son propre
compte.
Banque réceptrice Banque qui a pour charge de recevoir les remises. Il s’agit
obligatoirement d’un participant direct.
Banque remettante Banque concernée par la remise, c’est à dire celle dont les
comptes seront impactés par les résultats de compensation.
BDD Base de données.
Bourrage Blocage d'un chèque/ lettre de change dans le scanner lors de sa

capture.
Capture Scannérisation de l'image recto et verso du chèque / lettre de

change et lecture de la ligne MICR.
CIP Centrale des incidents de paiements.

Statut Ebauche
Clé Chaîne de caractères qui représentent le paramètre d'entrée de
l'algorithme de cryptage.
Clé courante Clé valide servant à la signature ou à l’authentification des

images.
Clé nouvelle Clé générée dont la date de début de validité n’est pas encore
atteinte.
Clé privée Clé secrète de signature que seul l'expéditeur connaît.
Clé publique Clé d’authentification connue par tous les correspondants.
Clé triple DES Clé avec laquelle se fait le cryptage et le décryptage des fichiers
à l’aide de l’algorithme symétrique DES.
Collecte Récupération, par l’Autocollecte, des remises et des informations

contenues dans les boîtes aux lettres des participants.
Code opération Code valeur : Code retenu par le format d’échange du système
de compensation pour définir le type d’opération.
Code enregistrement C’est un code qui indique s’il s’agit d’une remise classique
d’opérations, d’une remise de rejet, d’une remise d’annulation
d’opérations ou d’une remise d’annulation de rejets.
Condensé Chaîne de caractères qui représentent le document haché.
Confrontation Opération de comparaison de deux chaînes de caractères.
Contrôle bloquant Contrôle qui en cas d’échec, engendre le blocage de l’opération

concernée.
Cryptage Procédé mathématique qui transforme un message d'origine en

une chaîne inexploitable de caractères apparemment aléatoire,
mais qui obéit en fait à des règles mathématiques précises.
Contrôle logique Il comprend tous les contrôles liés au contenu bancaire des
remises.
Contrôle syntaxique Il comprend tous les contrôles liés aux formats des remises:
Contrôle de la structure de l’enregistrement et contrôle de sa
complétude.
Contrôle réglementaire Il comprend tous les contrôles liés au respect des obligations
réglementaires par les opérations et dont certains font appel à
l’historique au niveau de la base de données.

Statut Ebauche
Date de règlement Date à laquelle une opération est portée sur les comptes de
règlement des banques concernées. Elle est exprimée sous la
forme J+n, où J représente le jour de présentation de la valeur
en compensation et n le délai de règlement.
Début des échanges Heure d’ouverture des échanges pour toutes les valeurs du
système.
Délai de règlement DDR - Nombre de jours ouvrés entre le jour de la présentation

d’une valeur en compensation et sa date de règlement.
Délai de rejet Nombre de jours ouvrés, depuis la date de remise en

compensation d’une valeur, pendant lesquels la contrepartie
peut rejeter l’opération.
Doubles Deux chèques/ lettres de change qui passent en même temps

dans le scanner.
Doublons Deux chèques / lettres de change ayant la même ligne MICR qui
passent dans le scanner.
Endossement Ecriture d'un texte sur l'endos de la valeur physique.
Enregistrement Ensemble des données à échanger d’une façon électronique

informatique suivant des structures normalisées.
Enregistrement détail Enregistrement contenant les informations détails des opérations

d’une remise.
Enregistrement global Enregistrement contenant les informations globales de toutes les

opérations d’une remise.
Envoi Dépôt, par l’Autocollecte, dans les boîtes aux lettres des
participants des remises et des informations qui leur sont
destinées.
Fichier image cumulé Fichier contenant un ensemble d’images générées depuis le

début d’une session jusqu’à un instant (t).
Fichier image Fichier contenant un ensemble d’images générées dans un

différentiel intervalle de temps donné.
Fichier image Fichier contenant une seule image.

élémentaire
Fichier image global Fichier contenant toutes les images générées pendant une
session.
Fichier zippé (triplet) Triplet de fichiers .CAT, .PAK et .ENV compressé et regroupé
dans un seul fichier.

Statut Ebauche
FIFO First in, first out. Premier arrivé, premier traité.
Fin des échanges Heure de fin des échanges pour toutes les valeurs du système.
Format JPEG Format standard de compression d’images.
FTP File Transfert Protocol : protocole de transfert de fichiers.
Hachage Fonction mathématique irréversible permettant de générer une

chaîne de caractères de taille fixe à partir d'un document de taille
variable.
HFJ Heure d’arrêté de la journée comptable.
HFE Heure d’arrêté de la journée d’échange.
Identifiant d’une Ensemble de données permettant d’identifier une opération d’une

opération manière unique.
Inter Interbancaire.
Intra Intra bancaire.
Identifiant d’une Ensemble de données permettant d’identifier une remise d’une

remise manière unique.
LDC Lettre de change
Limite débitrice multilatérale et/ou bilatérale

bilatérale
Correspond au solde débiteur maximal qu’un participant peut
atteindre par rapport à l’ensemble des participants ou vis-à-vis
d’un participant en particulier.
Messages non Messages échangés dans le système de compensation et n’ayant

financiers aucun impact financier sur les soldes des participants.
Les messages non financiers sont de deux types
1. Messages d’information systèmes relatifs à la
suspension ou à l’exclusion de participants ;
2. Messages libres. Echangés entre les participants.
Montant seuil d’envoi Montant au-dessous duquel les fichiers (.PAK et .CAT) ne sont
pas envoyés vers le siège de la banque.
Montant seuil Montant au delà duquel l’image doit être véhiculée avec les
interbancaire données.

Statut Ebauche
Participant aux Tout établissement bancaire qui délivre à sa clientèle ou reçoit
échanges d'elle des instruments de paiement scripturaux qu'il échange en
compensation. Il possède un compte courant dans les livres de la
Banque Centrale sur lequel sera imputée la somme algébrique de
ses soldes de compensation.
Participant direct Participant qui assume la responsabilité technique et financière

vis-à-vis de l’ensemble des participants au système d’échanges
des opérations transitant par son intermédiaire, que ce soit pour
son propre compte ou pour celui de l’ensemble des
établissements qu’il représente.
Participant indirect Participant connu du système de compensation, il détient un

compte de règlement mais utilise les infrastructures techniques
d’un participant direct pour ses échanges avec le centre de
compensation. Il a la pleine responsabilité financière de ses
échanges et de leur règlement.
Poste adhérent Installé au niveau de la plate forme participant direct, le module

poste adhérent représente le premier, et l’unique, point d’accès
au système de compensation. Tous les échanges entre le
système central et les participants se faisant via le poste
adhérent.
Piste MICR Police utilisée pour l’encodage des chèques et des lettres de
changes, conçue spécialement pour être lues par les scanners.
Plage d’échanges Intervalle temporel durant lequel les échanges peuvent avoir
lieu.
Plate forme participant Système informatique, permettant aux participants d’accéder au

système de compensation.
Port SSL C’est la porte d’entrée ou de sortie du protocole SSL.
Queuearch Table de communication au niveau de la base de données dans

laquelle sont inscrits les fichiers à archiver.
Queuein File d’attente dans laquelle sont insérés les fichiers qui vont être
traités par un applicatif.
Queueout File d’attente dans laquelle seront inscrits les outputs d’un
applicatif.
RTGS Système gros montants automatisé.
Réconciliation Confrontation de deux fichiers.

Statut Ebauche
Remise (ou lot) Fichier informatique contenant des opérations de même nature
présenté à une ou plusieurs banques.
Représentation d’une Deuxième présentation d’une remise après avoir fait l’objet
remise d’une annulation ou d’un rejet
RIB Relevé d'Identité Bancaire.
SI Système d’information.
Signature Cryptage d’un condensé par une clé privée.
STC Système des transactions par cartes
Sous-participant Institution « client » d’un participant direct ou indirect. Ses

opérations sont échangées et réglées dans le système via le
participant direct. Le sous participant passe des accords avec un
participant direct, voir un participant indirect qui lui assure les
échanges de ses opérations dans le système de compensation
ainsi que leur règlement.
SSL Secure Socket Layer - Protocole sécurisé d’échange point à

point.
Standard PKCS Protocole de cryptographie standard basé sur une clé publique.
Valeur compensable Moyen de paiement échangé dans le cadre du système de

compensation.
Valeurs interbancaires Valeurs dont les contreparties sont des banques différentes de la
banque remettante.
Valeurs intra Valeurs pour lesquelles le tireur et le bénéficiaire font partie de

bancaires la même banque
Vignette papier Support physique d’un chèque ou d’une lettre de change.
1.2 EXTENSION DES FICHIERS

.CIP : Fichier d’interface avec la centrale des incidents de paiements
.CPR : Fichier compte rendu de fin de journée.
.CRS : Fichier compte rendu de fin de session.
.DATA : Fichier de données généré par le module de capture.
.ECH : Fichier échéancier de règlement.

Statut Ebauche
.FCT : Fichier de facturation.
Fichier .CAT : Fichier catalogue (ou index) décrivant le fichier package.
Fichier .PAK : Fichier contenant les images chèques / lettres de change concaténées bout à
bout.
.MIS : Fichier contenant les messages d’information système.
.ENV : Fichier remise destiné au centre de compensation.
.RCP : Fichier remise reçu du centre de compensation.
.RJT : Fichier de remise de rejet réglementaire envoyé par le centre de compensation.
.SND : Situation nette définitive. Reprend, pour chaque valeur, les soldes bilatéraux
comprenant toutes les opérations de la journée et le solde net de la journée.
.SNF : Situation nette de fin de session. Reprend, pour chaque valeur, les soldes bilatéraux
comprenant toutes les opérations de la session et le solde net de la session.
.SNI : Situation nette intermédiaire. Intègre, pour chaque valeur, les situations nettes
calculées depuis le début de la journée jusqu’au moment de sa génération.
.SIG : Situation nette intermédiaire globale. Intègre, pour toutes les valeurs confondues, les
situations nettes calculées depuis le début de la journée jusqu’au moment de sa génération.
.SFG : Situation nette de fin de session globale. Reprend, pour toutes les valeurs confondues,
les soldes bilatéraux comprenant toutes les opérations de la session et le solde net global de la
session.
.SNG : Situation nette globale. Reprend, pour toutes les valeurs confondues, les soldes
bilatéraux comprenant toutes les opérations de la journée et le solde net global de la journée.
.SIV : Situation intermédiaire globale par valeur. Intègre, pour chaque type de valeur (les
présentations et les représentations confondues), les situations nettes calculées depuis le
début de la journée jusqu’au moment de sa génération.
.SFV : Situation de fin de session globale par valeur. Reprend, pour chaque type de valeur (les
présentations et les représentations confondues), les soldes bilatéraux comprenant toutes les
opérations de la session et le solde net de la session.
.SDV : Situation définitive globale par valeur. Reprend, pour chaque type de valeur (les
présentations et les représentations confondues), les soldes bilatéraux comprenant toutes les
opérations de la journée et le solde net de la journée.
.STC : Fichier d’interface avec le centre de traitement monétique.

Statut Ebauche
.STG : Fichier des statistiques des rejets réglementaires.
.STI : Fichier des statistiques des institutions.
.STJ : Fichier des statistiques de la journée.
.STR : Fichier des statistiques des rejets.

Statut Ebauche
2 PRESENTATION DU PROJECT
2.1 CONTEXTE DU PROJECT
Dans le cadre du passage à une monnaie unique des pays de la Zone Monétaire de l’Afrique de
l’Ouest, un Project de développement des systèmes de paiement à été lancé début 2009 par
l’Institut Monétaire de l’Afrique de l’Ouest.
L’une des composantes de ce projet concerne l’implémentation d’un système automatisé de

traitement des chèques (ACP) et un système automatisé de compensation (ACH) pour traiter
des transactions de paiement à gros volume et petits montants et ce dans trois pays de la
ZMAO : la Gambie, la Guinée Conakry et le Sierra Leone.
Le système ACP sera utilisé pour le traitement des images des valeurs papier (principalement
les chèques).
Le système ACH assurera la compensation des données de toutes les valeurs (données chèque
reçues du système ACP system, virements, prélèvements, etc.).
Les résultats des transactions seront réglés dans le système de règlement brut en temps réel
(RTGS).
En février 2010, BFI a été choisie pour l’implémentation de ce nouveau système.
2.2 OBJECTIFS DU PROJET
La « chambre de compensation automatisée » (ACH) permettra un traitement efficace et à

faible coût des moyens de paiements. Ce système permettra l’échange électronique des
virements et des prélèvements pour des particuliers ou des sociétés.
Le module ACH sera utilisé pour les paiements récurrents tels que les salaires, les primes
d’assurance et les dépenses courantes.
Les fichiers en entrée de l’ACH seront émis directement par les banques avec un format
prédéfini, permettant ainsi un taux d’acceptation élevé et le règlement de la plupart des
instructions de paiement sans intervention humaine.

Statut Ebauche
Un système ACP sera également implémenté afin de permettre la dématérialisation des images
chèques et assurer leur traitement et leur authenticité à chaque étape du traitement. Le
système ACP permettra également la soumission des données des valeurs chèque au module
ACH.
Le système ACP permettra d’atteindre les objectifs suivants :
• Réduire les délais de compensation des chèques avec la possibilité de compenser les
chèques à J indépendamment de leur lieu de présentation dans le pays,
• Eviter les échanges physiques de chèques de la banque présentatrice à la banque tirée

pour validation et vérification,
• Garder une seule chambre de compensation électronique pour chaque pays, la chambre
de compensation manuelle sera fermée après le démarrage du système,
• Augmenter la confiance dans le système bancaire: Modernisation des lois et des règles
afin d’assurer les droits et les devoirs de tous les participants et usagers du système.
• Faciliter l’accès aux nouveaux entrants (micro-finances, banques de dépôt) avec la
standardisation, et amélioration des méthodes de travail entre les participants
existants,
• Diminution de l’utilisation de la monnaie fiduciaire dans le commerce et renforcer la
confiance dans les transactions bancaires. Le public ayant une forte habitude
d’utilisation de la monnaie fiduciaire pour diverses raisons, le nouveaux système
contribuera à la réduction du risqué lié à cette monnaie,
• Augmenter le taux de bancarisation en vue de permettre à un plus grand nombre de
personnes, notamment dans les zones rurales et dans les petites entreprises, d’accéder
aux services bancaires d’une manière juste et équitable,
• Développer de nouveaux moyens de paiement qui comblent les besoins et les intérêts
des usagers et qui utilisent des technologies sures et éprouvées.
2.3 INTERVENANTS DU PROJET
 Banques Centrales des trois pays : propriétaires et gestionnaires du système.
 WAMI : acquéreur du système et garant de la bonne implémentation du système
 Institutions participantes :
 Banques Commerciales
 Banques Centrales
 La Poste, le Trésor Public

Statut Ebauche
 Autres instituions financières
 BFI : Fournisseur et intégrateur du système.
 Logica : assiste la WAMI et les Banques Centrales dans toutes les phases du projet
2.4 COMITÉS DE PILOTAGES

2.4.1 Comité de suivi des pré-requis
 Mission
Comité de suivi des pré-requis examine le progrès en terme d’exécution des pré requis
(Systèmes informatiques, aspects organisationnels, réseau…) nécessaires à la mise en
place de tout le système.
 Organisation
Le comité inclut :
- Représentants de l’IMAO,
- Représentants des banques centrales,
- Représentants des participants,
- Représentants de BFI,
- Représentants de Logica.
Cette réunion de comité sera programmée par l’IMAO.
Le lieu de la réunion est choisi par l’IMAO (dans les locaux de l’IMAO ou dans l’un des 3 pays).
Des sessions extraordinaires peuvent être initiées à chaque fois que nécessaires.
2.4.2 Equipe Projet au sein de la Banque Centrale

Une équipe projet devra être mise en place au sein de chaque Banque Centrale des trois
pays (Gambie, Guinée et Sierra Leone).
 Mission
Sous la responsabilité du chef de projet, cette équipe se charge de la mise en œuvre
conjointement avec l’équipe BFI. A ce titre elle se charge de :
 Organiser et planifier les groupes de travail ;

 Gérer la relation entre les intervenants internes (informaticiens, utilisateurs) avec les
responsables de projets des fournisseurs externes et notamment BFI;
 Superviser la mise en œuvre des pré-requis sur le plan national;
 Gérer les problèmes (propositions de solutions aux problèmes) ;

Statut Ebauche
 Suivi des tests et recette de la solution ;
 Pré-valider les livrables qui seront soumis au Comité de Projet ;
 Participer aux réunions d’avancement de projet avec BFI pour le suivi et le traitement
des problèmes courants ;
 Planifier et suivre la réalisation de la formation au bon moment ;
 Superviser l’actualisation des méthodes, normes et procédures ;
 Mettre en place l’assistance aux utilisateurs lors des phases de déploiement.
 Organisation
Cette équipe comprend :
 Membres permanents :
Le chef de projet de la Banque Centrale;
Des informaticiens ;
Des organisateurs ;
Des utilisateurs (futurs formateurs) responsables pour les modules de la solution ;
 Membres ponctuels :
Un responsable de l’inspection et de l’audit ;
Un responsable des ressources humaines.
Toute autre personne nécessaire.
2.5 PRÉSENTATION DU PROJET
La compensation reposera uniquement sur des échanges électroniques entre les participants et
le Centre de Compensation. Chaque opération client sera dématérialisée par la banque
remettante et fera l’objet d’un enregistrement normalisé contenant toutes les informations qui
permettront le contrôle et la comptabilisation de cette opération. Il n’y aura plus nécessité de
déplacement physique des agents des banques à la chambre de compensation,
Le participant remettant aura également la charge de procéder à une scannérisation des

vignettes chèque et effet de commerce (image numérisée recto/verso) et de transmettre cette
numérisation au Centre de Compensation avec l’enregistrement correspondant.
Le Centre Compensation traitera sans distinction des opérations déclarées, sur place, hors
place et déplacées. Toutes les opérations seront dénouées dans les mêmes délais. Le centre de

Statut Ebauche
compensation contrôle les remises des banques remettantes, effectue la préparation des
remises destinataires et calcule, en continu, les positions des participants. Les soldes
multilatéraux sont transmis pour règlement une fois par jour (après la fin de la journée de
traitements) au système de règlement brut en temps réel (RTGS). Le règlement s’effectuera
donc pour chaque participant sur son unique compte de règlement.
Le centre de compensation envoie en continu le même jour les remises retours aux
participants destinataires. Le centre de compensation émet également vers les participants des
comptes rendus de traitement de leurs remises ainsi que des situations nettes (soldes
bilatéraux, multilatéraux).
A la réception des remises retour, les banques destinataires ont la possibilité d’effectuer les
vérifications d’usage (signature, endos) sur la base de la visualisation des images de chèque
(ou effet de commerce) et de rejeter les opérations. Quatre motifs de rejets peuvent saisis par
l’utilisateur pour chaque opération reçue.
Les rejets seront retournés par la banque destinataire au centre de compensation pendant la
période de rejet autorisée. La non réception de rejet à la fin de la période de rejet signifie que
la valeur a été définitivement acceptée et payée
Le Centre de compensation archive les images numérisées et les données pendant une durée
prédéfinie. L’accès aux données archivées par les participants sera effectué via un serveur web
central dédié à cet effet.

Statut Ebauche
3 DESCRIPTION FONCTIONNELLE DU SYSTÈME ACP/ACH
3.1 ASPECTS GÉNÉRAUX
3.1.1 Codes pays et devises
Code Abréviation du Libellé devise Code devise

Pays
pays
LA GAMBIE 01 GM Dalasi (GMD) 270
SIERRA LEONE 05 SL Leone (SLL) 694
GUINEE CONAKRY 03 GN Franc Guinéen (GNF) 324
LIBERIA 06 LR Liberian Dollar 430
3.1.2 Participants
Les participants au système de compensation peuvent intervenir selon des statuts différents :
 Le participant direct : possède un compte de règlement après de la banque centrale

ainsi qu’une plateforme technique pour les échanges avec la banque centrale. Le
participant direct Assume la responsabilité technique et financière vis-à-vis de
l’ensemble des participants au système ACH des opérations transitant par son
intermédiaire, que ce soit pour son propre compte ou pour celui de ses sous
participants;
 Le participant indirect : Est connu du système de compensation, il détient un compte
de règlement mais utilise les infrastructures techniques d’un participant direct pour ses
échanges avec le centre de compensation. Il a la pleine responsabilité financière de ses
échanges et de leur règlement;
 Le sous participant : c’est le « client » d’un participant direct ou indirect. Il ne
possède pas de compte de règlement auprès de la banque centrale et ses opérations
sont échangées et réglées dans le système via un participant direct ou indirect avec
lequel il conclut un accord. C’est ce dernier qui assume les responsabilités financières
du sous-participant vis-à-vis du système et des autres participants.

Statut Ebauche
3.1.3 Moyens de paiement
Les moyens de paiements acceptés dans le système ACP/ACH sont :

Valeurs financières :
- 10- Virement *.
- 12- Virement en provenance de l’Etranger.
- 13- Virement représenté*.
- 20- Prélèvement **.
- 23- Prélèvement représenté*.
- 30- Chèque.
- 33- Chèque représenté*.
- 40- Lettre de change.
- 43- Lettre de change représentée*.
- 50- Opération carte.
- 53- Opération carte représentée*.
Valeurs non financières :

- 61- Message Libre.
- 62- Avis de non paiement
- 83-Avis de Reconstitution de Provision.
(*) Définition du virement:
Le moyen de paiement Virement est un transfert de fonds entre deux contreparties permettant au
remettant (le payeur) de présenter une transaction à la banque destinataire au crédit du compte du client
destinataire (bénéficiaire) par le montant de la transaction.
(**)Définition du prélèvement:
Le prélèvement automatique est un instrument de paiement permettant au remettant (le bénéficiaire) de

présenter une transaction à la banque destinataire pour débiter le compte du client destinataire (le
payeur) par le montant de la transaction.
Pour autoriser une opération de prélèvement entre deux contreparties, un contrat doit être signé entre le
bénéficiaire et le payeur et dans lequel ce dernier autorise le bénéficiaire de retirer un montant spécifique
de son compte à une date précise ou une fréquence spécifique.

Statut Ebauche
(*)Définition de la représentation:
La représentation ne peut être effectuée que si l’opération initialement présentée a été rejetée par le
destinataire par une opération de rejet. La représentation est effectuée par le remettant de la première
présentation.
Exemple :
1. La banque 001 présente un chèque (avec code valeur 30) à destination de la banque 002 ;
2. En recevant le chèque (avec code valeur 30), la banque 002 le rejette pour manque de
provision ;
3. Quand la provision est reconstituée au niveau de la banque 002, la banque 001 peut représenter
le chèque (avec code valeur 33) pour paiement.

Statut Ebauche
3.1.4 Codes enregistrement/remises
Les types de remises (code enregistrement) qu'un participant peut présenter sont :
3.1.4.1 Première présentation de remises (code enregistrement 21)
- Les fichiers de données contiennent la totalité des opérations que présente un

participant, par type de moyen de paiement (code valeur) et par code enregistrement ;
- Aucune limitation n’existe quant au nombre de remises d’un même type présentées par
un participant pendant une session de compensation.
3.1.4.2 Remises de rejets (code enregistrement 22)
- Les rejets doivent faire l’objet de remises distinctes ;

- Le rejet d’opérations par une banque destinataire peut avoir lieu soit pour un motif
bancaire, soit pour un motif technique :
o Le motif technique est celui qui empêche la banque destinataire de déterminer le
montant à imputer ou le compte auquel elle doit l’imputer ou de vérifier la
validité de l’opération (absence de données faciales) ;
o Le motif bancaire est celui qui empêche la banque de procéder à un dénouement
complet de l’opération (solde insuffisant, signature non autorisée, compte fermé
ou bloqué …).
- Le rejet d’une opération reçue de la compensation doit être transmis au système durant
le délai de rejet défini pour le code valeur en question, le délai de rejet étant calculé à
partir de la date de présentation appliquée à la valeur ;
- Le rejet d’une opération reçue de la compensation doit être transmis au système à

partir du délai de début de rejet défini pour le code valeur en question ; les rejets
parvenues en dehors de ce délai seront rejetées par le système (rejet réglementaire) ;
- Les rejets doivent obligatoirement contenir les références des opérations initiales.
3.1.4.3 Remises d’annulations d’opérations (code enregistrement 23 et

24)
- Les annulations doivent faire l’objet de remises distinctes triées de la même manière
que les présentations initiales ou les rejets ;
- Les remises d’annulations peuvent comprendre une ou plusieurs opérations d’une
remise déjà présentée au système (remise de présentation, de rejet ou de
représentation) ;

Statut Ebauche
- Les opérations figurant dans une remise d’annulation doivent être transmises au
système pendant le délai d’annulation paramétré de la valeur. Les opérations à annuler
parvenues en dehors de cet intervalle seront rejetées par le système (rejet
réglementaire).
3.1.5 Codes Centre de compensation

- Opérations intrabancaires : Code 00 : opérations dont le bénéficiaire et le payeur
appartiennent à la même banque (du même pays). Les opérations entre un participant
direct et son sous-participant sont aussi considérées comme des opérations
intrabancaires.
- Opérations interbancaires nationales : Code 01 : opérations dont le bénéficiaire et le

payeur appartiennent à deux banques différentes d’un même pays.
- Opérations interbancaires régionales : Code 02 : opérations dont le bénéficiaire et le

payeur appartiennent à deux banques différentes de deux pays différents.
NB: les banques appartenant à un même groupe et opérant dans deux pays différents sont
considérées comme deux banques différentes.
3.1.6 Propriétés des valeurs

Code Libellé valeur
Délai Délai Délai Délai Délai
Valeur
Règlement Rejet Début Echéance Annulation
rejet
10- Virement.
Jà
12- Virement Etranger. J J - J
J+1
13- Virement représenté.
20- Prélèvement. Jà
J J J J
23- Prélèvement représenté. J+1
30- Chèque Jà
J J - J
33- Chèque représenté J+1
40- Effet Jà
J J J J
43- Effet représenté J+1
50- Opération carte

Jà
53- Opération carte J J - J
J+1
représentée
61- 62- Message libre. - - - - -

83- Avis de non paiement.

Statut Ebauche
Avis de reconstitution de
provision.
J = jour de présentation en compensation

Statut Ebauche
3.1.7 Profil de journée
Ce schéma est un exemple de profil de journée de compensation. Tous les horaires sont des
paramètres qui peuvent être changés si nécessaire :
Traitements
Situations
ACP/ACH
Compensation Jour J nettes
définitives
Contrôles et Règlement
générations ACH Génération des lots et des ACH Fin
des soldes
Début situations intermédiaires selon Journée
mulitlatéraux
journée fréquence de génération
collecte
Collecte et envoi
envoi
ACP participant Dépôt des remises allant en

compensation
Dépôts et
réceptions Réception des remises de la compensation
Début Contrôle et génération des

Pré-compensation journée remises allant en compens
Contrôles et Siège
générations Contrôle et tri des remises reçues
collecte
Collecte et envoi
envoi
Début Fin
journée journée
agence agence
ACP Agence Scannérisation et saisie de données

J-1 16H30
J-1 16H45
J 16H30
J 17H00
J 08H30
J 08H45
J 09H00
J 14H00
J 14H30
J 15H00
J 15H30
J 13H30
3.1.7.1 Au niveau de l’agence remettante
Dès la réception du nouveau fichier “DATE” (au maximum à 16H30 de J-1), l’agence peut
procéder à l’ouverture de la nouvelle journée (J). Toutes les transactions qui seront traitées

Statut Ebauche
vont être gardées en agence et ne seront collectés qu’à l’ouverture de la prochaine session de
collecte (08h30 de J).
Les opérations à envoyer en compensation doivent être traitées en agence avant la fon de la
session de collecte (14H00 de J)
L’agence va commencer à recevoir les lots intra bancaires et interbancaires à partir du siège
depuis le début de la session d’envoi (09H00 de J) et jusqu'à la fin de la session d’envoi
(16h30 de J).
3.1.7.2 Au niveau du siège du participant
Collecte des fichiers : Durant la période de collecte du siège (08H30 à 14H00 de J), le siège va
collecter tous les fichiers crées au niveau des agences afin de les contrôler et de les intégrer
dans les remises à envoyer en compensation. Les fichiers en provenance du CBS seront aussi
traités pendant la même période.
La dernière remise sera générée par le siège à l’heure fin de génération (14H15).
Le dépôt des remises pour la compensation peut être effectué durant la période de dépôt
(08H30 à 14H30 de J) : toute remise déposée sera contrôlée, cryptée, compressé et placée
dans le répertoire d’envoi du siège
Réception des fichiers : la réception des fichiers reçus de la compensation au niveau du siège
va se faire dés l’arrivée de l’horaire de début d’envoi du centre de compensation (09H00 de J)
jusqu'à l’horaire de fin d’envoi (16H00 de J). Ces fichiers sont contrôlés et triés par agence
puis envoyées vers les agences destinataire pour paiement (ou rejet).
Envoi des fichiers : l’envoi peut être effectué durant la période d’envoi du siège (09H00 à
16H30 de J) et concerne les fichiers triés a envoyer aux agences destianataires.
3.1.7.3 Au niveau du centre de compensation : Réception des lots,

Traitement et génération des remises retour
Collecte des fichiers : Durant la période de collecte du Centre de compensation (08H30 à

14H45 de J), ce dernier va collecter toutes les remises générées par les banques remettantes
afin de les contrôler et de les intégrer dans les traitements de compensation. Les fichiers
rejetés seront immédiatement retournés aux participants remettants.
Génération des remises retour : pendant la période de génération (08H30 à 15H00 de J), Le
centre de compensation va envoyer continuellement les remises retours ainsi que les situations
nettes intermédiaires aux différents participants destinataires.

Statut Ebauche
A la fin de la journée de compensation (15H30 de J): Le centre de compensation génère les
fichiers aux participants destinataires:
- Les situations nettes définitives, qui tiennent compte pour chaque participant des
valeurs présentées, des valeurs annulées et des valeurs rejetées lors de la journée de
compensation.
- Les comptes rendus de traitements,
- Les remises RCP et RJT non encore générées.
L’envoi des fichiers aux participants destinataires va durer jusqu'à la fin de la période d’envoi
(16H00 de J).
Les soldes définitifs de compensation des différents participants sont communiqués au

système RTGS pour règlement sous forme d’un message SWIFT (MT971).

Statut Ebauche
3.2 ARCHITECTURE ET SCHÉMA DES FLUX
3.2.1 Sens aller Compensation
Barberousse - Capture
Agence remettante
- Capture des images, recto et verso du
Générateur des clés

document
Barberousse -
Scanner - Lecture des pistes MICR
Chèques et Effets - Signature des images
LS515
- Saisie des données relatives aux documents (

montant, date...)
- Validation des données
- Génération des fichiers catalogue (index) et
Fichiers CBA package
de l'agence - Génération des fichiers données relatifs aux
documents scannés
Fichiers images (.CAT/ .PAK) et fichiers de

données
Banque remettante Hannibal - Autocollecte
Collecte des remises numériques et des

fichiers images
Hannibal - ADT
- Contrôle des structures des fichiers index et

images et données

- Authentification des images
Barberousse -
- Confrontation des fichiers CAT/ PAK
- Réconciliation des données et images
Fichiers CBA de la banque - Contrôle des fichiers reçus du CBA de la
banque
- Génération des remises interbancaires
destinées à la Télécompensation
- Génération des remises intrabancaires
destinées aux agences
- Calcul des situations nettes prévisionnelles
Remises numériques et fichiers d'images
Hannibal - Poste Adhérent

- Authetification des images
- Contrôle de la conformité des fichiers images
et index
- Contrôles syntaxiques et logiques des
remises numériques
- Réconciliation des remises numériques et les
fichiers images correspondants
- Dépôt et cryptage des fichiers destinés à la
Télécompensation
- Affichage des erreurs et rejet des remises
erronées
BAL : Remises numériques et fichiers

d'images contrôlés et triés par centre de
compensation, par devise et par type de
valeur
Centre de
compensation Hannibal - Autocollecte
Collecte des fichiers images et données cryptés

Statut Ebauche
3.2.2 Sens retour Compensation
Hannibal - Compensation Service Bureau
Hannibal-Poste de Secours
- Authetification et resignature des images - Authentification des images
- Vérification de la conformité des fichiers images et - Contrôles syntaxiques et logiques des fichiers
index de données
- Contrôles syntaxiques et logiques des fichiers de - Dépôt des fichiers images et données
données - Récupération des fichiers reçus
- Contrôles réglementaires - Édition des opérations reçues et des résultats
- Réconciliation entre images et données de la compensation
Hannibal-
- Génération des alertes et rejet des remises ou blocage ---------------------------------------------------
Serveur Barberousse-Présentation
des opérations erronées
WEB - Chargement des fichiers de données relatifs
- Calcul des situations nettes intermediaires et finales
- Établissement des échéanciers de règlement aux images scannées
- Consultation des données et - Génération des lots vers les banques destinataires - Saisie des opérations
images archivées - Génération des fichiers d’interface vers RTGS, Système - Chargement des fichiers reçus
- Administration des habilitations Monétique... - Rejet des opérations
(Profils des utilisateurs) ---------------------------------------------------
-Édition des états et sauvegarde Barberousse-Capture
Fichiers retour compensation

( fichiers de données, fichiers d'images,
comptes rendus...)
Hannibal - Autocollecte
Envoi des fichiers retour compensation

( fichiers de données, fichiers d'images, comptes rendus,
situations nettes...)
Banque destinataire
Hannibal - Poste Adhérent
- Consultation des lots reçus

- Récupération des remises numériques et des
fichiers images
- Edition des résultats de la compensation
Barberousse -
Hannibal - ADT
- Contrôle des fichiers images et données

Accès à reçus
Hannibal- - Tri des fichiers images et données par agence
Serveur Web destinataire
- Calcul des situations nettes
- Confrontation des situations nettes
- Edition des résultats de la compensation
Hannibal - Autocollecte
Envoi des fichiers données et images
Agence destinataire
Barberousse – GIP Vice de

Forme
Barberousse -
- Consultation des images reçues + Authentification

- Consultation des données
- Interfaçage avec le système de vérification des signatures
- Traitement et Génération des rejets
- Consultation en Ligne des opérations archivées par accès à
Hannibal-Serveur Web
- Edition des états

Statut Ebauche
3.3 DESCRIPTION FONCTIONNELLE DE LA SOLUTION
La plateforme Participant est composée des modules suivants :
Modules agences :
 Barberousse-Capture permet la scannérisation sécurisée des images des valeurs

physiques (chèques et effets de commerce).
 Barberousse-Générateur Clés : assure la sécurisation des images et données durant

leur circuit de traitement.
 Barberousse–GIP : permet la visualisation des images et données des valeurs

interbancaires et intrabancaires reçues durant la journée afin de permettre à la banque
destinataire d’effectuer les rejets éventuels.
Ces modules sont installés en agence, Toutefois ils peuvent être installés au siège en tant
qu’installation centralisée.
Modules siège :
 Hannibal-ADT : assure la préparation des remises à envoyer en compensation ainsi

que le traitement des remises reçues de la compensation.
 Hannibal-Autocollecte : assure le transfert sécurisé des fichiers, images et données,

depuis les agences vers le siège et inversement.
 Hannibal -Poste Adhérent : permet le dépôt des remises en compensation ainsi que
la réception de remises envoyées par le centre de compensation.
 Hannibal Générateur des Clés : assure la sécurisation des images et données durant
leur circuit de traitement.
3.3.1 Description fonctionnelle du module Barberousse Capture
3.3.1.1 Présentation
Le logiciel Barberousse -Capture permet la scannérisation des images des valeurs physiques
(chèques et effets de commerce). Il peut être installé aux agences de la banque ou bien au
siège.
Les fonctionnalités essentielles de Barberousse-Capture sont :
- La scannérisation des valeurs physiques des deux cotés.

Statut Ebauche
- Lecture de la ligne MICR et impression d’un endos paramétrable sur l’envers du chèque.
- Chargement manuel des données.
- Génération et sauvegarde des fichiers image contenant les deux faces de l’image
concaténés (Fichier PAK) ainsi que le fichier index contenant l’information qui concerne
l’image (Fichier CAT)
- Signature électronique des images.
Génération de fichiers DATA contenant l’information sur les valeurs scannées.
3.3.1.2 Fonctionnalités
3.3.1.2.1 Gestion des droits et des accès
L’accès à l’application est sécurisé et différents niveaux d’autorisations peuvent être accordés
aux différents groupes/utilisateurs de l’application
3.3.1.2.1.1 Gestion des groupes, des utilisateurs et des droits d’accès
L’administrateur système peut créer, modifier ou supprimer les utilisateurs grâce à un masque
spécifique.
Chaque utilisateur doit être attribué à un groupe, à une banque et à une agence.
Par défaut, les nouveaux utilisateurs sont affectés à la banque et agence d’installation
Les autorisations peuvent être attribuées par groupe ou par utilisateurs à travers un masque
spécifique. Un utilisateur hérite ainsi automatiquement les autorisations du groupe.
3.3.1.2.1.2 Gestion des Mots de passe
Chaque utilisateur possède un mot de passe valide pour une période définie par le système.
Deux niveaux de sécurité des mots de passe sont offerts par l’application :
- Un niveau de sécurité standard : permettant à l’utilisateur de définir le mot de passe de

don choix.
- Un niveau de sécurité renforcé : certaines règles doivent être respectées dans la

définition des mots de passe.
Chaque participant peut choisir le niveau de sécurité qu’il veut appliquer au niveau de ses
agences
3.3.1.2.2 Initialisation de la journée

Statut Ebauche
L’opération d’initialisation de la journée de capture est effectuée au moment de la connexion
pour une nouvelle journée de capture.
L’initialisation de la journée comprend les opérations suivantes :
- La consommation de la date de capture ;

- La vérification des clés de signature et la consommation éventuelle d’une nouvelle clé;
- La consommation du référentiel participant ;
- Purge de la Boîte aux lettres.
3.3.1.2.2.1 Consommation de la date capture
Selon le paramétrage, la consommation de la nouvelle date de session peut se faire à travers

la consommation automatique ou bien la saisie manuelle.
3.3.1.2.2.2 Vérification de la clé de signature
Cette opération consiste à vérifier l’existence au niveau de la base du générateur (détenue par
B-Générateur Clés) si une nouvelle clé est reçue du siège. Si une nouvelle clé est reçue, le
module de scannérisation la charge pour la nouvelle journée.
L’absence d’une clé valide à l’initialisation de la journée entraîne le blocage de l’application.
3.3.1.2.2.3 Consommation du référentiel participant
Le référentiel comprend les informations de gestion sur :
- les participants : code participant, codes agences, mode de participation et état.
- Le calendrier des jours fériés,
- Les devises : statuts et codes devise.
- Les valeurs financières : statuts et codes valeur.
3.3.1.2.3 Traitements de Scannérisation
La scannérisation des valeurs à image peut se faire en deux modes :
- Mode remise: Une remise est un ensemble de valeurs présentées par un même
bénéficiaire;
- Mode lot : Un lot est un ensemble de valeurs présentées par des bénéficiaires
différents;
3.3.1.2.3.1 Saisie des données globales

Statut Ebauche
En cas de scannérisation par remise, les données globales relatives à celle-ci doivent être
saisies par type de valeur :
- L’identifiant de la remise : l’identifiant de la remise peut être soit saisi soit généré
automatiquement, selon un numéro séquentiel;
- Le RIB du bénéficiaire : le RIB peut être soit saisi soit sélectionné à partir d’une liste
déroulante ;
- Le nom bénéficiaire : peut être soit saisi soit sélectionné à partir d’une liste déroulante;
- Le montant global de la remise ;
- Le nombre global de valeurs ;
- Le code valeur ;
- Le code devise ;
- Des informations complémentaires concernant la remise.
Il est à noter que lors de la saisie du RIB du bénéficiaire, ce dernier fera l’objet des contrôles
suivants :
- Si le contrôle d’existence du compte est activé, le RIB bénéficiaire saisi est

contrôlé par rapport aux RIB existants au niveau de la base de données de
l’application.
- Si le contrôle d’existence du compte n’est pas activé, les différents champs du

numéro de compte sont contrôlés : le code banque, code agence, clé RIB.
3.3.1.2.3.2 Choix des options de scannérisation
Les valeurs des options de scannérisation sont prédéfinies par défaut pour chaque type de
valeur. Toutefois, au début de chaque opération de scannérisation, l’opérateur a la possibilité
de les changer :
Options chèque/lettre de change :

- Le mode de correction de la ligne MICR: au cours ou à la fin de scannérisation ;
- Le mode de saisie de la date d’émission et Le mode de saisie du montant : au cours
ou à la fin de la scannérisation ;
- Mode saisie des informations complémentaires : au cours ou à la fin de

scannérisation.
- Le code valeur : deux types de valeurs peuvent être scannés : les chèques/effets
présentés (code valeur 30/40) et les chèques/effets représentés (code valeur
33/43) ;
- La nature de l’endossement, le contenu.

Statut Ebauche
3.3.1.2.4 Scannérisation des valeurs
La scannérisation permet la capture de l’image du recto et du verso de la valeur chèque ou

lettre de change ainsi que la lecture de la ligne MICR.
3.3.1.2.4.1 Lecture des Lignes MICR
La lecture de la ligne MICR d’un chèque permet de lire la piste depuis le scanner et de vérifier
son état (correct ou défectueux).
Lors de la lecture de la ligne MICR les contrôles suivants sont effectués :

o Contrôle appartenance au référentiel : le code banque, code agence doivent
appartenir aux référentiel des codes banque et agences de l’application,
o Contrôle clé RIB : vérifie que le RIB calculé par l’application est égal à celui
indiqué dans la ligne MICR,
o Le code devise dans la ligne MICR doit correspondre à une devise active.
o Le code devise dans la ligne MICR doit correspondre au code devise de la
remise.
o Contrôle clé MICR : Vérifie que la clé MICR calculée par l’application est égale à
celle indiquée dans la ligne MICR,
3.3.1.2.4.2 Correction de la ligne MICR
La lecture de la ligne MICR peut révéler une piste défectueuse. Selon le choix adopté par
l’utilisateur à l’initialisation des options de scannérisation, deux possibilités lui sont offertes:
- Correction au cours de la scannérisation ;
- Correction au cours de la scannérisation ;
Remarque : Lorsqu’une ligne MICR est corrigée, la clé RIB et la clé MICR sont revérifiées.
3.3.1.2.4.3 Détection des doublons
Durant la scannérisation, le système procède à l’opération de détection des doublons sur une
période paramétrable. Toute valeur en double est rejetée automatiquement.
La fonction de détection des doublons est également déclenchée lorsque l’opérateur corrige
manuellement les lignes MICR.
3.3.1.2.4.4 Traitement et compression des images

Statut Ebauche
Le traitement et la compression des images sont une fonction qui s'exécute directement après
l’opération de lecture du recto et du verso de la valeur depuis le scanner. le traitement des
images se fait comme suit :
- Scannérisation de l’image avec le scanner en 100 dpi, en 256 gris et couleur RGB.
- La conversion de l’image du format Bitmap vers le format JPEG
- Compression de l’image à 76% (sans dégradation remarquable de la qualité)
La taille de l’image générée est environ 30 Kb pour les chèques (recto et verso) et environ 45
Kb pour les lettres de changes (recto et verso).
3.3.1.2.4.5 Signature des images scannées
La signature utilise l’algorithme asymétrique standard. Les inputs sont les deux côtés des
images ainsi que les informations sur la valeur. L’output de cette fonction est une image et
signée.
La signature des images est effectuée à travers la clé privée du siège consommée durant
l’initialisation de la journée.
3.3.1.2.4.6 Impression d’un endossement variable
Pendant la scannérisation, l’application va automatiquement imprimer un endos au verso du

chèque/effet scanné. Le contenu de l’endos et sa position sont paramétrables ( première
position ou deuxième position. Un endos spécifique est aussi prévu pour les MICR corrigées ou
saisies manuellement
3.3.1.2.4.7 Stockage des données
Les images signées sont stockées dans un répertoire temporaire alors que les données
correspondantes sont stockées dans la base de données. Une image est identifiée par sa ligne
MICR.
Le code participant remettant et le code agence remettante sont associés à l’utilisateur
connecté à l’application.
3.3.1.2.4.8 Visualisation des images
Cette fonction permet à l'utilisateur :

 de consulter les images chèques et effets et de faire des manipulations sur
l’image (zoom, rotation et inversion du recto et verso).
 Vérifier et éventuellement modifier des données.
Statut Ebauche
 Supprimer des données.
 Continuer la scannérisation ;
 Pré-valider et/ou valider la remise (selon les paramètres de validation).
3.3.1.2.5 Saisie des données
En plus des informations détectées de la ligne MICR, des informations additionnelles doivent
être saisies pour chaque code valeur. Selon les paramètres de l’application, ces données
peuvent être manuellement déposés ou bien chargés d’un fichier en provenance du CBA.
3.3.1.2.5.1 Saisie de données
3.3.1.2.5.1.1 Saisie de données chèques
Plusieurs informations obligatoires doivent être saisies pour compléter les informations sur la
valeur :
- Saisie des montants : L’utilisateur peut lire le montant de l’image affichée et le saisir
manuellement. Le montant unitaire de la valeur ne doit pas dépasser la limite autorisée.
- Saisie de la date d’émission : Obligatoire si l’option date d’émission est cochée)
- Choix nature du chèque : En cas de non lecture automatique de la nature du chèque par
le scanner, l’utilisateur doit choisir l’une des deux valeurs suivante :
 0 : chèque personnel
 1 : chèque de banque
 2 : Chèque entreprise
- Le nom Tireur (obligatoire ou non, selon les contrôles de l’ACH)
3.3.1.2.5.1.2 Saisie de données lettre de change
Plusieurs informations obligatoires doivent être saisies pour compléter les informations sur la
valeur. Les données à saisir sont les suivantes :
- Le nombre : ce champ doit être renseigné si l’information correspondante n’est

pas lue automatiquement de la ligne MICR.

Statut Ebauche
- Le montant des opérations : L’utilisateur peut lire le montant de l’image
affichée et le saisir manuellement. Le montant unitaire de la valeur ne doit pas
dépasser la limite autorisée. Sinon sa saisie ne sera pas acceptée.
- Le RIB du tiré ;
- Le nom du payeur (obligatoire ou non, selon les contrôles de l’ACH);
- Le lieu de création ;
- la date échéance ;
- Etc…
Avant la validation, l’application génère les fichiers images individuels (CAT/PAK) contenant les
images recto et verso de chaque chèque.
3.3.1.2.5.2 Import de données
Dans le cas où l’option d’import des montants est activée, l’opérateur procède à l’import des
montants à partir du fichier des données agence, le lien étant la ligne MICR des chèques.
A l’import, l’application remplace les informations manuellement saisies.
3.3.1.2.6 Validation des remises
Une fois toutes les valeurs d’une remise saisies, l’opérateur doit valider/pré-valider la remise
(suivant les paramètres de la validation) afin de procéder au traitement de la remise. Si la
remise n’est pas validée elle restera comme remise « prévalidée ».
La validation va lancer le rapprochement entre le nombre total des valeurs de la remise et le

montant total, avec le nombre et montant saisies unitairement.
- Si le rapprochement est effectué avec succès, la remise est automatiquement cochée et

aura le statut « validée »
- Si le rapprochement est effectué avec échec, un message d’alerte sera affiché demandant à
l’utilisateur de bien vouloir corriger les informations. La remise reste « prévalidée »
3.3.1.2.7 Consultation des remises déjà validées/pré-validées :
Les remises déjà validées/prévalidées peuvent être consultées afin de :

- Mettre à jour les informations : (montant total, nombre total, numéro de compte
bénéficiaire…)

Statut Ebauche
- Mettre à jour les informations détaillées concernant les valeurs : (montant, date,
échéance, nature du chèque.
- Suppression d’une valeur scannée.
Les images des chèques de la remise sont affichées a chaque consultation.
3.3.1.2.8 La deuxième validation des valeurs saisies :
La deuxième validation des valeurs saisies est paramétrable. En effet, un paramètre au niveau
de l’application permet l’activation de la deuxième validation. En cas d’inactivation, la double
validation n’est plus obligatoire et la génération des images est effectuée dès la validation par
l’utilisateur.
La deuxième validation ne peut pas être effectuée par le premier utilisateur qui a effectué la
saisie.
Une fois que le deuxième validateur effectue la validation, l’utilisateur qui a saisit la valeur ne
pourra plus la modifier.
3.3.1.2.9 II.1.2.9 Génération fichier de données
Le fichier de données de chaque type de valeur et devise ne contient que les remises validées.
3.3.1.2.9.1 Génération du fichier DATA à chaque validation de la remise :
A chaque fois que l’utilisateur valide la remise, un fichier data est généré automatiquement
contenant toutes les informations de la remise validée.
3.3.1.2.9.2 Génération du fichier DATA à la demande de l’utilisateur
A chaque fois que l’utilisateur valide la remise, un fichier data est généré automatiquement
contenant toutes les informations depuis le début de la journée.
3.3.1.2.9.3 Génération du fichier DATA à la fin de journée :
Quand l’utilisateur lance les traitements de la fin de journée, un fichier DATA est
automatiquement généré et contient toutes les informations de la remise validée.
Remarque :
- Les fichiers DATA sont générés dans des formats prédéfinis.
- Les fichiers DATA sont générés par valeur et par devise.
- Les fichiers DATA peuvent être générés à n’importe quel moment de la journée.

Statut Ebauche
- Dans le mode remise, le fichier DATA pour chaque instrument contient un
enregistrement global et plusieurs enregistrements détail pour chaque remise.
L’enregistrement global contient les informations sur chaque valeur scannée de la
remise.
- Les fichiers DATA sont sécurisés dès leur génération dans l’application. La sécurisation
des fichiers DATA permet la détection des modifications faites après leur génération.
3.3.1.2.10 Réconciliation entre les fichiers des données et les fichiers du système
agence
Cette fonction est importante en cas de double saisie au niveau du CBA. Elle permet le
rapprochement entre les deux saisies, et génère éventuellement une différence et/ou des
erreurs de réconciliation.
La réconciliation est effectuée en comparant le global et le détail d’un fichier généré par le CBA
et celui généré par Barberousse Capture.
3.3.1.2.10.1 Types de réconciliations
Trois types de réconciliations sont disponibles. Ces types de réconciliation sont les suivants :
1. Réconciliation 1 : Réconciliation entre le fichier global des remises généré au niveau du
système interne, et le fichier des données généré par la capture.
2. Réconciliation 2 : Réconciliation entre le fichier détail des remises généré au niveau du
système interne, et le fichier des données généré par la capture.
3. Réconciliation 3 : Réconciliation entre le fichier envoi (.ENV) généré par le système interne
et le fichier des données généré par la capture
Remarques
- La réconciliation peut se faire à tout moment de la journée.
- Les fichiers à réconcilier doivent être déposés par le CBA et doivent avoir la même
structure que les fichiers de données (.data) de chaque type de valeur ;
Le résultat de tout type de réconciliation est affiché. Il peut être imprimé et enregistré dans un
fichier. L’opérateur peut également procéder à des rectifications en cas d’erreur.
3.3.1.2.10.2 Rectification des données
Lorsque la réconciliation révèle des erreurs, l’opérateur a la possibilité de rectifier les données
erronées qu’il a pu saisir (identifiant de la remise, RIB bénéficiaire, montant global, nombre
total….). Toute rectification des données engendre la suppression du fichier de données.

Statut Ebauche
Suite à la validation de ces rectifications, il y a lieu de régénérer le fichier de données.
3.3.1.2.11 Génération des fichiers images (.PAK) et index (.CAT)
3.3.1.2.11.1 Génération des fichiers PAK et CAT unitaires
La génération des fichiers .CAT et .PAK unitaires se fait à la deuxième validation si le

paramètre correspondant est activé, sinon la génération est effectuée dés la première
validation de la remise.
Un couple de fichiers unitaires CAT et PAK est généré pour Valeur scannée.
Les fichiers CAT unitaires contiennent les données qui vont permettre d'identifier les images
dans les fichiers PAK.
Les fichiers packages .PAK contient les images recto et verso de la valeur scannée.
Tous les fichiers .CAT et PAK générés sont placés dans les sous-répertoires correspondants :
 Chèque inter-bancaire
 Chèque interbancaire
 Lettre de change / interbancaire ;
 Lettre de change / intrabancaire.
3.3.1.2.11.2 Génération des fichiers PAK et CAT intermédiaires, différentiels et

globaux
Une génération de fichiers .PAK et .CAT peut aussi se faire en cours de journée, Suite à la
demande de l’utilisateur :
 Un .PAK et un .CAT cumulés par type de valeur et par devise ;
 Un .PAK et un .CAT différentiels (à partir de la dernière génération) par type de
valeur et par devise.
L’opérateur peut générer les fichiers intermédiaires et cumulés à tout moment de la journée.
Dans le cas d’un traitement par remise, ces fichiers ne contiennent que les remises validées,
alors que dans le cas d’un traitement par lot ces derniers ne comportent que les valeurs pour
lesquelles les données obligatoires ont été saisies ou importés. En cas d’inexistence de lots à
générer : aucune remise validée (traitement par remise) ou aucune valeur dont les données
ont été saisies (traitement par lot), l’applicatif affiche un message indiquant qu’il n’y a aucune
donnée à générer.
3.3.1.2.12 Traitement des exceptions et des anomalies
Durant le processus de capture, des anomalies ou des exceptions peuvent surgir.
La liste des exceptions gérées par le module de Capture est la suivante:

Statut Ebauche
- Scanner non connecté ou non allumé.
- Incident mécanique ;
- Bourrage au niveau du scanner ;
- Doubles : deux valeurs passant ensemble au niveau du scanner;
- Interruption de communication avec le scanner ;
- Reprise en cas de pannes ;
- Erreurs de drivers (absence de driver, driver non correspondant, …) ;
- Ligne MICR défectueuse: la ligne MICR peut présenter des anomalies qui affectent
sa lecture à partir du scanner, il s’agit notamment des cas suivants:
 Cas de la scannérisation d’un chèque à l’envers (piste en haut) ;
 Cas de la scannérisation d’un chèque du coté du verso ;
 Cas d’un caractère manquant au niveau de la piste ;
 Cas d’un défaut d’impression de la piste ;
 Cas d’une piste altérée (ex : caractère troué) ;
 Cas d’un chèque sans ligne MICR.
3.3.1.2.13 Forçage de la date
Lorsque la date session générée par la banque (ou saisie) est erronée, mais supérieure à la
date de clôture de la veille, l’administrateur de l’agence dispose de la possibilité de forçage de
la date.
Le forçage de la date implique la mise à jour des outputs générés depuis l’initialisation de la
journée. Ces mises à jour sont les suivantes :
 Mise à jour de la date et des signatures au niveau de la base de données ;

 Suppression et régénération des fichiers d’images et d’index individuels ;
 Suppression des fichiers DATA éventuellement générés avant le forçage.
 Génération des fichiers index et image avec la nouvelle date de session.
 Si la date session consommée, est supérieure à la date de fin de validité de la clé de
signature courante et a engendré la prise en compte de la nouvelle clé, le forçage de
la date opéré par l’administrateur afin de rétablir la date correcte permet de
reprendre en charge la bonne clé (i.e. la clé courante). Ce cas peut se présenter si
la date chargée est supérieure à la date fin de la clé courante.
3.3.1.2.14 Scannérisation multi-Agences
B-capture permet à l’administrateur de l’application de définir un profil d’agences hôtes

pourrant scanner leurs remises dans des agences installées. En conséquence, Il permet le

Statut Ebauche
traitement des remises traitées par plusieurs agences de la même banque et la génération de
ses outputs.
En définissant le profil d’utilisateur comme une « autre agence », l’administrateur doit spécifier
l’agence correspondante, donc quand l’utilisateur entre avec son utilisateur et mot de passe,
l’environnement de l’agence en question sera affiché.
Un utilisateur d’une agence hôte peut seulement accéder à son agence.
3.3.1.2.15 Traitement centralisé
L’application Barberousse-Capture offre la possibilité de traiter les chèques et lettres de change

de toutes les agences confondues. Pour ce faire, il suffit de paramétrer comme code agence le
code « 999 » lors de l’installation.
Dans ce cas, tous les traitements sont identiques à ce qui est décrit plus haut. Toutefois, tous
les fichiers relatifs aux images scannées sont générés dans un même répertoire par type de
valeur et sans distinction par rapport au code agence.
3.3.1.2.16 Traitement multipostes
Barberousse-capture peut être installé dans différent postes ce qui permet la répartition de la
charge de travail sur plusieurs utilisateurs entraînant ainsi des gains de temps.
La scannérisation multipostes présente un outil d’allocation et de supervision de la charge de

travail pour les fonctions de saisie.
3.3.1.2.17 Saisie/Import des Données bénéficiaires
Barberousse-Capture permet la saisie des données bénéficiaire des chèques et des lettres de
change. Ces informations sont :
- RIB bénéficiaire
- Nom et prénom bénéficiaire
- Adresse Bénéficiaire.
Le masque permet aussi de charger les données bénéficiaires issues du CBA.
3.3.1.2.18 Clôture de la journée de capture
La clôture de la journée de capture est initiée par l’opérateur. Elle donne lieu à :
- L’édition d’un état comprenant les données globales de la journée de capture par type de
valeur (chèque et lettre de change) par devise et par profil ;
- La génération d’un fichier contenant la date de clôture
Statut Ebauche
- Tri des fichiers : La copie intégrale des répertoires dans lesquels ont été générés les
fichiers .CAT et .PAK de l’agence en question ainsi que ceux des autres agences ayant
éventuellement effectué la scannérisation de leurs chèques auprès de cette dernière. La
stratégie de sauvegarde consiste à l’utilisation de deux répertoires de sauvegarde, un pour
sauvegarder les fichiers de la veille, le deuxième pour sauvegarder les fichiers de l’avant
veille.
- La génération des fichiers .CAT de fin de journée ;
- La génération du fichier de données chèques et du fichier de données lettres de change ;
- La purge de la journée opération.
Il est à noter que, lorsque la réconciliation 3 est obligatoire, l’applicatif s’assure, lors de la
clôture de la journée, qu’elle a été effectuée avec succès. Autrement, la clôture de la journée
ne peut avoir lieu.
3.3.1.2.19 II.1.2.21 Editions des états et statistiques
Toutes données de toutes les remises traitées pendant une journée de scannérisation peuvent
être regroupées dans des états
3.3.1.2.19.1 Des états Détails
- Bordereaux détaillé par remise/Lot : Chèque et / ou LDC.

- Etats détaillés par agence destinataire : Chèque et / ou LDC.
- Etats détaillés par banque destinataire : Chèque et / ou LDC.
3.3.1.2.19.2 Des états Récapitulatifs
- Etats récapitulatifs des remises/Lots interbancaires.

- Etats récapitulatifs des remises/Lots intrabancaires.
- Etat récapitulatif général.
3.3.1.2.19.3 Etat de consommation des clés
Cet état renseigne l’utilisateur sur la dernière clés consommée : statut, date de début, date
fin de validité, taille, etc.
3.3.1.2.19.4 Etat des incidents
Tout au long des traitements d’une journée, différentes erreurs liées à l’application de capture
peuvent survenir. Ces erreurs obéissent à une codification bien déterminée et sont répertoriées
au niveau d’un état des incidents.

Statut Ebauche
3.3.2 Description fonctionnelle du module Générateur de clés
3.3.2.1 Présentation :
La principale fonctionnalité de Barberousse Générateur clé (Installation agence) est de recevoir

et sauvegarder les clés de signature et d’authentification nécessaires pour la sécurisation des
images.
Ces clés sont reçues de Barberousse-Générateur clés du siège de la banque à travers le

transfert sécurisé SSL.
L’accès à l’application est sécurisé et les différents niveaux d’autorisation peut être affecté à
plusieurs groupes et utilisateurs de l’application.
3.3.2.2.1 Gestion des droits et des autorisations d’accès:
A l’instar de Barberousse-capture, ce module fournit les mêmes fonctionnalités de gestion des

groupes, d’utilisateurs, de droits d’accès et de mot de passe.
3.3.2.2.2 Réception et sauvegarde des clés :
Les clés générées au siège de la banque sont envoyées automatiquement par le protocole SSL
sécurisé (Secure Socket Layer)
Ces clés sont consommées par Barberousse-GénérateurClés (agence) qui les sauvegarde
et envoie un acquittement vers Barberousse-générateur Clés siège.
D’un autre coté, Barberousse-Générateur Clés (installation agence) reçoit et sauvegarde la clé
centre de compensation transférée par Barberousse-Générateur Clés (installation siège).
Les clés sont sauvegardées indépendamment de leurs statuts (nouvelle clé, clé courante, clé
archivée, clé annulée).
La consultation permet de voir les clés du siège et du centre de compensation avec leurs
différents statuts :
- Privée et publique du siège.
- Publique du centre de compensation.
3.3.2.2.3 Chargement manuel des clés

Statut Ebauche
En cas d’échec d’envoi automatique des clés vers les agences à cause d’un problème de
télécommunication, Barberousse-générateur Clés (installation agence) permet le chargement
manuel des clés.
3.3.2.2.4 Edition des statistique
Barberousse-générateur Clés permet l’édition des statistiques concernant les clés reçues selon
la période choisie par l’utilisateur.
3.3.2.2.5 Consultation des messages SSL
L’utilisateur peut consulter la liste des messages SSL :
- Clés reçues :
- Acquittement des clés reçues
- Acquittement des clés envoyées
La recherche peut être effectuée par le statut de transmission :
- Succès : succès d’envois

- Echec : échec d’envoi
- Suspens : clés en cours de transmission
Une reprise manuelle de transmission est possible en cas d’échec d’envoi.
3.3.3 Description fonctionnelle du module Barberousse GIP
Barberousse –GIP permet la visualisation des valeurs interbancaires et intrabancaires ainsi que
les images en provenance d’autres pays durant la journée afin de permettre aux utilisateurs
d’effectuer les rejets bancaires.
3.3.3.2.1 Gestion des droits et des autorisations d’accès
A l’instar des autres modules agence, ce module fournit les mêmes fonctionnalités de gestion
des groupes, d’utilisateurs, de droits d’accès et de mot de passe.
3.3.3.2.2 Initialisation de la journée :

Statut Ebauche
L’initialisation de la journée consiste en ces opérations :
- Consommation de la nouvelle date de session
- Vérification et import des valeurs en provenance du centre
- Vérification et import du référentiel
- Purge des anciens fichiers dans la Boite aux lettres.
- Vérification et chargement des remises intrabancaires
3.3.3.2.2.1 Consommation de la date
Selon le paramétrage, la consommation de la nouvelle date de session peut se faire à travers

la consommation automatique ou bien la saisie manuelle.
Tant que la nouvelle date session n’est pas consommée, aucune autre opération ne sera
possible au niveau du module.
3.3.3.2.2.2 Consommation du référentiel participant
Le référentiel comprend les informations de gestion sur :
- les participants : code participant, codes agences, mode de participation et état.
- Les devises : statuts et codes devise.
- Le calendrier des jours fériés,
- Les valeurs financières : statuts et codes valeur.
3.3.3.2.3 Chargement des images et des fichiers de données
Les fichiers sont automatiquement chargés à l’initialisation de la journée ou bien chargées

manuellement par l’utilisateur.
Cette fonction permet à l’utilisateur de charger les images et données en provenance du centre
de compensation (interbancaires) ou bien du siège de la banque (intrabancaires).
Lors du chargement, Barberousse –GIP effectue les contrôles suivants :
- Contrôle de conformité des fichiers images.
- Authentification des images
- Contrôle syntaxique et logique des fichiers de données.
3.3.3.2.4 Consultation des images et données reçues

Statut Ebauche
Barberousse-GIP permet la consultation des images et données de la journée. L’utilisateur
peut voir le recto et le verso des images reçues.
L’affichage peut être raffiné avec des critères de recherche choisis par l’utilisateur.
L’affichage des images peut être personnalisé. (Visualization recto/verso, Zoom, rotation…)
L’utilisateur peut imprimer un état contenant l’image en resto et verso de la valeur

sélectionnée et ses informations les plus significatives.
De plus, Barberousse-GIP permet l’affichage des signatures des détenteurs du compte si elles
sont fournies par le système d’information. Le spécimen de signature est affiché
automatiquement a côté de l’image de la valeur reçue et peut ainsi facilement procéder au
contrôle visuel de conformité de la signature.
3.3.3.2.5 Gestion des rejets
3.3.3.2.5.1 Saisie des motifs de rejet Gestion des rejets :
En cas de problème au niveau de la vérification des images et des fichiers au niveau du CBA,
l’utilisateur peut choisir les transactions une par une afin d’effectuer les rejets et de choisir les
motifs adéquats. En effet, l’utilisateur peut choisir jusqu’à quatre motifs de rejets en même
temps pour une seule valeur.
Si Barberousse –GIP reçoit une annulation d’une opération, l’utilisateur ne peut pas la
rejeter.
3.3.3.2.5.2 Consultation des rejets :
Les rejets non encore générés peuvent être consultés à travers un masque spécifique.
L’utilisateur a la possibilité d’annuler un rejet ou plusieurs, un motif ou plusieurs.
3.3.3.2.5.3 Génération des fichiers de rejet
Le fichier de rejet peut être effectué par l’utilisateur durant la journée de compensation.
L’utilisateur peut choisir plusieurs valeurs ou même la totalité des valeurs à être générées par
code valeur ou nature de remise choisie.
A la génération, la date de règlement est calculée suivant le moyen de payement ainsi que la
date et l’heure de génération du fichier.

Statut Ebauche
3.3.3.2.6 Gestion des annulations
3.3.3.2.6.1 Saisie des annulations
Cette fonction permet à l’utilisateur d’annuler les rejets déjà générés.
Le masque de « traitement des annulation » affiche toutes les valeurs générées et permet à
l’utilisateur de choisir un ou plusieurs valeurs à annuler.
3.3.3.2.6.2 Consultation des annulations
Les rejets annulés non encore générés peuvent être consultés à travers un masque spécifique.
L’utilisateur a la possibilité de supprimer une ou plusieurs annulations.
3.3.3.2.6.3 Génération du fichier d’annulation
La génération du fichier d’annulation peut s’effectuer durant la journée. L’utilisateur peut

sélectionner de la liste un ou plusieurs valeurs à générer.
NB : l’annulation est conditionnée par une période après laquelle il n’est plus possible de
l’effectuer. La période d’annulation est définie dans le système central et est envoyée dans le
référentiel vers les participants.
3.3.3.2.7 La double Validation des rejets/annulations
La double validation des rejets/annulations est une option qui peut être utilisée dans ce
module.
Une fois activée, avant la génération des remises de rejets/annulations, un validateur doit faire
une deuxième validation de ces opérations d’un masque spécifique.
En cas d’activation, la double validation des rejets/annulations est nécessaire pour la

génération.
3.3.3.2.8 États :
Plusieurs états affichant les différentes opérations traitées peuvent être édités :
- Etat des opérations reçues
- Etat des opérations rejetées reçues
- Etat des opérations rejetées
- Etat des opérations acceptées
- Etat des opérations annulées reçues

Statut Ebauche
- Etat des opérations d’annulation reçues
- Etc…
Les états peuvent être édités sous un format électronique ou bien imprimés sur du papier.
3.3.3.2.9 Forçage de la date :
Quand la date chargée est erronée, l’administrateur agence peut forcer cette date et saisir une
nouvelle date.
Le forçage de la date implique la mise à jour des outputs dès le début de journée, ces mises à
jour sont :
- mise à jour dans la base de données.
- Suppression des fichiers générés.
- Génération des nouveaux fichiers avec la nouvelle date.
3.3.3.2.10 Consultation en ligne des données et images archivées :
Barberousse-GIP offre la possibilité de consulter le WEB du centre de compensation afin de

visualiser les images et les informations archivées.
3.3.3.2.11 Installation multi-agences :
Barberousse-GIP permet à l’administrateur de l’application de définir un profil d’agences

invitées qui sont capables de traiter leurs remises reçues au niveau de l’agence. De ce fait, il
permet le traitement des remises reçues par plusieurs agences de la même banque et la
génération de ses outputs dans des fichiers séparés.
En définissant le profil d’utilisateur comme une « autre agence », l’administrateur doit spécifier
l’agence correspondante, donc quand l’utilisateur entre avec son utilisateur et mot de passe,
l’environnement de l’agence en question sera affiché.
Un utilisateur d’une agence hôte peut seulement accéder à son agence.
3.3.3.2.12 Installation centralisée :
Barberousse-GIP offre la possibilité de traiter les valeurs d’une banque, toute agence
confondue et ce en paramétrant le code agence a « 999 ».
Dans ce cas, les traitements sont les même que ceux décrits précédemment. En revanche tous
les fichiers des agences seront générés dans le même répertoire.

Statut Ebauche
3.3.3.2.13 Installation multipostes :
Barberousse-GIP peut être installé dans différent postes ce qui permet la répartition de la
charge de travail sur plusieurs utilisateurs entraînant ainsi des gains de temps.

Statut Ebauche
3.3.4 Description fonctionnelle du module Générateur de clés Siège
La principale fonctionnalité de Barberousse Générateur clé (Installation agence) est de recevoir

et sauvegarder les clés de signature et d’authentification nécessaires pour la sécurisation des
images.Ces clés sont reçues de Barberousse-Générateur clés du siège de la banque à travers
le transfert sécurisé SSL.
Le module de génération est installé au siège de la banque et fonctionne en mode «Siège»,

mais également dans chaque agence ou lieu de scannérisation.
3.3.4.2.1 Gestion des droits et des autorisations d’accès:
A l’instar du module agence, ce module fournit les mêmes fonctionnalités de gestion des
3.3.4.2.2 Génération des clés
La génération des clés s’effectue au niveau du siège. Dans le cas d’une installation à l’agence,
le menu de génération est inhibé.
La génération des clés permet à un utilisateur autorisé de lancer à partir du siège d’une
banque la génération de deux clés : publique et privée qui seront envoyées à destination des
agences paramétrées à travers un transfert sécurisé.
3.3.4.2.3 Transmission des clés
Les clés générées à la banque sont envoyées à travers le protocole sécurisé SSL.
Ces clés sont également envoyées à la plateforme Hannibal-PosteAdherent qui les transmet au
centre de compensation.
De plus, Barberousse générateur clés reçoit la clé publique du centre de compensation à

travers Hannibal-PosteAdherent la sauvegarde et la transmet aux agences.
3.3.4.2.4 Sauvegarde des clés :
Barberousse-générateur Clés assure la sauvegarde des clés de la banque et du centre de

compensation. Ces clés seront utilisées par les agences pour les opérations de signature et
d’authentification.
Statut Ebauche
Les clés sont sauvegardées indépendamment de leurs statuts (nouvelle clé, clé courante, clé
archivée, clé annulée)
La consultation permet de voir les clés du siège et du centre de compensation avec leurs
différents statuts :
- Privée et publique du siège.
- Publique du centre de compensation.
3.3.4.2.5 Chargement manuel des clés
En cas d’échec de transmission des clés siège vers les agences ou vers le poste adhérent à
cause de problème de télécommunication, Barberousse-Générateur des Clés permet le
chargement manuel des clés à partir de supports amovibles.
3.3.4.2.6 Edition des statistique
Barberousse-générateur Clés permet l’édition des statistiques concernant les clés reçues selon
la période choisie par l’utilisateur.
3.3.4.2.7 Consultation des messages SSL
L’utilisateur peut consulter la liste des messages SSL :
- Clés reçues :
- Acquittement des clés reçues
- Acquittement des clés envoyées
La recherche peut être effectuée par le statut de transmission :

- Succès : succès d’envois
- Echec : échec d’envoi
- Suspens : clés en cours de transmission
Une reprise manuelle de transmission est possible en cas d’échec d’envoi.
3.3.5 Description fonctionnelle du Module Autocollecte
Le module Autocollecte est un moniteur de transfert sécurisé des fichiers.
Le module Autocollecte est conçu pour partager les charges de collecte si elles sont

Statut Ebauche
Importantes entre deux serveurs communicants.
3.3.5.2 III.2.2 Fonctionnalités
3.3.5.2.1 Collecte des fichiers
La collecte se fait sur l’initiative du siège selon une minuterie générale.
Toutefois, il est possible de personnaliser la collecte par agence selon les paramètres suivants:
- Collecte par nombre de fichiers minimum;
- Collecte par intervalle de temps ;
Les opérations de collecte sont effectuées par le module central au niveau du siège.
Les fichiers collectés à partir des agences sont traités selon le principe « premier arrivé /
premier traité ».
La collecte peut se faire de plusieurs agences simultanément.
La collecte se fait au fil de l’eau dés leur création en agence, ce qui permet d’alléger le trafic
réseau et d’éviter les goulots d’étranglement.
Chaque fichier collecté avec succès est acquitté par le siège et ne sera plus collecté.
Pour assurer l’intégrité des fichiers à collecter, les services agents procèdent à leur signature
par un algorithme standard.
Les signatures des fichiers sont envoyées vers le siège pour servir au contrôle de l’intégrité des
fichiers à l’arrivée.
Les périodes de collecte entre siège et agence sens 1 et siège et agence sens 2 sont
indépendantes. Cette indépendance permet une flexibilité à l’utilisateur qui peut paramétrer
les périodes d’une façon indépendante selon son besoin.
3.3.5.2.2 Envoi de fichiers
Les opérations d’envoi sont effectuées par le module central au niveau du siège.
Les fichiers à envoyer sont inscrits au niveau de la file d’envoi.
Chaque entrée dans la file d’envoi est prise en charge par l’Autocollecte qui se charge de
l’envoyer jusqu’à sa destination.
L’envoi peut être effectué d’une façon simultanée pour plusieurs banques selon la règle
« premier détecté/premier envoyé »

Statut Ebauche
Après le transfert de chaque fichier, l’agent et le module central procéderont en collaboration
au contrôle de l’intégrité des fichiers.
En effet, le module central envoie à l’agent le nom et la signature du fichier envoyé et lui
demande de vérifier cette signature.
Selon le résultat de ce contrôle d’intégrité, le module Autocollecte met à jour la file d’envoi des
fichiers (envoi avec succès ou avec échec). Plusieurs tentatives de reprises d’envois des
fichiers envoyées avec échec sont effectuées.
3.3.5.2.3 Paramétrage du module Autocollecte
3.3.5.2.3.1 Paramétrage des flux de collecte
Pour chaque agence, le module Autocollecte permet de paramétrer les différents flux
Source/Destination des fichiers à transférer.
Le paramétrage consiste à définir :
- Le serveur de collecte principal qui va faire la collecte ;
- L’identifiant de l’agence ;
- Le chemin complet du fichier / répertoire source ;
- Le chemin complet du fichier / répertoire de destination.
3.3.5.2.3.2 Paramétrage de la minuterie générale
Les périodes de collecte et d’envoi sont indépendantes et peuvent se chevaucher. Cette

indépendance permet une flexibilité de paramétrage de la collecte et de l’envoi selon la volonté
de l’utilisateur.
- Horaire de début de collecte (heure début de session) ;
- Horaire de fin de collecte ;
- Horaire de début d’envoi ;
- Horaire de fin d’envoi (heure fin de session).
Le paramétrage des horaires de début et de fin de collecte et d’envoi peuvent se chevaucher

sur plusieurs journées calendaires.
3.3.5.2.3.3 Paramétrages spécifiques
Pour chacune des agences, le module Autocollecte permet de paramétrer :

Statut Ebauche
- L’heure de début de collecte pour cette agence (qui doit être >= Horaire de début de
collecte globale) ;
- L’heure de fin de collecte pour cette agence (qui doit être <= Horaire de fin de collecte
globale) ;
- La fréquence de connexion pour cette agence.
- nombre minimal de fichiers à partir duquel la collecte peut avoir lieu à partir de cette
agence.
3.3.5.2.4 Suivi opérationnel des échanges
Le module Autocollecte permet un suivi centralisé des transferts de fichiers entre les agences
et le siège.
Hannibal-Autocollecte se base sur une interface graphique offrant une vision de synthèse sur
l’activité de transfert des fichiers.
Toutes les informations concernant les transferts y sont disponibles comme l’état du transfert,
l’origine, la destination, la taille du fichier, le nombre de fichiers, le temps début transfert, le
temps fin transfert.
L’interface principale de suivi affiche les détails concernant un transfert donné et montre ses
différents statuts.
 Suivi de collection : L’agence, le nombre de fichiers à collecter, le nombre de fichiers

collectés, Heure début de collecte, Heure fin de collecte
 Suivi d’envoi : L’agence, le nombre de fichiers à collecter, le nombre de fichiers

collectés, Heure début de collecte, Heure fin de collecte
 Anomalies de connexion.
En cas d’échec de collecte ou d’envoi d’un fichier donné, Hannibal-Autocollecte reprend

l’envoi jusqu’au succès. Les intervalles de reprise sont paramétrables.
L’application permet également d’étendre la période de collecte pour l’ensemble des agences
ou pour une agence donnée.
3.3.5.2.5 Historique et Statistiques sur les échanges
3.3.5.2.5.1 Historique des échanges
Cette fonction permet d’afficher, par participant et par date, l’historique des opérations
suivantes :

Statut Ebauche
o Tous les fichiers transférés vers les agences ;
o Tous les fichiers reçus des agences ;
o Toutes les opérations terminées avec succès ;
o Toutes les opérations terminées avec échec.
L’historique desdites opérations est affiché sur une période déterminée par les champs « Date
début » et « Date fin ».
3.3.5.2.5.2 Statistiques du jour
Cette fonction permet de renseigner sur l’état de la collecte des fichiers du jour. Elle affiche :
- Le nombre de fichiers collectés ;
- Le nom des fichiers transférés ;
- Le répertoire d’où chaque fichier est collecté ;
- La taille du fichier.

Statut Ebauche
3.3.6 Description fonctionnelle du Module ADT
Le module ADT (Automatic Data Treatment) permet le traitement automatique, au niveau du

siège de la banque, des fichiers reçus à partir des agences et à partir du CBA de la banque. Il
permet aussi le traitement des remises retour compensation et leur tri par agence destinataire.
Il fonctionne en coordination avec Hannibal-Poste adhérent vers lequel il génère les lots à
présenter en compensation et à partir duquel il récupère les lots reçus de la compensation.
Il fonctionne aussi en coordination avec le module Hannibal-Autocollecte à partir duquel il

récupère les lots collectés des agences et vers lequel il génère les lots à envoyer aux agences
Le module ADT est divisé en trois modules :
- ADT-Contrôle : assure le contrôle de tous les lots reçus : des agences ou du

centre de compensation
- ADT-Générateur : assure la génération des lots : vers le centre de compensation

et vers les agences.
- ADT-Administration : qui assure l’administration et la supervision des opérations

effectuées au niveau du siège ainsi que la gestion des paramètres généraux de
l’application.
3.3.6.2.1 Ouverture de la session
L’ouverture de la session est déclenchée par l’arrivée de l’horaire « Début de session ».
La nouvelle session ne peut être ouverte qu’après réception de la nouvelle date session au
niveau du poste adhérent.
Après la consommation de la nouvelle date, Hannibal-ADT génère des fichiers date qui seront
envoyés vers les différentes agences pour initialiser les journées.
3.3.6.2.2 Traitement des données reçues des agences
Dès le début de la session, le module ADT procède aux traitements suivants :
- Détection des fichiers reçus des agences ;
- Contrôle des fichiers images CAT et PAK;
- Contrôle des fichiers ENV;

Statut Ebauche
- Contrôle des fichiers DATA
- Réconciliation des fichiers de données et des images ;
- Calcul de la date de règlement
- Génération des remises inter-pays
- Génération des remises interbancaires;
- Génération des remises intrabancaires;
- Calcul de la situation nette du participant
3.3.6.2.2.1 Détection des fichiers reçus des agences
Les fichiers sont détectés et contrôlés dès leur inscription au niveau de la file de réception du
siège et leur dépôt au niveau de la boîte aux lettres du siège. Les fichiers reçus sont les
suivants :
- Les remises envoi (.ENV) contenant les données préparées soit par le CBA de la
banque soit par Barberousse présentation : Virements, prélèvements, chèques,
lettres de change, opérations sur cartes ;
- Fichiers d’image CAT et PAK des chèques, et lettres de change.
- Les fichiers (.DATA) contenant toutes les valeurs chèques et lettres de change.
Les fichiers reçus au niveau de la file de réceptions ont par défaut le statut de contrôle « 0-
Attente de contrôle ».
En cas de contrôle avec succès, les fichiers ont le statut de contrôle « 1- contrôle avec
succès».
En cas de contrôle avec Echec, les fichiers ont le statut de contrôle « 2- contrôle avec Echec».
3.3.6.2.2.2 Contrôle des fichiers images
Ce contrôle concerne tout type de fichiers images (.CAT et .PAK) : élémentaires, cumulés,
différentiels et globaux reçus à partir des agences. Les contrôles effectués à ce niveau
concernent :
- L’authentification des images : elle permet de s'assurer que les fichiers reçus à ce
niveau sont authentiques et qu'ils n'ont pas été altérés durant leur transfert. La
détection d’une image non authentique engendre la génération d’une alerte et
l’affichage de l’erreur d’authentification en couleur rouge;

Statut Ebauche
- La vérification de conformité CAT/PAK : Cette vérification consiste à s’assurer que
pour chaque image dans le fichier .PAK existe son correspondant dans le fichier
.CAT.
- Le contrôle des doublons : A l’arrivée de chaque image, le module ADT vérifie si

cette dernière a déjà fait l’objet d’un traitement pendant cette même journée ou
pas.
3.3.6.2.2.3 Contrôles des Fichiers .DATA
3.3.6.2.2.3.1 Authentification fichier DATA
Les DATA des chèques et lettres de change sont authentifiés d’une façon continue dès leur
arrivée des agences.
Ce contrôle est effectué pour assurer que ces fichiers sont authentiques et qu’ils n’ont pas été
modifiés ou endommagées après leur génération.
3.3.6.2.2.3.2 Contrôles syntaxiques
Ce contrôle a pour objectif de vérifier :
- L’intégrité du fichier.
- L’état complet des enregistrements data.
- Le respect des types de champs prédéfinis.
Les fichiers non valides seront rejetés entièrement par Hannibal-ADT. Dans ce cas, une alerte
et le détail des erreurs est affiché et peut être édité ou sauvegardé.
3.3.6.2.2.3.3 Contrôles logiques
Il comprend tous les contrôles liés à la cohérence d’information liée au « business rule » défini
au système central et consommé au niveau du référentiel.
3.3.6.2.2.3.4 Conversion fichiers DATA
Après le succès de contrôle, les enregistrements data chèques et lettres de change sont
convertis pour des enregistrements ENV afin d’être traitées par l’ADT.
3.3.6.2.2.4 Contrôles des Fichiers .ENV

Statut Ebauche
Ces contrôles sont appliqués aux :
- Fichiers de présentations et de représentations ;
- Fichiers de rejets ;
- Fichiers d’annulation de présentation.
- Fichiers d’annulation de rejet
Ces Fichiers peuvent être générés aussi bien au niveau agence qu’au niveau du siège.
3.3.6.2.2.4.1 Authentification des fichiers ENV
Les ENV des chèques et lettres de change sont authentifiés d’une façon continue dès leur
arrivée des agences.
Ce contrôle est effectué pour assurer que ces fichiers sont authentiques et qu’ils n’ont pas été
modifiés ou endommagées après leur génération.
Ce contrôle vérifie :
- l’intégrité du fichier
- l’état complet des fichiers de données
- la conformité avec les types de champs prédéfinis.
Les fichiers non valides seront rejetés entièrement pas Hannibal-ADT. Dans ce cas, une alerte
Il comprend tous les contrôles liés à la cohérence d’information liée aux règles de contrôle
défini au système central et consommé au niveau du référentiel.
3.3.6.2.2.4.4 Contrôles réglementaires

Statut Ebauche
Ils comprennent tous les contrôles en relation avec la concordance des informations avec les
exigences règlementaires. Ces contrôles comprennent la vérification de l’historique dans la
base de données comme le contrôle du délai de rejet ou du motif de rejet appliqué à la valeur.
Pour effectuer les contrôles réglementaires, un historique des présentations et des rejets est
requis. La durée de cet historique est définie au niveau des paramètres de l’ADT.
Les fichiers non valides seront rejetés unitairement par Hannibal-ADT. Une alerte et le détail
des erreurs est affiché et peut être édité ou sauvegardé.
3.3.6.2.2.4.5 Contrôle des doublons
Lors du contrôle de chaque enregistrement .ENV, le module ADT vérifie qu’aucun autre
enregistrement identique n’existe dans la base.
En cas de détection de doublons, le module ADT rejette le doublon reçu (i.e. le 2 e

enregistrement) tout en générant un message d’alerte qui est affiché à l’écran.
3.3.6.2.2.5 Gestion des annulations
3.3.6.2.2.5.1 Contrôle des annulations d’opérations
Les opérations à annuler par le participant devront être préparées par le CBA et
communiquées au module ADT qui vérifie les rejets et les délais d’annulation des opérations à
annuler comme suit:
A. Vérification des délais d’annulations : ADT-contrôle vérifie le dépassement des délais

d’annulations des opérations à annuler :
- Si le délai d’annulation de l’opération est dépassé, l’annulation n’est pas acceptée

par ADT-Contrôle ;
B. Vérification des rejets : Le module ADT vérifie si les opérations à annuler n’ont pas déjà
fait l’objet de rejet bancaire par la banque destinataire. dans ce cas, l’annulation ne
sera pas acceptée par l’ADT.
3.3.6.2.2.5.2 Génération des remises d’annulation d’opérations
Les opérations d’annulation acceptées par le module ADT sont enregistrées au niveau de la
base de données. Le module ADT identifie pour chaque opération à annuler, la remise de
présentation initiale. Ainsi, toutes les opérations annulées, appartenant initialement à une
même remise, seront générées dans une même remise d’annulation qui a la même référence
de que la première (numéro du lot).

Statut Ebauche
3.3.6.2.2.5.3 Impact des annulations générées sur les traitements ADT
La génération d’une remise d’annulation d’opérations par le module ADT entraîne la mise à
jour de la situation nette.
3.3.6.2.2.6 Insertion des informations
Les informations de ces remises sont insérées seulement dans le cas de succès de contrôle.
3.3.6.2.2.7 Réconciliation des fichiers images et des données
Ce contrôle est utilisé pour vérifier que les fichiers de données à images ne sont pas transmis
au centre de compensation sans image et qu’aucune image n’est transmise au centre de
compensation sans donnée. Il permet aussi de vérifier la conformité des informations
contenues dans le fichier de donnée sans image et celui à image.
Les enregistrements accusant un succès de réconciliation seront marqués avec le statut de

réconciliation« 1- Réconcilié avec succès » au niveau de la base de données.
Il est à noter que les valeurs sans image ont par défaut le statut de réconciliation « 1-
Réconcilié avec succès ».
3.3.6.2.3 Génération des remises interbancaires
Cette opération est effectuée d’une manière continue et automatique dès que l’une des
conditions suivantes est satisfaite (selon le paramétrage effectué) :
- Heure de début de génération interbancaire est arrivée ;
- Intervalle temporel de génération est atteint ou taille seuil des remises à générer
est atteinte.
L’opération de génération consiste à concaténer tous les enregistrements de données et

d’images réconciliés avec succès en une ou plusieurs remises globales selon les conditions de
génération choisies. Cette génération se fait par code valeur, par code devise, par code
enregistrement (présentation ou rejet) et par code centre (intrabancaire, interbancaire ou
régional).
L’écran de suivi de la génération au niveau du module ADT générateur permet à l’utilisateur

suivre les générations par nombre valeur et par type.
3.3.6.2.4 Génération des remises intrabancaires
Cette opération est effectuée d’une manière continue et automatique dès que l’une des
conditions suivantes est satisfaite :

Statut Ebauche
- Heure de début de génération intrabancaire est arrivée ;
- Intervalle temporel de génération est passé ou taille seuil des fichiers à générer est
atteinte.
La génération consiste à trier les enregistrements de données et d’images de présentation, de

représentation, d’annulation et de rejets intrabancaires par valeur, code enregistrement et par
agence tirée.
3.3.6.2.5 Calcul des dates de règlement
Lors de la génération des remises, l’application effectue le calcul des dates de règlement et de
présentation pour chaque valeur générée.
Date de règlement = Date Présentation + Délai de règlement
3.3.6.2.6 Traitement réception du centre de compensation
A la réception des fichiers retours compensation, le module ADT effectue les traitements
suivants :
- Décrypte les fichiers retours compensation par la clé Privée Siège ;
- Décompresse les fichiers images retour.
- Authentification des images et contrôle des fichiers de données.
- Met à jour la situation nette de la banque
- Génère et fait le tri par agence destinataire
- Mise à disposition des remises pour transfert au CBA de la banque ;
3.3.6.2.7 Détection des remises de la compensation
Dès leur arrivée au niveau de la BAL du poste adhérent en provenance du centre de

compensation, les remises sont automatiquement détectées et prises en charge par le module
ADT-Contrôle.
3.3.6.2.8 Décryptage et décompression des remises reçues de la compensation

Statut Ebauche
A la Réception des fichiers retours en provenance de la compensation, Hannibal ADT-Contrôle
procède au Décryptage de ces derniers. En plus du décryptage, les lots à image sont
également décompressés.
3.3.6.2.9 Contrôle des remises reçues de la compensation
Chaque RCP reçu sera validé syntaxiquement, logiquement et du contrôle des doublons.
Chaque CAT/PAK sera validé après les contrôles d’authentification et de réconciliation.
3.3.6.2.9.1 Contrôle syntaxique des remises RCP.
A la réception de chaque fichier .RCP en provenance de la compensation et après décryptages,

les contrôles suivants sont effectués:
Les fichiers non valides seront rejetés entièrement pas Hannibal-ADT. Dans ce cas, une alerte
3.3.6.2.9.2 Contrôle logique des remises RCP
Il comprend tous les contrôles liés à la cohérence d’information liée au « business rule » défini
au système central et consommé au niveau du référentiel.
3.3.6.2.9.3 Contrôle des doublons
Ce contrôle vérifie si une transaction a été traitée par le module ADT durant le même jour ou
durant la période d’historique des transactions. Si le cas se présente, la transaction est
qualifiée comme doublon.
Les enregistrements en double détectés sont générés dans un fichier séparé (.DBL) ayant la
même structure des fichiers RCP. Une alerte est affichée avec une couleur rouge informant le
rejet.
3.3.6.2.9.4 Authentification des images reçues
L’opération d’authentification des images cheques et lettres de change est effectuée d’une
façon continue dès l’arrivée des fichiers CAT et PAK du centre de compensation.
Statut Ebauche
Ce contrôle est fait pour s’assurer que ces fichiers sont authentiques et qu’elles n’ont pas été
endommagées ou modifiés durant le transfert.
L’authentification est effectuée en utilisant la clé publique du centre.
La non authenticité d’une image génère une alerte et affiche une erreur d’authentification.
3.3.6.2.9.5 Réconciliation des fichiers CAT et des remises RCP
Ce contrôle est utilisé pour vérifier que les fichiers de données à images ne sont pas reçus du
centre de compensation sans image et qu’aucune image n’est reçue du centre de
Pour chaque valeur à image, il permet aussi de vérifier la conformité des informations
3.3.6.2.10 Tri et Génération des remises reçues par agence tirée
Les remises interbancaires et régionales reçues du centre de compensation sont insérées dans
la base de données de l’application puis générées par agence tirée. Cette génération se fait par
agence, par valeur, par devise, par code centre et par type de remise.
Les fichiers .RCP, .CAT et .PAK Interbancaires triés vont être déposés dans les boîtes aux
lettres d’envoi du module ADT pour être transférés vers les agences destinataires par
Hannibal-autocollecte.
3.3.6.2.11 Calcul des situations nettes et mise à jour des soldes
3.3.6.2.11.1 Calcul des situations nettes
Ce calcul se fait automatiquement et d’une manière continue pour chaque devise au fur et à
mesure de :
- La génération des remises par le module ADT ;
- La réception des remises retours à partir du centre de compensation
- La réception des rejets réglementaires à partir du centre de compensation: les

situations nettes jusque-là calculées sont ajustées en fonction de ces rejets ;
- La réception du compte rendu final de fin de journée à partir du centre de

compensation.
3.3.6.2.11.2 Contrôle des limites débitrices

Statut Ebauche
Les limites sont définies pour chaque participant au niveau des centres de compensation.
Le contrôle des limites débitrices est effectué pour les valeurs interbancaires et régionales. Il
consiste à vérifier en continu (i.e. à chaque mise à jour de ses situations nettes) - grâce à un
compteur des situations nettes cumulées (i.e. toutes valeurs confondues) - si le seuil d’alerte
est atteint par rapport à la limite débitrice qui lui est définie.
Lorsque c’est le cas, le module ADT génère une alerte afin d’informer le trésorier de la banque.
Cette alerte ne génère aucune situation de blocage par rapport aux traitements du module qui
continue son fonctionnement normalement.
3.3.6.2.12 Interfaçage avec le poste adhérent
En plus de la détection des remises en provenance du centre de compensation, le module ADT-

charge à partir de Hannibal-PosteAdherent.
- la nouvelle date de session.
- Le nouveau référentiel.
- Le compte rendu de fin de journée (CPR).
- Les comptes rendus d’opération (CRO).
- Les rejets réglementaires (RJT).
- Les situations nettes définitives par valeur.
3.3.6.2.12.1 Consommation du Référentiel
La mise à jour du référentiel se fait dès qu’un nouveau référentiel est détecté.
Plusieurs référentiels peuvent être consommés pendant une même journée ; C’est l’horaire de
mise à jour qui indiquera le dernier référentiel arrivé.
Après consommation de chaque nouveau référentiel, ADT génère à son tour les référentiels
agences qu’il inscrit dans la file d’envoi pour qu’ils soient acheminés vers les agences
destinataires par Autocollecte.
3.3.6.2.12.2 Consommation du compte rendu de fin de journée
A la fin de la journée de compensation, le système de compensation retourne aux participants

remettants un compte rendu sur les traitements effectués sur les remises qu’ils ont envoyées
et sur les remises qui leur sont destinées.
Statut Ebauche
Ce fichier contient toutes les informations sur le suivi des remises envoyées au système central
ainsi que le nombre de remises .RJT et .RCP à recevoir par valeur.
En cas de non acquittement des remises envoyées (ENV) ADT-Contrôle génère une alerte pour
informer l’opérateur.
Dans le cas de manque d’RCP ou de rejet reçu les actions citées précédemment seront
bloquées jusqu’à l’arrivée du reste des fichiers.
La consommation du compte rendu final déclenchera la génération des comptes rendus

agences qui seront routés vers les agences remettantes et le CBA pour traitements.
Les comptes rendus agence contiendront le sort de toutes les opérations envoyées par chaque
agence dans la journée de compensation.
3.3.6.2.12.3 Consommation des rejets réglementaires
Les rejets réglementaires (RJT) effectués au niveau du centre de compensation et reçus par le
poste adhérent sont pris en charge au fur et à mesure de leur arrivée au siège par le module
ADT qui :
1. Met à jour le statut de l’opération au niveau de la base de données ADT;
2. Met à jour les situations nettes calculées.
Ensuite, le module ADT trie les fichiers de rejets réglementaires (RJT) par agence destinataire
et met les fichiers triés à la disposition de l’Autocollecte qui va les acheminer au niveau des
agences concernées.
3.3.6.2.12.4 Confrontation des Situations Nettes
A la réception des situations nettes définitives du centre de compensation, le module ADT

procède à la confrontation de ces dernières avec les situations nettes qu’il a calculées.
a. En cas de conformité absolue entre toutes les situations nettes, le module ADT
génère un message de confirmation des soldes de compensation toutes les
valeurs et devises confondues.
b. En cas d’échec de confrontation d’au moins une des situations nettes, Un

message d’alerte détaillant les causes de cet échec est généré par le module
ADT et la génération du message de confirmation n’a pas lieu.

Statut Ebauche
3.3.6.3 Fonctions du module ADT Administration
Hannibal-ADT Admin est l’application d’administration de Hannibal-ADT, il contient le

paramétrage et la supervision des transactions effectuées par les module Hannibal-ADT
Générateur et Hannibal-ADT contrôle.
3.3.6.3.1 Gestion des droits et des autorisations d’accès
A l’instar des modules agence, ce module fournit les mêmes fonctionnalités de gestion des
3.3.6.3.2 Paramétrage des répertoires de travail
Ce paramétrage permet de définir tous les répertoires avec lesquels le module ADT va
communiquer avec les autres applications (Module Poste Adhérent, module Autocollecte, CBA,
etc.). Ces répertoires sont :
- Les répertoires d’envoi et de réception des fichiers en provenance des agences;
- Les répertoires d’envoi et de réception des fichiers en provenance du CBA de la

banque ;
- Les répertoires d’envoi et de réception des fichiers en provenance du module Poste

Adhérent ;
3.3.6.3.3 Paramétrage de la durée de l’historique des présentations
Pour les besoins de contrôle de doublons des présentations et des contrôles réglementaires, un
historique des présentations doit être gardé par le module ADT et contient toutes les valeurs
présentées interbancaires intrabancaires et régionales. La durée de cet historique est
paramétrable dans Hannibal-ADT.
3.3.6.3.4 Paramétrage de génération des valeurs
Dans ce masque, trois types de paramétrage peuvent être établit : Paramétrage du mode de
génération (unique, multiple), Paramétrage de la fréquence, Paramétrage des horaires débuts
de génération interbancaires et intrabancaires.
3.3.6.3.5 Paramétrage des agences
Il s’agit de saisir et de mettre à jour les propriétés et les paramètres des agences de la
banque. (Adresses IP des machines et boîtes aux lettres d’envoi et de réception).

Statut Ebauche
Au niveau de chaque agence sont configurés un nom d’accès et un mot de passe FTP
déterminés, qui serviront à Hannibal Auto-collecte pour la collecte et l’envoi des fichiers en
provenance et à destination des agences.
3.3.6.3.6 Dépôt manuel
3.3.6.3.6.1 Dépôt manuel des remises Non Acquittées
Cet écran permet le dépôt manuel des remises générées par le module ADT la veille ouvrable
et qui n’ont pas été acquittés par le centre.
Les remises ainsi déposées seront traitées par le module ADT avec les enregistrements du
jour. Les traitements suivants doivent notamment être faits :
- Mise à jour des dates (dates de présentation, date de règlement, etc.) ;
- Re-signature des images si la signature de la banque a changé entre temps.
3.3.6.3.6.2 Dépôt manuel secours
En cas d’échec de connexion les fichiers en provenance des agences, du CBA ou du centre de
compensation peuvent être déposés pour être traités au module Hannibal-ADT. Ce menu
concerne les fichiers suivants :
- Fichiers images interbancaires, intrabancaires et régionales;
- Fichiers de présentation ENV interbancaires, intrabancaires et régionales;
Tous les fichiers déposés manuellement sont sujet aux mêmes contrôles syntaxiques, logiques,
réglementaires, d’authentification et de réconciliation.
3.3.6.3.7 Suivi des traitements de compensation
3.3.6.3.7.1 Consultation de la file d’attente
Une interface de recherche multicritère permet à l’utilisateur de rechercher un fichier donné

qui a déjà été inscrit au niveau de la file d’attente.
Pour affiner l’affichage, L’utilisateur pourra choisir parmi les critères de sélection tel que :
Code valeur, Statut (en attente, contrôlé avec succès, rejeté, inexistant, ..), Agence
Remettante, Centre de compensation : Interbancaire/Intrabancaire/Régional, etc..
3.3.6.3.7.2 Consultation des valeurs : Etat de la Base

Statut Ebauche
Cette consultation concerne toutes les opérations acceptées par les contrôles ADT.
Une interface de recherche multicritère permet à l’utilisateur de rechercher un enregistrement

donné et de visualiser son image si elle existe.
La consultation affiche également toutes les informations relatives à la valeur sélectionnée et

renseigne également l’utilisateur sur son état actuel (en attente de réconciliation, réconcilié
avec succès, réconcilié avec échec, généré, acquitté, etc.). Les enregistrements consultés
peuvent être édités (image et données).
Affichage de l’image : En parcourant les fichiers CAT, l’utilisateur peut voir le bouton image,
plusieurs options d’affichage sont disponibles tels que le zoom, la rotation et l’inversion de
l’image, en recto et verso.
3.3.6.3.7.3 Consultation de la file d’envoi
Une interface de recherche multicritères permet la consultation de toutes les valeurs générées
par l’ADT-Générateur déjà insérés dans la « Queueout » à être transférées vers les agences.
3.3.6.3.7.4 Consultation des remises générées
Une interface de recherche multicritères permet à l’utilisateur de consulter et d’éditer les

enregistrements qui ont été générés au cours de la journée.
- Remises interbancaires ;
- Remises intrabancaires ;
- Remises régionales.
3.3.6.3.7.5 Consultation remises reçues
Une interface de recherche multicritères permet à l’utilisateur de consulter et d’éditer les

enregistrements qui ont été reçus au cours de la journée.
- Fichiers interbancaires
- Fichiers régionaux.
Ces informations peuvent être éditées dans un état et sauvegardées sous forme électronique
ou imprimés sur papier.

Statut Ebauche
3.3.6.3.7.6 Consultation des Situations nettes
Le module ADT Administration permet de visualiser en temps réel les situations nettes
calculées par le module ADT, à la suite de la génération de chaque remise et/ ou de la
réception des remises du centre de compensation.
Cet écran affiche par valeur et par devise la situation nette jusque-là calculée, ainsi que le
cumul des situations nettes (toutes valeurs confondues) et les soldes bilatéraux et
multilatéraux.
L’utilisateur peut imprimer à tout moment un état de situation nette d’une valeur donnée.
3.3.6.3.7.7 Consultation de la confrontation de situation nette
A la réception des situations nettes finales du centre de compensation, le module ADT effectue
une confrontation automatique avec les situations nettes qu’il a calculées. Deux résultats sont
possibles :
- Une confrontation avec succès : le résultat de la confrontation est affiché dans une
table de comparaison affichant les soldes bilatéraux par valeur et par devise.
- Un échec de confrontation : le résultat de la confrontation est affiché dans une table

de comparaison affichant les soldes bilatéraux par valeur et par devise. La différence
est distinguée par une couleur spécifique et un message d’alerte est affiché.
3.3.6.3.7.8 Consultation des alertes de contrôle
Toutes les erreurs de contrôles sont disponibles dans des masques spécifiques.
Les informations disponibles sont :
- Date et heure de l’alerte ;
- Remise concernée (défaillante).
- Détail des erreurs de contrôle : numéro de lignes d’erreurs, codes erreurs, libellés…
3.3.6.3.8 Gestion des éditions et des statistiques
Le module ADT Administration permet la génération de plusieurs états couvrant l’ensemble des
étapes de traitement du module ADT :
- Statistiques sur les Opérations Echangées : nombre et montant total des opérations
échangées selon une période temps choisie.

Statut Ebauche
- Statistiques des valeurs traitées : nombre et montant total des opérations générées,
reçues, acquittées, réglées et rejetées par code enregistrement et par date
opération
- Statistiques Cumulées :
Le résultat peut être édité dans un état et sauvegardées sous forme électronique ou imprimés
sur papier.
3.3.6.3.9 Gestion des reprises
Deux types de reprises sont disponibles :
- Reprise de contrôle : ne concernent que les fichiers accusant une erreur de contrôle
- Reprise de génération : la reprise implique la régénération des triplets (ENV/RCP,

CAT, PAK). Les fichiers régénérés gardent le même nom que le fichier initial.
3.3.7 Description fonctionnelle du module Hannibal-PosteAdherent
Le Poste adhérent représente le premier et l’unique point d’accès au centre de compensation,

tous les échanges entre le système central et les participants se faisant via le poste adhérent.
Le Poste adhérent est le seul module d’échange de toutes les opérations avec le centre de
compensation. Ses principales fonctions sont :
- Dépôt des remises pour traitement au centre de compensation.
- Suivi des remises et opérations envoyées au centre de compensation.
- Réception des remises reçues du centre de compensation.
3.3.7.2 Fonctionnalités:
3.3.7.2.1 Gestion des droits et des autorisations d’accès :
A l’instar de l’autre module siège, ce module fournit les mêmes fonctionnalités de gestion des
 Le mot de passe doit contenir obligatoirement des majuscules et des

minuscules.
Statut Ebauche
 Le mot de passe doit contenir obligatoirement des chiffres et des lettres.
 Etc…
3.3.7.2.2 Consommation du référentiel
Le référentiel est envoyé sous forme de base de données « Access » et est automatiquement
consommé dès sa détection par le poste adhérent. Ce référentiel comporte plusieurs
éléments dont:
 le référentiel banques et agences
 le référentiel des participants
 le référentiel des valeurs (valeur à échéance, délai rejet, délai de règlement, délai
annulation, HAJE,…)
 La devise
 Le référentiel des motifs de rejet.
 Le profil de la journée de compensation.
 Les règles de contrôle des lots.
 Les règles de gestion.
 Les jours fériés.
 Etc.
Après mise à jour de son référentiel, le poste adhérent met à jour la « Date Dernier Import de
référentiel ».
3.3.7.2.3 Consommation de la date session
Les fichiers « date session » sont générés à chaque fin de journée compensation par le centre
de compensation et sont envoyés à tous les participants via le Module Autcollecte central qui
les dépose au niveau des boite aux lettres de réception des postes adhérents.
Le fichier « date session » est automatiquement consommé dès sa détection par le poste
adhérent qui effectue les opérations suivantes :
- Purge de la BAL d’envoi qui contient les lots de l’ancienne journée.
- Mise à jour de sa propre date de session.
3.3.7.2.4 Dépôt des remises interbancaires et régionales

Statut Ebauche
Les fichiers de données (ENV) et les fichiers images (CAT/PAK) générés par le CBA de la
banque doivent être manuellement déposés au niveau du module Poste Adhérent
Le module offre deux modes de dépôt des remises :
- le dépôt manuel des remises : les remises sont manuellement déposées dans
l’application à travers un menu spécifique.
- Le dépôt automatique des remises : les remises sont automatiquement chargée dans
l’application dès leur détection dans un répertoire déterminé.
Pour les valeurs à images chaque remise déposée doit être constituée d’un triplet de fichiers
ENV, CAT et PAK qui doivent être déposés ensemble au niveau du Poste-Adhérent.
- Fichier ENV : contiennent les données bancaires des remises.
- Fichiers CAT/PAK : contiennent les images et leur Index.
Pour les valeurs sans image les remises sont constituées uniquement de fichiers ENV.
L’enregistrement Global contient l’information globale de la remise comme : le code valeur, le

code enregistrement, la date de présentation, le code remettant, le nombre total, le montant
total et la devise.
L’enregistrement détail contient en plus de l’information globale, l’information spécifique à

chaque transaction comme : le nombre de transactions (nombre de chèques..) le montant, la
devise, le RIB payeur/tireur, le RIB bénéficiaire/cédant, la date d’émission, la date déchéance
(pour les prélèvements et lettres de change).
La banque va générer les fichiers selon une fréquence de génération spécifique. Donc, pour
une valeur donnée et un code enregistrement donné (présentation, rejet ou annulation)
plusieurs fichiers peuvent être déposés dans Hannibal-PosteAdherent durant la même journée
L’activation du menus de dépôt des remises interbancaires est conditionné par deux
paramètres systèmes : Heure début dépôt et Heure fin dépôt.
Ces deux horaires, fixés par le centre de compensation, sont consommés au niveau des
postes adhérents à partir du référentiel.
Lors du dépôt, l’application compare la date et heure système de la machine à ces deux
paramètres et procède comme suit :

Statut Ebauche
- Si date et heure système incluse dans [Heure début dépôt, Heure fin dépôt]  l’écran
de dépôt sera Activé.
- Sinon, l’écran de dépôt sera inhibé.
Dans le cas du dépôt automatique des fichiers, l’application compare l’horaire de dépôt (heure
système) avec ces deux paramètres horaires
- Si date et heure système incluse dans [Heure début dépôt, Heure fin dépôt]  la
remise est détectée automatiquement par l’application et est prise en charge.
- Sinon, la remise n’est pas détectée par l’application.
3.3.7.2.4.1 Contrôle des remises déposées
Lors du dépôt des remises, les contrôles suivants sont effectués :
1. Contrôle syntaxique et logique des fichiers de données ;
2. Contrôle des fichiers images ;
3. Réconciliation entre données et images correspondantes pour les chèques et lettres de

change.
4. contrôle des valeurs dupliquées
En cas de dépôt manuel, ces contrôles sont déclenchés par l’utilisateur suite à l’appui sur le
bouton « contrôler remises »
En cas de dépôt automatique, ces contrôles sont automatiquement déclenchés par l’application
dés que celle-ci détecte les remises dans le répertoire approprié.
3.3.7.2.4.2 Contrôles syntaxiques et logiques des fichiers de données (ENV)
Ce contrôle vérifie :
Les fichiers non valides seront rejetés entièrement pas Hannibal-Poste adhérent. Dans ce cas,
une alerte et le détail des erreurs est affiché et peut être édité ou sauvegardé.

Statut Ebauche
Il comprend tous les contrôles liés à la cohérence d’information liée aux « règles de contrôles»
défini au système central et consommé au niveau du référentiel.
Les fichiers non valides seront rejetés entièrement par Hannibal-Poste adhérent. Dans ce cas,
une alerte et le détail des erreurs est affiché et peut être édité ou sauvegardé.
3.3.7.2.4.3 Contrôle des doublons
Le premier niveau de contrôle se fait par rapport à la remise : Une remise déposée au niveau
du poste adhérent ne peut pas être redéposée le même jour.
Lors du dépôt de la remise, le module vérifie si elle n’a pas été déposée auparavant (et ce, en
vérifiant l’existence d’un fichier du même nom au niveau de la BAL). Dans l’affirmative, elle
sera rejetée et un message d’erreur s’affiche à l’utilisateur.
Le deuxième niveau de contrôle consiste à vérifier l’unicité des enregistrements au sein d’une
même remise.
Les fichiers non valides, ainsi que les fichiers images correspondants (s’il s’agit d’une valeur à
image) seront rejetés en totalité par le poste adhérent.
Le détail des erreurs sera affiché à l’utilisateur qui pourra les éditer, les enregistrer et les
imprimer.
3.3.7.2.4.4 Contrôle des fichiers images
Ce contrôle consiste à :
- Contrôler la validité du format du fichier. CAT : contrôle de la structure du fichier et de

son intégrité ;
- Vérifier la concordance des données contenues dans les deux fichiers index et package
(.CAT et .PAK) ;
- Contrôler la taille des images : la taille de chaque image unitaire recto + verso ne doit
pas dépasser une taille maximale paramétrable au niveau du référentiel.
- Authentifier les images par la clé publique du participant.
Lorsqu’une erreur est détectée à ce niveau, l’ensemble des trois fichiers (remise numérique,
.PAK et .CAT) est rejeté par le poste adhérent et les erreurs sont affichées.
3.3.7.2.4.5 Réconciliation entre les images et les données

Statut Ebauche
Ce contrôle est utilisé pour vérifier que les fichiers de données à images ne sont pas transmis
au centre de compensation sans image et qu’aucune image n’est transmise au centre de
En cas d’erreur détectée à ce niveau, le triplet de fichiers est rejeté affichant des erreurs.
3.3.7.2.4.6 Affichage des erreurs :
Suite aux divers contrôles décrits plus haut, le module Poste Adhérent affiche la liste des
erreurs relatives à chaque type de contrôle, pour les fichiers erronés.
Le principe des contrôles effectués fait qu’à la moindre erreur détectée, la totalité de la remise
contrôlée (et du triplet en cas de valeurs à images) est rejetée.
3.3.7.2.5 Validation du dépôt
En cas de dépôt manuel, Lorsque le ou les fichiers contrôlés ne révèlent aucune erreur, le
Poste Adhérent affiche les sous totaux par participant destinataire et demande la validation du
dépôt de la remise par l’opérateur.
Lorsque la remise à déposer au niveau du poste adhérent est relative à une valeur à image
(chèque, lettre de change), l’opération de contrôle, de dépôt et d’envoi à la compensation
s’effectue par triplet de fichiers : le fichier de données .ENV et les fichiers .PAK et .CAT
correspondants. Ceci permet d’éviter qu’une remise parvienne au système sans les images
correspondant et vice versa.
Ainsi, lors de la confirmation de l’opération de dépôt et après cryptage des fichiers le triplet de
fichiers est zippé en un seul fichier dans le répertoire d’envoi.
En cas de dépôt automatique, aucune validation par l’utilisateur n’est requise.
Lors du dépôt des remises, la date de règlement sera calculée en fonction du moyen de
paiement et de la date et heure de dépôt effectuée. Si l’haje est atteinte, la date de règlement
de la remise sera incrémentée d’un (1) jour.
Les remises déposées seront automatiquement déplacées du répertoire « dépôt de remises » à

« remises déposées ».
3.3.7.2.6 Signature et cryptage des données et images
Une fois que les fichiers ont été contrôlées avec succès, Les images sont signées
électroniquement par la clé privée de la banque et toute la remise est cryptée par la clé

Statut Ebauche
publique du centre de compensation (et ensuite compressée pour les valeurs à images) avant
d’être copiées dans la BAL Out (Répertoire d’envoi) du poste Adhèrent.
Le cryptage est effectué pour les données et images contrôlées avec succès.
3.3.7.2.7 III.4.2.8 Consultation des lots reçus de la compensation
Les remises retour du centre de compensation sont reçues au niveau du Poste-Adhérent pour
les traitements au siège.
Les fichiers sens 1 et 2 incluent 3 fichiers différents (données, index et image) compressés
dans un seul fichier pour les valeurs à image. Pour les valeurs sans image, un seul fichier non
compressé est envoyé et reçu.
Les remises retours relatives aux différentes valeurs traitées (virements, prélèvements,
chèques, effets) peuvent être dénombrées comme suit :
- Remises de présentation/représentation reçues.
- Remises d’annulation de présentation/représentation.
- Remises de rejets reçus.
- Remises d’annulation de rejets reçus.
Pour les valeurs à image (chèques et effets), les remises retours sont constituées par des
triplets de fichiers (données, index et image) alors que pour les valeurs sans image
(virements, prélèvements) les remises reçues sont constituées uniquement par des fichiers de
données.
Le centre de compensation envoie également les rejets et alertes suivants en cours de

journée:
- Rejets règlementaires (.RJT) du centre de compensation : délai dépassé, opération non

autorisée.
- Rejets techniques du centre de compensation : remise non valide, erreur de structure.
- Alertes sur dépassement de limite débitrice du participant (.ALR).
- Messages d’information et messages non financiers.
Les résultats de compensation sont constitués de :
Résultats intermédiaires

Statut Ebauche
 Situations nettes intermédiaires (.SNI) : Intègrent par participant et pour chaque valeur
et devise, les situations nettes calculées depuis le début de la journée/session jusqu’au
moment de génération de celles ci;
 Situations nettes intermédiaires globales par valeur (.SIV) : Intègrent, par participant,
pour chaque famille de valeur (les présentations et les représentations confondues) et
pour chaque devise, les situations nettes calculées depuis le début de la
journée/session jusqu’au moment de génération de celles-ci;
 Situation nette intermédiaire globale (.SIG) : Intègrent, par participant, par devise et

pour toutes les valeurs confondues, les situations nettes calculées depuis le début de la
journée/session jusqu’au moment de sa génération.
Résultats de la journée
 Situations nettes définitives (.SND) : Intègrent par participant et pour chaque valeur,
les soldes bilatéraux comprenant toutes les opérations de la journée et le solde net de
la journée par participant;
 Situations définitives globales par valeur (.SDV) : Intègrent par participant, par devise
et pour chaque famille de valeur (les présentations et les représentations confondues),
les soldes bilatéraux comprenant toutes les opérations de la journée et le solde net de
la journée;
 Situation nette globale de fin de journée (.SNG) : Intègrent par participant, par devise
et pour toutes les valeurs confondues, les soldes bilatéraux comprenant toutes les
opérations de la journée et le solde net global de la journée;
 Echéancier de règlement (.ECH) : En considérant le moyen de payement et le délai de

règlement, le système établit un programme de règlement pour les participants pour la
journée en cours (Solde net à régler) et les N jours de travail suivants (N 2tant le délai
maximal de règlement définit dans le système)
 Les fichiers de facturation (.FCT) : ce sont des fichiers générés automatiquement à la

fin de chaque période de facturation par le centre de compensation et transmis aux
participants avec leurs résultats de compensation ;
 Les comptes rendus de fin de session par devise (.CRS) et de fin de journée par devise
(.CPR);
 Les comptes rendus d’opérations par valeur et par devise.
3.3.7.2.8 Récupération des résultats de la compensation

Statut Ebauche
Tous les résultats de la compensation reçus au niveau du poste adhérent peuvent être
récupérés dans un répertoire défini afin d’être exploités par l’interface du CBA.
Le module offre deux méthodes de récupération :
- la récupération manuelle initiée par l’utilisateur.
- La récupération automatique lancée automatiquement dès la détection des remises en

provenance du centre de compensation.
Lors de cette récupération les opérations suivantes sont effectuées :
- Décryptage des fichiers reçus par la clé privée du participant,
- Authentification des lots à images par la clé publique du centre de

compensation.
- Décompressions les triplets de fichiers relatifs aux valeurs à images.
3.3.7.2.9 Edition des résultats de la compensation
3.3.7.2.9.1 Edition des remises reçues
Toutes les remises reçues de la compensation peuvent être éditées au niveau du poste
adhérent.
3.3.7.2.9.2 Edition des situations nettes
La consultation des fichiers reçus permet la consultation des résultats issus du centre de
compensation selon plusieurs critères.
L’édition des situations nettes permet à l’utilisateur de connaître par code devise:
- Le total crédit de sa banque.
- Le total débit de sa banque.
- Le solde de la banque : créditeur ou bien débiteur
La situation nette peut être éditée et sauvegardée sous format électronique ou bien imprimée
sur papier.
3.3.7.2.9.3 Edition des factures
De la même manière que les situations nettes, les fichiers factures reçus à chaque fin de
période de facturation peuvent être consultés et édités.

Statut Ebauche
3.3.7.2.10 Suivi opérationnel des traitements
3.3.7.2.10.1 Consultation des lots envoyés
Cet écran constitue, pour le participant, un tableau de bord de suivi des statuts des remises
qu’il a envoyées au système central. Il affiche les informations suivantes :
 La liste de toutes les remises déposées ;
 L’heure de collecte est affichée en face de la remise dès qu’elle est récupérée par le
module d’Autocollecte.
 Le statut de la remise.
La liste des remises envoyées ainsi que ses détails peuvent être imprimés ou sauvegardés.
3.3.7.2.10.2 Consultation des comptes rendus
A la fin de la journée, et en fin de session en cas de multi-sessions, le système retourne un

compte rendu de traitement aux participants remettants, portant sur les traitements effectués
sur leurs remises. Une fois reçus dans la boîte aux lettres de réception, ces comptes rendus
sont consultables à partir du poste adhérent.
Les informations affichées concernent les remises envoyées uniquement. Il s’agit, pour chaque
remise de :
- L’identifiant de la remise ;
- La devise de la remise ;
- Date et heure d’arrivée ;
- Date et heure de début et de fin de traitements ;
- Date de règlement appliquée ;
- Date de présentation appliquée ;
- L’état de contrôle de la remise : contrôlée acceptée ou contrôlée rejetée ou

annulée ;
- Le nombre et le montant total des opérations acceptées dans la remise ;
- Le nombre et le montant total des opérations rejetées dans la remise ;
Les comptes rendus peuvent être édités et sauvegardées sous format électronique ou bien
imprimés sur papier.
3.3.7.2.10.3 Consultation des alertes

Statut Ebauche
Le participant peut consulter les alertes du jour qui lui sont adressées du système central.
3.3.7.2.10.4 Consultation des messages du jour
Le participant peut consulter tous les messages non financiers du jour qui lui sont envoyés par
le centre de compensation (messages d’information) ou par les autres participants (messages
libres). Les informations affichées au niveau de cet écran sont les suivantes :
 Nom du fichier ;
 Type de message : Les messages non financiers sont de deux types :
1. Messages d’information systèmes : relatifs à la suspension ou à l’exclusion de

participants ;
2. Messages libres: ce sont les messages libres reçus des autres participants ;
Un bouton de consultation est disponible permettant la consultation et l’impression du

message.
3.3.7.2.11 Gestion des clés
3.3.7.2.11.1 Consommation des clés
Les règles de consommation de la clé sont les suivantes :
 La clé est consommée définitivement lors du contrôle et du dépôt du premier lot à

images de la journée ;
 Cette clé consommée doit satisfaire les conditions suivantes :
 Elle doit être en cours de validité ;
 Dans le cas où il y aurait plusieurs clés valides, la clé consommée doit être
la plus récente.
3.3.7.2.11.2 Chargement manuel des clés
Lorsque le poste adhérent se trouve exceptionnellement isolé (du point de vue télécoms) et
que la clé de la banque, lui servant pour la signature des images ne lui est pas parvenue, il est
possible de procéder au chargement manuel de ladite clé.
Lors du chargement manuel d’une clé, deux cas sont possibles :
 Si la consommation d’une clé n’a pas encore eu lieu alors :

Statut Ebauche
 1er cas : la clé chargée manuellement est valide et est plus récente que la
dernière clé générée valide dans la base : C’est la clé chargée
manuellement qui sera consommée ;
 2ème cas : la clé chargée manuellement est valide et est moins récente que
la dernière clé générée valide dans la base : alors c’est la clé la plus
récente qui est consommée (et non celle chargée manuellement) ;
 Si la consommation d’une clé a déjà eu lieu dans la même journée: la clé chargée
manuellement ne peut plus être consommée pour ce jour.
3.3.7.2.11.3 Transfert des clés
Hannibal Poste-Adhérent s’occupe du transfert des clés entre le participant et le centre de

compensation :
- Transfert de la clé publique du centre de compensation vers le module Générateur

des Clés du siège ;
- Transfert de la clé banque vers le centre de compensation.
Quand Hannibal Poste-Adhérent transfère la clé du participant pour le centre de compensation,

un acquittement doit s’envoyer en retour attestant la bonne réception de la clé.
3.3.7.2.11.4 Consultation des clés
Ce menu permet de consulter les clés du participant. Les informations affichées sur les clés
sont :
- Référence de la clé
- Taille de la clé
- Date de génération, date de début de validité, date fin de validité, statut (nouvelle,
courante, annulée, archivée).
3.3.7.2.11.5 Consultation des messages SSL
Ce menu permet la consultation de tous les messages SSL relatifs aux transferts des clés,
acquittements et certificats.
Les informations affichées sont :
- référence message
- type message : clé, acquittement
- envoyeur/receveur.
Statut Ebauche
- Nombre de tentatives.
- Statuts.
Ce masque permet la retransmission manuelle des échecs d’envoi.
3.3.7.2.12 Utilisation par un participant indirect
Les participants indirects doivent utiliser la plateforme de leur participant direct pour déposer
et récupérer leurs remises.
3.3.7.2.13 III.4.2.14 Affichage des évènements
Hannibal-PosteAdherent peut retracer toutes les opérations effectuées par l’application ainsi
que la date et l’heure de ces opérations et l’utilisateur qui les a effectués.

Statut Ebauche
4 PLANNING DE MISE EN ŒUVRE
Le planning prévisionnel de mise en œuvre en Guinée se présente comme suit :
Tache Début Fin
DEPLOIEMENT DE LA GUINEE 17/10/2013 03/06/2014
LIVRAISON EQUIPEMENTS ET INSTALLATIONS 17/10/2013 20/12/2013
Livraisons des équipements 17/10/2013 15/11/2013
Installation des équipements et tests (site principal et 18/11/2013 20/12/2013

backup)
11/11/2013 13/12/2013
FORMATION
Formation fonctionnelle des techniciens des banques 11/11/2013 15/11/2013
Formation technique des techniciens des banques 18/11/2013 03/12/2013
Formation fonctionnelle des utilisateurs des banques 18/11/2013 29/11/2013
Formation fonctionnelle des techniciens de la BCRG (ACH) 02/12/2013 06/12/2013
Formation technique des techniciens de la banque centrale 09/12/2013 13/12/2013
Formation fonctionnelle des utilisateurs de la banque

02/12/2013 13/12/2013
centrale
DEPLOIEMENT 16/12/2013 20/12/2013
Plan de déploiement 16/12/2013 20/12/2013
Installation du système sur matériel cible 16/12/2013 20/12/2013
Déploiement 18/12/2013 20/12/2013
TESTS SUR SITE PILOTE
Tests sur site pilote Généralisé 20/01/2014 07/02/2014
Tests en parallel run 10/02/2014 28/02/2014
Démarrage en réel du système (GO-LIVE) 03/03/2014 03/03/2014
Assistance 3 mois 03/03/2014 03/06/2014
Réception provisoire et début de la garantie 03/06/2014 03/06/2014

Statut Ebauche
5 PRE-REQUIS À LA MISE EN PLACE DU SYSTÈME
Pour participer aux échanges du système de Télécompensation, les institutions participantes
seront amenées à :
- se conformer aux nouvelles normes du système (codification des valeurs, des

opérations, des motifs rejet, nouvelle ligne MICR, etc..).
- respecter les règles d’échange du système (horaires des échanges, règles de

contrôle des remises, etc.).
- fournir les remises à présenter en compensation (virements et prélèvements).
- prendre en charge des remises chèques et effets envoyées en compensation afin de

les intégrer au niveau du CBS.
- prendre en charge des remises reçues de la compensation.
- améliorer le réseau
- Sécurité (réseau, accès aux salles, etc...).
5.1 NORMES DES CHÈQUES ET DES EFFETS

5.1.1 Format physique des chèques et grammage
Les nouvelles formules de chèques doivent respecter les caractéristiques suivantes :
Types Cheque Grand format

Cheque / Cheque
Remplissage Remplissage
dimension Petit format
automatique
s Manuel
67/8 pouces 67/8 pouces 81/4 pouces

Longueur
174.6 mm 174.6 mm 210 mm
27/8 pouces 37/8 pouces 37/8 pouces

Hauteur
73 mm 99 mm 99 mm
Tolérance: ± 1/16 pouce (1.6 mm) verticalement et ± 1/20 pouce (1.3 mm) horizontalement.

Statut Ebauche
5.1.2 Structure de la ligne MICR des Chèques
La structure de la nouvelle ligne MICR (E13B/CMC7) est la suivante :
Position longueur Description

Ordre Libellé
début
1 Numéro de chèque 2 08
2 Code Pays tiré 11 02 01 (GM) /05 (SL) / 03 (GN)
3 Code Banque tiré 13 03
4 Code état 16 02
5 Code Agence tiré 18 03
6 Numéro de Compte tiré 22 10
Modulo97 : inclue le code

7 Clé Contrôle Compte tiré 32 02 banque, code agence et le
numéro de compte.
01 : cheque personnel
8 Code transaction 35 02 02 : cheque d’entreprise
03 : Chèque de Banque
270 (GM) /694 (SL) / 324 (GN)

9 code devise 37 03
/430 (LR)
Modulo97 inclue tous les

10 Clé de contrôle MICR 40 02 caractères de la ligne MICR
(35 caractères)
Total 37

Statut Ebauche
5.1.3 Formatage de la ligne MICR E13B/CMC7
E13B
CMC7
E13B CMC7
Transit symbol
Séparateur SIV
(Symbol10)
Amount symbol
Séparateur SI
Symbol11)
On-Us symbol
Séparateur SIII
(Symbol12)
Dash symbol
Séparateur SII
(Symbol13)
5.1.3.1 E13B
Les positions sont calculées de gauche à droite :
Position Longueur Description

Ordre Libellé
début
Symbol12/
1 01
ZONE1 On-Us symbol
Numéro de chèque 2 08
ZONE2 Symbol12/
10 01
On-Us symbol
01 (GM) /05 (SL) / 03 (GN) / 06

Code Pays tiré 11 02
(LR)
Code Banque tiré 13 03

Statut Ebauche
Code état 16 02
Code Agence tiré 18 03
Symbol10 /
21 01
Transit symbol
ZONE3 Numéro de Compte tiré 22 10

Clé Contrôle Compte tiré 32 02 banque, code agence et le
numéro de compte.
Symbol12/
34 01
On-Us symbol
Code transaction 35 02 02 : cheque d’entreprise
ZONE4 03 : Chèque de Banque
270 (GM) /694 (SL) / 324 (GN) /

code devise 37 03
430 (LR)

Clé de contrôle MICR 40 02 caractères de la ligne MICR (35
caractères)
Symbol11/
42 01
Amount symbol
Total avec séparateurs 43
Total sans séparateurs 37
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 41 42 43
08 02 03 02 03 10 02 02 03 02
Transa
S S Coutry State Branch S Accpt S Currency MICR S
Cheque Number Bank code Account number ction
12 12 code code code 10 check 12 code check 12
code
digit Digit
5.1.3.2 CMC7
Les positions sont calculées de gauche à droite :

Statut Ebauche
Position longueur Description
Ordre Libellé
début
Séparateur SIII 1 01
ZONE1
Numéro de chèque 2 08
01 (GM) /05 (SL) / 03

Code Pays tiré 11 02
(GN)/ 06 (LR)
ZONE2
Code Banque tiré 13 03
Code état 16 02
Code Agence tiré 18 03
Séparateur SIV 21 01
Numéro de Compte tiré 22 10

ZONE3
Clé Contrôle Compte tiré 32 02 banque, code agence et le
numéro de compte.
Code transaction 35 02 02 : cheque d’entreprise
03 : Chèque de Banque
ZONE4
270 (GM) /694 (SL) / 324
code devise 37 03
(GN) /430 (LR)

Clé de contrôle MICR 40 02 caractères de la ligne
MICR (35 caractères)
Séparateur SI 42 01
Total avec séparateurs 43
Total sans séparateurs 37
5.1.4 Normes des Effets
5.1.4.1 Format physique des effets et grammage
Les nouvelles dimensions des effet doivent respecter les caractéristiques suivantes :

Statut Ebauche
dimensions Format des Effets
Longueur 67/8 pouces - 174.6 mm
Hauteur 37/8 pouces - 99 mm
Tolérance: ± 1/16 pouce (1.6 mm) verticalement et ± 1/20 pouce (1.3 mm) horizontalement.
5.2 FORMAT DES RIB

Les RIB sont codifiés sur 18 positions comportant :
Ordre Champs Longueur Type Remarque
1 Le code banque 3 Numérique Compléter avec des 0 à gauche
2 Le code Agence (guichet) 3 Numérique Compléter avec des 0 à gauche
Numéro de compte
10 Numérique Compléter avec des 0 à gauche
3 interne du client
4 Clé RIB 2 Numérique -
Total 18
5.3 CLÉS DE CONTRÔLE (MODULO 97)

5.3.1 Clé de contrôle du compte (Modulo97)
5.3.1.1 Calcul de la clé de contrôle du compte
L’ensemble constitué dans l’ordre par le code banque, le code agence et le numéro de compte
forme un nombre N de 16 chiffres.
Multiplier N par 100 = N’

Diviser N’ par 97
Le reste de la division euclidienne par 97 (modulo 97) peut prendre des valeurs comprises
entre 00 et 96.
Le résultat de la soustraction du reste de cette division du nombre 97 (égal à 97 – (N’ mod

97)) représente la clé de contrôle du compte (sur 2 positions).
Cette clé ne peut donc prendre que des valeurs comprises entre 01 et 97.
Exemple:
Code Code agence Numéro de Clé de contrôle RIB (*)

Statut Ebauche
Banque compte
001 001 0000000111 57
N = 0010010000000111
N’= 001001000000011100
Le reste de la division euclidienne de N’ par 97 (mod 97) = MOD (001001000000011100; 97)

= 40
(*) Clé de contrôle du compte = 97-40 = 5
RIB = 001001000000011157
5.3.1.2 Vérification de la clé du compte (Clé RIB)
L’ensemble constitué dans l’ordre par le code banque, le code agence, le numéro de compte et
la clé de contrôle forme un nombre N de 18 chiffres.
Le reste de la division de N par 97 est égal à 0.
MOD ('001001000000011157'; 97) =0
5.3.2 Clé de contrôle MICR (Modulo97)

La clé MICR est une clé de contrôle « modulo 97 » sur toute la ligne MICR.
Cette clé permet de vérifier la saisie de toute la ligne MICR en cas de correction manuelle de
celle-ci.
5.3.2.1 Calcul de la clé de contrôle MICR
L’ensemble constitué dans l’ordre par le numéro de chèque, le code pays, le code banque, le
code état, le code agence, le numéro de compte, la clé de contrôle du compte, le code
transaction, et le code devise forment un nombre N de 35 chiffres.
Multiplier N par 100 = N’

Diviser N’ par 97
Le reste de la division euclidienne par 97 (modulo 97) peut prendre des valeurs comprises
entre 00 et 96.
Le résultat de la soustraction du reste de cette division du nombre 97 (égal à 97 – (N’ mod

97)) représente la clé de contrôle MICR (sur 2 positions).
Cette clé ne peut donc prendre que des valeurs comprises entre 01 et 97.
Exemple:
Statut Ebauche
Numéro Code Code Code Code Numéro de Clé de code Code Clé de
de banque état agence compte contrôle Transaction devise contrôle
Pays
Cheque du MICR
compte (*)
01234567 01 001 01 001 0000000111 57 01 270 53
01234567 03 001 01 001 0000000333 70 01 324 47
01234567 05 001 01 001 0000000555 83 01 694 63
N = 01234567010010100100000001115701270
N’= 0123456701001010010000000111570127000
Le reste de la division euclidienne de N’ par 97 (mod 97) = MOD

(1234567801001010010000000111570127000; 97) = 44
(*) clé de contrôle MICR = 97-44 = 53
MICR = 0123456701001010010000000111570127053
5.3.2.2 Vérification de la clé de contrôle MICR
L’ensemble constitué dans l’ordre par le numéro de chèque, le code pays, le code banque, le
code état, le code agence, le numéro de compte, la clé de contrôle du compte, le code
transaction, le code devise et la clé MICR forment un nombre N de 37 chiffres.
Le reste de la division de N par 97 est égal à 0.
MOD ('0123456701001010010000000111570127053'; 97) =0

Statut Ebauche
5.4 GESTION DES ÉCHANGES
5.4.1 Formats d’Echange
5.4.1.1 Echange des remises
5.4.1.1.1 Nommage des remises
Les différents participants au système ACP/ACH vont échanger entre eux des fichiers
informatiques nommés « remises » et structurés selon des formats prédéfinis et obéissant à
des règles de contrôle spécifiques.
Les remises échangées concernent :
- Des valeurs à image : les chèques et les lettres de change.
- Des valeurs sans images : les virements, les prélèvements.
Pour les valeurs à images chaque remise déposée doit être constituée d’un triplet de fichiers
ENV, CAT et PAK qui doivent être déposés ensemble au niveau de la plateforme participant.
- Fichier ENV : contiennent les données bancaires des remises.
- Fichiers CAT/PAK contiennent les images et leur Index.
Pour les valeurs sans image les remises sont constituées uniquement de fichiers ENV.
Ces remises doivent être déposées au niveau du module Hannibal PosteAdherent pendant la
plage horaire de dépôt autorisée.
Après traitement, le centre de compensation génère des remises retours vers les participants
destinataires.
Pour les valeurs à images chaque remise reçue est constituée d’un triplet de fichiers RCP, CAT
et PAK qui sont reçus ensemble au niveau de la plateforme participant.
- Fichier RCP : contiennent les données bancaires des remises reçues (même
structure que les fichiers ENV).
- Fichiers CAT/PAK contiennent les images reçues et leur Index.
Pour les valeurs sans image les remises reçues sont constituées uniquement de fichiers RCP
(même structure que les fichiers ENV).

Statut Ebauche
Exemple de remises:
- Remise interbancaire de valeur à image : le chèque
- 01-GM-XXX-21012009-141510-30-21-450.ENV
- 01-GM-XXX-21012009-141510-30-21-450.CAT
- 01-GM-XXX-21012009-141510-30-21-450.PAK
- Remise interbancaire de valeur sans image : le Virement
- 01-GM-XXX-22012009-113000-10-21-450.ENV.
- Remise intrabancaire de valeur à image : le chèque
- 00-GM-XXX-21012009-141510-30-21-450.ENV
- 00-GM-XXX-21012009-141510-30-21-450.CAT
- 00-GM-XXX-21012009-141510-30-21-450.PAK
- Remise intrabancaire de valeur sans image : le Virement
- 00-GM-XXX-22012009-113000-10-21-450.ENV
5.4.1.1.2 Constitution des remises
Les remises contiennent la totalité des opérations que présente un participant, par valeur et
par code enregistrement.
Chaque participant peut présenter un nombre illimité de remises d’une même valeur et d’un
même code enregistrement pendant la journée de compensation.
Les données figurant dans les différentes remises doivent être conformes au référentiel déclaré
au niveau de l’ACH de chaque pays (les codes banque et agences, motifs de rejet, code
valeurs, etc.).
Chaque fichier ENV/RCP est constitué d’un enregistrement global et d’un ou plusieurs
enregistrements détails.
 l’enregistrement global contient les données globales de la remise tel que : le code
valeur, code enregistrement, date de présentation, code participant remettant, nombre
total, montant total
 Les enregistrements détail contiennent en plus des données globales, des données
spécifiques à chaque opération présentée par la banque tel que : le numéro de
l’opération (numéro chèque, numéro virement, etc..) et son montant, le RIB
payeur/tireur/donneur d’ordre, le RIB bénéficiaire/cédant, Date d’émission, date
d’échéance (pour les prélèvements et les effets), etc.
Les structures des fichiers par valeur sont détaillées en annexe

Statut Ebauche
Exemple de fichier ENV : 30-21
La banque génèrera ces fichiers selon la fréquence qu’elle jugera adéquate par rapport à la
volumétrie des opérations à présenter. Ainsi, pour un code valeur donné et une nature
d’opération donnée (i.e. présentation, rejet ou annulation) plusieurs fichiers peuvent être
déposés dans Hannibal-Poste Adhérent au cours d’une même journée.
5.4.2 Contrôle des fichiers
5.4.2.1 Contrôle des fichiers ENV/DATA
Les contrôles effectués sur les fichiers ENV/DATA sont de trois types :
 Authentification : L’authentification permet de vérifier que les données n’ont pas été
altérées ou modifiées depuis leur création jusqu'à leur dépôt au niveau de la plateforme
participant.
 Contrôles syntaxiques : contrôles liés aux formats des remises, contrôle de la structure
des enregistrements, contrôle de leur complétude et contrôle des types de champs.
• Exemple : existence d’une valeur numérique dans des champs numériques, date
dans un champ date.
 Contrôles logiques : contrôles liés à la présence des informations obligatoires, au

contenu bancaire des opérations et de leur cohérence.
• Exemple :

Statut Ebauche
• conformité des données au référentiel (référentiel banque et agence,
motifs de rejet, etc.),
• clé RIB doit être correcte,
• conformité nombre et montant de la ligne globale avec la somme des

ligne détail en nombre et montant, etc..
Les contrôles syntaxiques et logiques sont effectués en premier lieu au niveau d’Hannibal-
PosteAdherent puis seront effectués encore au niveau du centre de compensation. Les erreurs
de contrôle syntaxiques et logiques entraînent un rejet intégral de la remise (ENV, CAT et PAK)
au niveau de la plateforme participant.
 Contrôle sur les doublons : permet de vérifier qu’aucun autre enregistrement ayant le
même identifiant n’a été déjà traité par l’application (même jour ou jour antérieur).
 Contrôles règlementaires : contrôles liés au respect des obligations règlementaires par

les participants et dont certains font appel à l’historique au niveau de la base de
données.
• Exemples :
 Existence d’une présentation initiale en cas de représentation,
 Existence d’une valeur déjà reçue en cas de rejet.
 Existence d’une valeur déjà envoyée en cas d’annulation.
 Rejet tardif si dépassement du délai de rejet autorisé, etc.…
 Annulation tardive si dépassement du délai d’annulation autorisé, etc.…
 Etc.
Les erreurs de contrôle règlementaires entraînent le rejet unitaire des opérations contrôlées
avec échec au niveau du centre de compensation. Le rejet est immédiatement véhiculé vers la
banque remettante.
5.4.2.2 Contrôle de régularité des fichiers Images CAT/PAK
 Authentification des images : L’authentification permet de vérifier que les images n’ont
pas été altérées ou modifiées depuis leur création jusqu'à leur dépôt au niveau de la
plateforme participant.
 Contrôle de conformité: vérification de la conformité entre les Index et les images

(CAT / PAK).

Statut Ebauche
 Réconciliation : La réconciliation permet de vérifier que toute image au niveau des
fichiers CAT/PAK est accompagnée de l’enregistrement correspondant au niveau du
fichier ENV et inversement.
Les contrôles de régularité des images sont effectués en premier lieu au niveau de Hannibal-
Poste Adhérent puis seront effectués encore au niveau du centre de compensation. Les erreurs
de contrôle de régularité des images entraînent un rejet intégral de la remise (ENV, CAT et
PAK) au niveau de la plateforme participant.

Statut Ebauche
5.5 EQUIPEMENTS
5.5.1 Équipements fournis par les Banques Centrales
La plateforme participant au niveau du siège est fournie par la Banque Central de chaque pays
et est composé d’un serveur et d’un poste de travail (PC).
Equipements techniques des

Participant
Vers le centre de compensation

Principal and Backup
WAN
LAN Participant
Poste de travail
SERVEUR Poste
ADT Adherent
La configuration de la plateforme participant est la suivante :

5.5.1.1 Configuration du Serveur ADT
Le serveur ADT et Oracle est un serveur IBM x3200 M3 server:
 1 x processor Xeon X3320 2,66 GHz Quad Core.

 4 Gb de RAM
 4 SAS disques de146 Gb en RAID 5
 2 contrôleurs Ethernet
 17" Lenovo écran plat L174
 Windows 2008 server standard
 ORACLE 11G Database Standard Edition.
 Modules BFI : Hannibal-ADT, Hannibal-ADTAdmin, Hannibal-Autocollecte et
Barberousse Générateur des clés

Statut Ebauche
5.5.1.2 Configuration des postes de travail des participants
Les postes de travail sont des Lenovo ThinkCentre A58 SFF:
 Intel Pentium Dual-Core processor 2.60GHz

 2 GB de RAM
 Disques de 360GB avec deux partitions
 Ecran LENOVO Thikvision L197 wide 19''
 Graveur DVD
 Windows 7 Professionnel 32bits
 Modules BFI: Hannibal Poste Adhérent
5.5.2 Equipements à acquérir par les Participants

Le périmètre du projet n’inclut pas les équipements des agences. Les postes de travail et les
scanners qui seront utilisés par les agences doivent être acquis par les banques
Toutefois, les licences BFI des modules agences sont fournies pour toutes les institutions
participantes.
Modules BFI : Barberousse-Capture, Barberousse-GenerateurCles, Braberousse-GIP.
5.5.2.1 Postes de travail des agences

La configuration minimale recommandée des postes de travail des agences est la suivante :
 Processor Intel Dual Core 2,0 GHz

 Mémoire : 2GB de RAM
 80GB disques durs (avec deux partitions C et D : C= système et D:data)
 Carte Ethernet 10/100 Mb
 USB 2.0 (connexion demandée pour les scanners LS100)
 Graveur DVD
 Ecran 17''
 Windows 7 professionnel (32 bits )
 MS-Office 2003 ou 2007
5.5.2.2 Scanners
Les Scanner proposés dans le cadre de ce projet est le CTS-LS100.
Le scanner LS100 est un modèle de la marque CTS ayant toutes les fonctionnalités de
scannérisation requises. Les principales caractéristiques sont:
 Vitesse: 60 doc/minute
 Bac d’alimentation Automatique (100 documents)

Statut Ebauche
 1 Bac de sortie
 Caméra Recto/verso
 MICR : lecteur CMC7 et E13B
 Reconnaissance OCR
 Imprimante jet d’encre intégrée
 résolution Image : 100 et 200 dpi
 niveau de gris : 16, 256 and RGB Couleur
 format Images : DIB, BMP, JPEG et TIFF
 connexion USB 2.0 (compatible USB1.1)
La Banque Centrale de chaque pays sera en charge de la collecte du nombre estimé de

scanners qui sera acquis par chaque participant. Cette estimation devra tenir compte de
scanners de rechange pour chaque banque.
5.6 RÉSEAU
Les pré-requis réseaux principaux sont les suivants
- Utilisation d’un Switch qui supporte un VLAN dédié à la plateforme particpant.
- Le réseau doit permettre un minimum de 100Mb de LAN entre les machines locales de
la plateforme participant.
- Le réseau doit permettre la connexion de la plateforme participant au réseau du centre

de compensation.
- Le réseau doit permettre la connexion de la plateforme participant au réseau interne de

la banque (liaison entre le siège et les agences)
5.7 SÉCURITÉ
5.7.1 Sécurité d’Accès physique
Tous les équipements listés plus hauts doivent être installés dans des locaux sécurisés.il est
recommandé pour un périmètre sécurisé des locaux de :
- Être protégé contre les personnes non autorisées. Une seule porte doit donner
accès à la salle des machines et des autorisations d’accès doivent être données
par le responsable de sécurité.
- Disposer d’un système d’accès utilisant des cartes, des badges ou biométriques
gérés par une application de contrôle dédiée;
- Disposer d’un système de surveillance par caméra;

Statut Ebauche
- Etre protégés contre le feu : les portes doivent être anti-Feu et des détecteurs
et alarmes doivent être mis en place;
- Etre dans un environnement à température contrôlée : 18° à 21°
- Avoir une source électrique permanente et sécurisée pour les équipements
5.7.2 Sécurité Réseau

Afin d’éviter les intrusions au système et de le protéger contre toute tentative d’accès par une
personne non autorisée, il est recommandé de :
- Subdiviser le réseau en groupes de DMZ afin de protéger les serveurs et les

sources de données par l’utilisation de pare-feux (contrôle de toutes les
connexions entrantes et sortantes)
- Utilisation de matériels de détections d’intrusions sur le réseau
- Utilisations de logiciels de détections d’intrusions sur les serveurs de production

afin de stopper toutes les tentatives d’accès
- Mise en place d’un antivirus au niveau des serveurs et des postes de travail.
5.8 INTERFAÇAGE ENTRE ACP/ACH ET LE SYSTÈME D’INFORMATION DE

LA BANQUE (CBS)
5.8.1 Génération des fichiers ENV de virements

Les fichiers ENV de virements émis doivent être générés par le CBS de la banque vers le
système ACP/ACH selon la structure décrite au niveau des annexes du présent document.
5.8.1.1 Présentations de virements (code enregistrement 21)
Les présentations émises de virements représentent les ordres de transferts déposés par les
clients de la banque à destination de clients d’autres banques.
5.8.1.2 Annulations de présentations de virements (code enregistrement

23)
L’annulation de présentation du virement ne peut être générée que par le remettant de la

présentation initiale. Quand un participant envoie par erreur une opération de présentation
erronée au système ACP / ACH, il peut l'annuler en créant et générant une opération
d'annulation de présentation.

Statut Ebauche
L'opération d'annulation de présentation doit contenir les mêmes informations que la
présentation concernée. (Cf. Contrôles réglementaires du document « ACP-ACH Contrôles
logiques et réglementaires WAMI_FR_V1.0.1.doc »).
5.8.1.3 Rejets de virements (code enregistrement 22)
Lorsqu'un participant reçoit une présentation de virement de l'ACP / ACH et détecte qu'il y a un
problème et qu’elle ne peut pas être acceptée (bénéficiaire incorrect, compte fermé ...), il
peut la rejeter dans le système et la retourner à la banque rémittente.

Le rejet est effectué par le bénéficiaire de la présentation par la création et la génération d'une
opération de rejet (fichier ENV) à destination de la banque remettante initiale.
L'opération de rejet doit contenir le même identifiant et détails de l’opération de présentation
initiale. (Cf. Contrôles réglementaires du document « ACP-ACH Contrôles logiques et
réglementaires WAMI_FR_V1.0.1.doc »).
5.8.1.4 Annulations de rejets de virements (code enregistrement 24)
L’annulation de rejet du virement ne peut être générée que par le remettant du rejet initial.
Quand un participant envoie par erreur une opération de rejet erronée au système ACP / ACH,
il peut l'annuler en créant et générant une opération d'annulation de rejet.
L'opération d'annulation de rejet doit contenir les mêmes informations que le rejet concerné.
(Cf. Contrôles réglementaires du document « ACP-ACH Contrôles logiques et réglementaires
WAMI_FR_V1.0.1.doc »).
5.8.2 Génération des fichiers ENV de prélèvements

Les fichiers ENV de prélèvements émis doivent être générés par le CBS de la banque vers le
système ACP/ACH selon la structure décrite au niveau des annexes du présent document.
5.8.2.1 Présentations de prélèvements (code enregistrement 21)
Les présentations émises de prélèvements représentent les ordres de prélèvements déposés

par les clients de la banque à destination de clients d’autres banques.

Statut Ebauche
5.8.2.2 Annulations de présentations de prélèvements (code
enregistrement 23)
L’annulation de présentation du prélèvement ne peut être générée que par le remettant de la

présentation initiale. Quand un participant envoie par erreur une opération de présentation
erronée au système ACP / ACH, il peut l'annuler en créant et générant une opération
d'annulation de présentation.
L'opération d'annulation de présentation doit contenir les mêmes informations que la
présentation concernée. (Cf. Contrôles réglementaires du document « ACP-ACH Contrôles
logiques et réglementaires WAMI_FR_V1.0.1.doc »).
5.8.2.3 Rejets de prélèvements (code enregistrement 22)
Lorsqu'un participant reçoit une présentation de prélèvement de l'ACP / ACH et détecte qu'il y
a un problème et qu’elle ne peut pas être acceptée (bénéficiaire incorrect, compte fermé ...),
il peut la rejeter dans le système et la retourner à la banque rémittente.

Le rejet est effectué par le bénéficiaire de la présentation par la création et la génération d'une
opération de rejet (fichier ENV) à destination de la banque remettante initiale.
L'opération de rejet doit contenir le même identifiant et détails de l’opération de présentation
initiale. (Cf. Contrôles réglementaires du document « ACP-ACH Contrôles logiques et
réglementaires WAMI_FR_V1.0.1.doc »).
5.8.2.4 Annulations de rejets de prélèvements (code enregistrement 24)
L’annulation de rejet du prélèvement ne peut être générée que par le remettant du rejet initial.
Quand un participant envoie par erreur une opération de rejet erronée au système ACP / ACH,
il peut l'annuler en créant et générant une opération d'annulation de rejet.
L'opération d'annulation de rejet doit contenir les mêmes informations que le rejet concerné.
(Cf. Contrôles réglementaires du document « ACP-ACH Contrôles logiques et réglementaires
WAMI_FR_V1.0.1.doc »).

Statut Ebauche
6 INTERFAÇAGE PARTICIPANTS
6.1 INTERFAÇAGE DES APPLICATIONS AGENCE AVEC LE SYSTÈME
D’INFORMATION
Dans cette partie, nous allons détailler les échanges entre les différents modules agence et le
système d’information de l’agence.
Cette configuration est plus utilisée par les banques ayant un système d’information
décentralisé (chaque agence opère d’une manière séparée et indépendante du siège).
Toutefois, les modules agences peuvent, selon l’organisation de la banque, être installés au
siège en tant qu’installation centralisée. Dans ce cas, tous les échanges de fichiers effectués
avec le système d’information du siège seront identiques à ceux effectués avec le système
d’information de l’agence.
Il est important de noter que tous ces échanges sont optionnels et n’affectent pas les
traitements de compensation si non pris en compte. Ces échanges ont pour but de mettre les
informations utiles disponibles des deux cotés (coté SI et coté module agence).
6.1.1 Système d’information agence vers les modules agence

Les différents échanges dans cette partie traitent de :
- Chargement des données au niveau de Barberousse Capture.

- Réconciliation des données par Barberousse Capture
- Fourniture des fichiers spécimens de signature pour Barberousse GIP
- Génération des fichiers de présentation pour les valeurs sans images.
- Génération des fichiers de rejet pour les valeurs sans images.

Statut Ebauche
In Fichiers de Out
données du SI Système d’information
agence
de l’agence
Barberousse Fichiers de
Capture réconciliation
In
Fichiers des Out
spécimens de
signature
Barberousse
GIP
fichiers ENV de
présentation
(Virement, Out
prélèvements)
BAL OUT
Rejection files
ENV (direct Out
credits, direct
debits)
6.1.1.1 Chargement des données dans Barberousse capture

Le module de scannérisation offre deux possibilités pour entrer les données des chèques et
effets scannés :
- Saisie Manuelle des données.
- Chargement des données à partir de fichiers fournis par le SI de la banque.
L’option de chargement est généralement choisie par les banques qui veulent éviter la double
saisie des données (au niveau u module de capture) qui ont déjà été saisies par le SI de
l’agence. Dans ce cas, le SI doit fournir au module de capture un fichier avec une structure
prédéfinie (voir Annexes : Structure des fichiers .Data).
6.1.1.2 Réconciliation avec Barberousse capture

La Réconciliations ne peut être effectuée qu’en cas de double saisie des données (au niveau du
SI de la banque et au niveau du module de capture).
Le module de capture permet deux modes de réconciliation de données :
Réconciliation 1: données Globales
La réconciliation des données globales est déclenchée à la demande de l’utilisateur. Elle

consiste en la réconciliation des données globales de chaque remise au niveau du module de
capture avec celles saisies au niveau du SI de la banque.

Statut Ebauche
1. Un fichier de données (.DATA) doit être généré par Barberousse-Capture.
2. Un fichier de réconciliation, ayant la même structure que le fichier DATA, doit être
fourni par le SI de la banque (voir Annexes : Structure des fichiers .Data).
Réconciliation 2: données détail
La réconciliation de données détail est aussi déclenchée à l demande de l’utilisateur. Elle

consiste à réconcilier les données détail de chaque remise traitée au niveau du module de
scannérisation avec les données détail saisies au niveau du SI de l’agence
3. Comme pour la réconciliation des données globales, Un fichier de réconciliation, ayant

la même structure que le fichier DATA, doit être fourni par le SI de la banque (voir
Annexes : Structure des fichiers .Data).
6.1.1.3 Affichage des spécimens de signature dans Barberousse GIP

Barberousse GIP permet l’affichage des spécimens de signature scannés des titulaires de
comptes s’ils sont fournis dans un format de fichier bien défini. La signature du titulaire de
compte sera alors affichée automatiquement à coté de l’image de la valeur reçue et l’utilisateur
pourra facilement procéder aux contrôles visuels de vérification de signature.
Pour afficher ces spécimens de signatures, ces derniers doivent être :
- Au format JPEG ou TIFF.
- Les noms de fichiers doivent contenir le numéro de compte d tireur.
- Tous les fichiers spécimens doivent être placés dans un répertoire bien défini.
6.1.1.4 Générations des remises de présentation (.ENV):

Les présentations et les annulations liées aux valeurs sans image doivent être fournies par le
SI de l’agence dans des fichiers ayant des formats définies afin d’être envoyées au siège de la
banque.
6.1.1.5 Génération des remises de rejets (.ENV):

Les rejets et les annulations de rejets liées aux valeurs sans image doivent être fournies par le
SI de l’agence dans des fichiers ayant des formats définies afin d’être envoyées au siège de la
banque.

Statut Ebauche
6.1.2 Modules agences vers le SI de l’agence
Les différents échanges traités dans cette partie traitent de :

- Chargement des fichiers à partir de Barberousse Capture
- Chargement des remises reçues.

- Chargement des rejets reçus de Barberousse-GIP
Out In
Fichiers de
données .DATA SI de l’agence
Barberousse
Capture
In
Out Fichiers de rejets

( chèques et
effets)
Barberousse
GIP
In
Fichiers RCP reçus
BAL IN
6.1.2.1 Chargement des fichiers de données de Barberousse capture
Toutes les données saisies au niveau du module de scannérisation peuvent être générés dans
des fichiers .DATA avec une structure prédéfinie et ce afin d’être chargés au niveau du SI de
l’agence.
Cette génération et ce chargement permettent ainsi au SI d’éviter la double saisie de données

de toutes les valeurs scannées.
Les fichiers de données DATA peuvent être générés à la demande de l’utilisateur ou

automatiquement à la validation de chaque remise scannée.
4. La structure du fichier de données .DATA est détaillée au niveau des annexes (voir
Annexes : structure des fichiers DATA).

Statut Ebauche
6.1.2.2 Chargement des remises reçues
Au fur et à mesure de leur réception, les remises reçues (fichiers RCP) sont déposées dans la
BAL IN de l’agence.
Ces fichiers peuvent donc être chargés par le SI de l’agence afin d’intégrer les données qu’elles
contiennent et procéder aux opérations comptables y afférentes.
En cas de réception d’annulations à partir de la chambre de compensation (ou annulations

intrabancaires), le SI doit les traiter en inversant toutes les écritures comptables déjà opérées
lors de la réception de l’opération initiale.
Les opérations annulées ne peuvent pas être rejetées par l’agence destinataire.
Le system d’information de l’agence peut aussi charger les comptes rendus d’opérations
(.CRO) reçues en fin de journée au niveau de la BAL IN de l’agence (voir annexes : Structure
des fichiers CRO.)
6.1.2.3 Chargement des rejets de Barberousse-GIP

Le module Barberousse-GIP génère des fichiers de rejets (.ENV) contenant tous les rejets
interbancaires et intrabancaires des chèques et des effets traités au niveau de l’agence.
Le SI de l’agence peut charger ces fichiers de rejet (ENV) et procéder aux opérations
comptables y afférentes.
Les structures des fichiers de rejets sont détaillées au niveau des annexes (voir annexes
structure des fichiers des présentations, rejets et annulations.)

Statut Ebauche
6.2 ECHANGES ENTRE LES MODULES SIEGE ET LE SI DE LA BANQUE
Ces échanges vont assurer:
- La présentation des remises en compensation.

- La réception des remises reçues de la compensation.
Il est important de noter que tous ces échanges sont optionnels et n’affectent pas les
traitements de compensation si non pris en compte. Ces échanges ont pour but de mettre les
informations utiles disponibles des deux cotés (coté SI et coté module agence).
6.2.1 SI de la Banque vers les modules du siège
In Fichiers des Out

présentations
ENV (Virements,
prélèvements)
SI de la Banque
Hannibal ADT Fichiers des rejets

ENV (Virements,
prélèvements)
Fichiers ENV
erronnés
6.2.1.1 Génération des fichiers de présentation et des rejets (ENV)

Les fichiers (.ENV) des virements et prélèvements générés par le SI de la banque doivent être
contrôlés par le module Hannibal ADT avant d’être envoyées en compensation. Après ces
contrôles (syntaxiques, logiques, réglementaires et de réconciliation), seuls les fichiers corrects
seront présentés en compensation. Les fichiers erronés seront rejetés.
Le SI de la banque doit donc corriger les erreurs et re-soumettre les fichiers corrigés pour
contrôle par Hannibal-ADT.

Statut Ebauche
Il est important cependant de noter que ces erreurs sont généralement plus fréquentes lors du
démarrage du système. Au fur et a mesure que les mécanismes et règles d’échange du
système seront maitrisées, ces erreurs seront amenés a diminuer sensiblement voir
disparaitre.
Cas des annulations:
Lorsque qu’une remise d’annulation (annulation de présentation ou annulation de rejet) est

envoyée par le SI à Hannibal-ADT, le SI est supposé avoir déjà procédé aux réajustements
comptables nécessaires et relatifs aux opérations annulées.
Lorsqu’une remise d’annulation envoyée par le SI à Hannibal-ADT, n’est pas acceptée par
celui-ci, le SI doit réajuster sa comptabilité suivant les annulations rejetées.
6.2.2 Modules du siège vers le SI de la Banque

6.2.2.1 Chargement des fichiers des présentations et des rejets ENV
envoyés en compensation
Remises à
Out envoyer en
compensation
Centre de
.ENV Compensation
Hannibal ADT
In
Comptabilité
SI de la Banqie
Une copie de toutes les remises envoyées en compensation peut être fournie par Hannibal-ADT
au SI de la banque pour chargement et comptabilisation.
6.2.2.2 Chargement des remises de présentation et de rejet reçues de la

compensation
Centre de .RCP Out .RCP In

received received Core Banking
compensation remittances remittances System
To accounting
Hannibal ADT

Statut Ebauche
Une copie de toues les remises reçues (fichiers RCP reçus du centre de compensation) peut
être fournie par Hannibal-ADT au SI de la banque pour chargement et comptabilisation. Ces
fichiers ont la même structure que les fichiers ENV (voir annexes structure des fichiers des
présentations, rejets et annulations.)
Cas des annulations:
Quand une annulation en provenance de la compensation est reçue par le SI de la banque a

travers le module Hannibal-ADT, le SI est tenu de procéder aux réajustement comptables
nécessaires relatifs aux opérations annulées.
6.2.2.3 Chargement des comptes rendus
Fichiers Rejets
ENV réglementaires
erronés
SI de la Remises Remises ENV

envoyées en Centre de
Banque ENV
compensation compensation
Hannibal ADT &

Hannibal PosteAdherent
Comptes
Comptabilisation Comptes rendus du
rendus du centre de
siège compensation
Entre les remises générées par le SI et les opérations finalement traitées en compensation,
des différences peuvent être notées.
Ces différences peuvent être dues aux facteurs suivants:
1. Une remise a été générée par le SI de la banque mais n’a pas été déposée au niveau de
Hannibal ADT (ou Poste adherent).
Dans ce cas, la remise n’est pas acquittée par le centre de compensation. Cette information
peut être déduite à partir du compte rendu de fin de journée envoyé par le centre de
compensation.
2. Une remise déposée au niveau de Hannibal ADT (ou Poste adherent) et télécollectée
par le centre de compensation, a été acceptée après le contrôle logique et syntaxique, mais
certaines de ses opérations ont été rejetées lors du contrôle règlementaire.
Statut Ebauche
Dans ce cas, des fichiers de rejets règlementaires sont générés par le centre de compensation
comportant le motif de rejet et envoyés à la banque remettante.
En de fin de journée, des comptes rendus contenant toutes les informations sur les opérations
acceptées et rejetées sont générés par le centre de compensation et envoyées aux
participants.
Ces comptes rendus de fin de journée sont chargés au niveau d’Hannibal-ADT de chaque
banque et ce dernier acquitte toutes les remises traitées en fonction du contenu de ces
comptes rendus.
Des comptes rendus d’opérations sont générés par Hannibal ADT dés la consommation des
comptes rendus de fin de journée reçus de la compensation.
Les comptes rendus d’opérations contiennent toutes les informations ainsi que le sort de toutes
les opérations envoyées en compensation (acceptées par la compensation, rejetées par la
compensation).
Les comptes rendus d’opérations peuvent être charges par le SI de la banque après leur
génération par le module Hannibal-ADT
7 DÉSIGNATION DE L’ÉQUIPE PROJET

Chaque participant doit désigner une équipe Projet Télécompensation. Il est recommandé que
cette équipe soit la même qui suit les Comités de pilotage et de suivi du Projet.
Un facteur important de réussite est l’adhésion totale de la direction générale et la désignation

d’un ‘Responsable Télécompensation’ pour la coordination entre les différents intervenants et
le suivi de la mise en place des actions décidées et/ou préconisées par ce rapport.

Statut Ebauche
8 PLANIFICATION DES FORMATIONS
8.1 FORMATIONS ASSURÉES PAR BFI
Plusieurs cycles de formation pour les participants vont être assurés par les formateurs de BFI.
Ces formations vont concerner les profils suivants :
- Utilisateurs,
- Administrateurs,
- Informaticiens,
Pour chaque session, le participant désignera une équipe restreinte de deux personnes :
l'objectif est de créer une équipe qui maîtrise les modules du nouveau progiciel. Cette équipe
aura par la suite la charge de former les autres collaborateurs de l’institution intervenant dans
le système ACP/ACH.
Nous préconisons que pour les sessions ‘Utilisateur’ et ‘Administrateur’ que le participant
désigne un même binôme afin d’assurer la continuité et la cohérence entre l’utilisation et
l’administration du système.
Le planning détaillé de ces formations sera fourni par les Banques Centrales à chaque
participant.
8.1.1 Formations des utilisateurs

La formation des utilisateurs permet d'assurer la préparation des agents aux nouvelles
fonctions qui sont liées à l'évolution de l'activité de la banque et à l'utilisation du
nouveau Système de Compensation. Elle va se dérouler de la manière suivante :
Profil des
Objet Lieu Formateurs
personnes
Présentation et utilisation des modules agence

Pays Formateurs
et de la plateforme participant au niveau du Utilisateurs
d’implémentation BFI
siège.
8.1.2 Formations des administrateurs

La formation des administrateurs du système est essentielle car elle couvre la
formation fonctionnelle de paramétrage et d'opération sur tous les modules ainsi que
la supervision du système :
Statut Ebauche
Profil des
Objet Lieu Formateurs
participants
Présentation des modules et

paramétrage. Pays
Administrateurs Formateurs BFI
d’implémentation
Diagnostic et supervision des modules.
Gestion des reprises.
8.1.3 Formations des informaticiens

La formation des informaticiens de chaque participant va permettre une prise en main
technique de la solution BFI de Télécompensation par la présentation de l’architecture
technique des modules :
Objet Profil des personnes Lieu Formateurs
Présentation technique des modules Informaticiens Pays d’implémentation Formateur BFI
8.1.4 Formations des installateurs

La formation des installateurs de chaque participant va permettre une autonomie des
installateurs en termes d’installation et de réinstallation des applicatifs de la solution :
Objet Profil des personnes Lieu Formateurs
Informaticiens/
Installation des modules Pays d’implémentation Formateur BFI
Techniciens
8.2 FORMATIONS À ASSURER PAR LES PARTICIPANTS

Les formations assurées par BFI vont se dérouler suivant la formule des ‘formation des
formateurs’. Par la suite, il sera nécessaire pour chaque participant d’organiser des sessions de
formations en interne.
Il est important de noter que l’utilisation des modules de la solution de Télécompensation

suppose une connaissance basique de Windows 2008 (utilisateurs des modules siège) : si les
futurs utilisateurs du système ne sont pas habitués à travailler dans un tel environnement, il
est nécessaire de prévoir des sessions de formation à cet environnement.

Statut Ebauche
9 ANNEXES
9.1 STRUCTURES DE NOMS DES FICHIERS
9.1.1 Structure des noms des fichiers (.DATA)
9.1.1.1 Noms des fichiers DATA Individuels (.DATA)
Numér code Code DATE DE Heure de

Code
Code o de participan devis Génératio
champ agence Generation Extensio
valeu remise t e n
s remettant n
r (DDMMYYYY
remettant e HHMMSS
)
Length 02 07 03 03 03 08 06 .Data
Exemple: 30000000300100227009062010114530.Data: fichier data individuel de la

remise cheque 0000003 de chèques du 9 juin 2010 de l’agence 002 et de la banque 001.
9.1.1.2 Noms des fichiers DATA cumulés (.DATA)
Préfixe code Code DATE DE Heure de

Code
Code participan devis Génératio
champ ‘ACCU’ agence Generation Extensio
valeu t e n
s remettant n
r (DDMMYYYY
remettant e HHMMSS
)
Length 02 04 03 03 03 08 06 .Data
Exemple: 30ACCU00100227009062010114530.Data: est un fichier data cumulé de

chèques du 09 Juin 2010 de l’agence 002 et de la banque 001.
9.1.1.3 Noms des fichiers DATA Globaux (.DATA)
Préfixe code Code DATE DE Heure de

Code
Code participant devise Génération
champs ‘GLOB’ agence Generation Extension
valeur
remettant remettante HHMMSS
(DDMMYYYY)
Length 02 04 03 03 03 08 06 .Data
Exemple: 30GLOB00100227009062010114530.Data: est un fichier data Global de chèques

du 09 Juin 2010 de l’agence 002 et de la banque 001.

Statut Ebauche
9.2 STRUCTURE DES NOMS DE REMISES NUMÉRIQUES (.ENV/ RCP)
La structure du nom du fichier .ENV/RCP s’applique à toutes les remises envoyées (ou
reçues) par les participants vers (ou en provenance) du centre de compensation, à
savoir :
Code centre Code Code

Code Date de Heure de Code Code
Champ de participant devis Ext
pays génération génération valeur enregistrement
compensation émetteur e
Longueur .ENV
02 02 03 08 06 02 02 03
.RCP
Exemple : 01-GM-001-11022010-101352-30-21-270.ENV
Il s’agit d’une remise de présentation de chèques émise par la banque 001.
Remarque :
- Les champs qui définissent les noms de fichiers sont séparés par des tirets.
- si les fichiers .ENV/RCP sont générés au niveau de l’agence, les noms des fichiers doivent
contenir le code agence remettante après le code banque remettante.
9.3 STRUCTURE DES NOMS DE FICHIERS IMAGE CAT & PAK
Code centre Code

Cod participan Date Heure Code Code Code
de
Champ e t génératio génératio valeu enregistremen devis Ext
compensatio
pays n n r t e
n
Longueu .CAT
r 02 02 03 08 06 02 02 03
.PAK
Exemple : 01-SL-002-13122004-111000-30-21-694.CAT
Il s’agit d’un fichier catalogue inter relatif à la valeur chèque généré par le participant 002.
01-SL-002-13122004-111000-30-21-694.PAK
Il s’agit d’un fichier package inter relatif à la valeur chèque généré par le participant 002.
Remarque :
- si les fichiers sont générés au niveau de l’agence, les noms des fichiers doivent contenir le
code agence remettante après le code banque remettante.

Statut Ebauche
9.4 STRUCTURE DE NOMS DES AUTRES FICHIERS ÉMIS PAR LE CENTRE
DE COMPENSATION
9.4.1 Structure de nom de fichiers des rejets règlementaires (.RJT)
Code centre Code Date

Cod participant Heure Code Code
de de Code
Champ e génératio valeu enregistremen Ext
compensatio Destinatair sessio devise
pays n r t
n e n
Longueur 02 02 03 08 06 02 02 03 .RJT
Exemple : 01-GN-003-11022010-171648-23-21-324.RJT
Il s’agit d’un rejet réglementaire d’une remise de prélèvements représentés reçue par la
banque 003.
Remarque :
- Si les fichiers RJT sont générés au niveau des agences, le nom du fichier devrait contenir le
code de l’agence présentatrice, après le code de la banque présentatrice.
9.4.2 Structure de nom de fichiers des Situations nette détaillées

Code
Code centre de Code participant Date de Heure Code Code
Champ Extension
compensation pays session génération valeur devise
destinataire
Longueur .SNI
.SND
.SIV
02 02 03 08 06 02 03
.SNF
.SFV
.SDV
Exemples :
01-GM-001-11022010-181347-40-270.SNI : Il s’agit de la situation nette intermédiaire lettre
de change du participant 001.
01-SL-002-11022010-181347-40-694.SIV : Il s’agit de la situation nette intermédiaire globale
par valeur de la lettre de change du participant 002.
01-GN-003-11022010-190000-50-324.SNF : Il s’agit de la situation nette de fin de session de
la valeur opération sur carte du participant 003.
01-GM-004-11022010-190000-50-270.SFV : Il s’agit de la situation nette de fin de session
globale par valeur de l’opération sur carte du participant 004.

Statut Ebauche
01-SL-005-12022010-130101-43-694.SND : Il s’agit de la situation nette définitive de la
valeur lettre de change représentée du participant 005.
01-GN-006-12022010-130101-40-324.SDV : Il s’agit de la situation nette définitive globale
par valeur de la lettre de change du participant du participant 006.
Remarque :
9.4.3 Structure de nom de fichiers de Situation nettes Globales

Code
Code centre de Code participant Date de Heure Code
Champ Extension
compensation pays session génération devise
destinataire
Longueur .SIG
02 02 03 08 06 03 .SFG
.SNG
Exemples
01-GM-003-11022010-181387-270.SIG : Il s’agit de la situation nette intermédiaire globale du
participant 003.
01-SL-002-11022010-180010-694.SFG : Il s’agit de la situation nette de fin de session globale
du participant 002.
01-GN-001-12022010-110002-324.SNG : Il s’agit de la situation nette globale du participant
001.
Remarque :
9.4.4 Structure du nom de fichier échéancier de règlement (.ECH)
Code centre Code

Code participant Date de Heure Code Code
Champ de Extension
pays session génération valeur devise
compensation destinataire
Longueur 02 02 03 08 06 02 03 .ECH
Exemple : 01-GM-001-12022010-100001-33-270.ECH
Il s’agit de l’échéancier de règlement de la valeur chèque représenté du participant 001.
Remarque :

Statut Ebauche
9.4.5 Structure du nom de fichier compte rendu (CRS/CPR)
Code
Nom du Code centre de Code participant Date de Heure Code
Extension
champ compensation pays session génération devise
destinataire
Longueur 02 02 03 06 03 . CRS
08
.CPR
Exemple : 01-SL-001-11022010-106081-694.CRS
Il s’agit d’un compte rendu de fin de session généré par le centre de compensation pour le
participant 001.
01-GN-001-11022010-120001-324.CPR
Il s’agit d’un compte rendu de fin de journée généré par le centre de compensation pour le
participant 001.
Remarque :
9.4.6 Structure du nom de fichier compte rendu opération (CRO)
Le fichier .CRO contient toutes les opérations envoyées par les participants vers le
centre de compensation, à savoir :
Code centre Code

Code Date de Heure de Code Code
Champ de participant Ext
pays génération génération valeur devise
compensation émetteur
Longueur 02 02 03 08 06 02 03 .CRO
Exemple : 01-GM-001-11022010-150000-30-270.CRO
Il s’agit d’un compte rendu des opérations chèques émise par la banque 001.
Remarque :
- Si les fichiers CRO sont générés au niveau des agences, le nom du fichier devrait contenir
le code de l’agence présentatrice, après le code de la banque présentatrice.

Statut Ebauche
9.5 STRUCTURES DES FICHIERS DE DONNÉES DES PRÉSENTATIONS, DE
REJETS ET D’ANNULATIONS
- Le champ code participant figurant au niveau des enregistrements globaux correspond
au code remettant pour les remises .ENV et au code destinataire pour les remises
.RCP ;
- Le format date existant au niveau de toutes les structures est JJMMAAAA ;
- Tous les champs numériques doivent être cadrés à droite au niveau des structures.
9.5.1 Structure des fichiers DATA (.Data)
9.5.1.1 Fichiers DATA Chèques
9.5.1.1.1 Enregistrement Global
Champs Type Longueur Description
30 : Cheque présenté

Code valeur Numérique 02
33 : Cheque représenté
Code enregistrement Numérique 01 Doit être égal à 1 (enregistrement global)
Code devise Numérique 03 Code devise de la remise
Numéro de remise Numérique 07 Indique le numéro de la remise
Numérique RIB bénéficiaire (code banque, code agence, numéro

RIB bénéficiaire 18
de compte, clé de contrôle compte)
Alpha-
Nom du bénéficiaire 30 Indique le Nom du bénéficiaire
Numérique
Alpha-
Adresse du bénéficiaire 30 Indique l’adresse du bénéficiaire
Numérique
Nombre of chèques Numérique 10 Nombre de chèques de la remise
Montant Total Numérique 15 Montant total de la remise
Code état Numérique

02 Code état de réconciliation
Réconciliation
Informations Alpha-
30 Information concernant la remise
complémentaires Numérique
Date de remise Numérique 08 Date de remise client
Alpha-
Utilisateur 20 Utilisateur
Numérique
Alpha- “LOT” pour le mode LOT / “REM” pour le mode

Mode de scannérisation 03
Numerique remise

Statut Ebauche
Alpha-
Filler 101 non used zone
Numerique
Longueur: 280
9.5.1.1.2 Enregistrement Détail
Field name Type Length Description
30 : Cheque présenté

code valeur Numérique 02
33 : Cheque représenté
Numérique Doit être égal à 2 (enregistrement

Code enregistrement 01
détail)
Numéro remise Numérique 07 Numéro de la remise
Ligne MICR Numérique 37 Ligne MICR du chèque
Date émission Numérique 08 Date émission format JJMMAAAA
Montant Cheque Numérique 15 Montant du chèque
code Etat Réconciliation Numérique 02 Code état de réconciliation
Numérique Date de remise des chèques par le client

Date remise 08
à la banque
Code agence remettante Numérique 03 Code agence remettante
Alpha-
Nom du tireur Numérique 30 Nom du tireur
Alpha-
Adresse du tireur 30 Adresse du tireur
Numérique
RIB bénéficiaire Numérique 18
Alpha-
Nom bénéficiaire 30
Numérique
Alpha-
Address bénéficiaire 30
Numérique
Alpha-
Numérique
Alpha-
Zone libre 39 Zone libre
Numérique
Longueur : 280

Statut Ebauche
9.5.1.2 Bill of exchange data file
9.5.1.2.1 Enregistrement Global
Field name Type Length Description
40 : présentation de lettre de change

43 : représentation de lettre de change
Numérique Doit être égal à 1 (enregistrement

Code enregistrement 01
global)
Numéro de remise Numérique 07
Numérique RIB bénéficiaire (code banque, code

RIB bénéficiaire 18 agence, numéro de compte, clé de
contrôle compte)
Alpha-
Nom du bénéficiaire 30 Indique le Nom du bénéficiaire
Numérique
Alpha-
Adresse du bénéficiaire 30 Indique l’adresse du bénéficiaire
Numérique
Nombre de lettres de Numérique Nombre de lettres de change de la

10
change remise
Montant Total Numérique 15 Montant Total de la remise
Code état Réconciliation Numérique 02 Code état Réconciliation
Informations Alpha-
30 Informations sur la remise
complémentaires Numérique
Numérique Date de remise des effets par le client

Date de remise 08
JJMMAAAA
Alpha-
Numérique
Alpha- “LOT” pour le mode LOT / “REM” pour le

Mode de scannérisation 03
Numerique mode remise
Alpha-
Zone libre 101
Numérique
Longueur : 280

Statut Ebauche
9.5.1.2.2 Enregistrement Détail
Field name Length Description
40 : présentation de lettre de change

43 : représentation de lettre de change
Code enregistrement Numérique 01 Doit être égal à 2 (enregistrement détail)
Numéro remise Numérique 07 Numéro de la remise
Numéro de la lettre de Numérique

12 N° of the bill of exchange
change
Numérique RIB du payeur (code banque, code agence, numéro de

RIB du Payeur 18
compte, clé de contrôle compte)
Numérique RIB bénéficiaire (code banque, code agence, numéro

RIB beneficiaire 18
Nature effet Numérique 01 1 : personnel / 2 : entreprise / 3 : Banque
Montant de l’effet Numérique 15 Montant de l’effet
Date échéance Numérique 08 JJMMAAAA
Date de création Numérique 08 JJMMAAAA
Alpha-
Lieu de création 30
Numérique
Numérique 0 : lettre de change acceptée

Code d’acceptation 01
1 : lettre de change non acceptée
0 : Ni endosseur ni avaliseur
Code endossement et 1 : Endosseur

Numérique 01
aval 2 : Avaliseur
3 : Endosseur et avaliseur
Code état Numérique

02 Code état Réconciliation
Réconciliation
Date de remise Numérique 08 Date de remise des effets par le client JJMMAAAA
Code agence Numérique

03 Code agence remettante
remettante
Alpha-
Nom du tireur 30 Nom du tireur
Numérique
Alpha-
Adresse du tireur 30 Adresse du tireur
Numérique

Statut Ebauche
Alpha-
Nom bénéficiaire 30
Numérique
Alpha-
Address bénéficiaire 30
Numérique
Alpha-
Numérique
Alpha-
Zone libre 02 Zone libre
Numérique
Longueur : 280

Statut Ebauche
9.5.2 Virements / Virements représentés
9.5.2.1 Enregistrement global
N° Type Longueur Désignation Description Oblig
1 : Aller participant remettant

1. N 01 Sens 2 : Retour du centre vers participant O
destinataire
00 : Intrabancaire.
Code centre de
2. N 02 01 : Interbancaire national. O
compensation
02 : Interbancaire Régional.
GM = Gambie.
Code pays de SL = Sierra Leone

3. N 02 O
l’émetteur GN = Guinée
LR = Liberia
4. N 08 Date de génération Date de génération JJMMAAAA O
5. N 06 Heure génération Heure de génération HHMMSS O
6. N 02 Code valeur 10 / 13 O
7. N 03 Code participant Compléter avec des 0 à gauche O

Date de Date de présentation à la compensation
8. N 08 O
présentation JJMMYYYY
Date de
Date de présentation appliquée par le
9. N 08 présentation O
centre de compensation JJMMYYYY
appliquée
10. N 07 Numéro de la remise Compléter avec des 0 à gauche O
Code
11. N 02 11 / 12 / 13 / 14 O
enregistrement
270 (GM) /694 (SL) / 324 (GN) /430

12. N 03 Code devise O
(LR)
13. N 02 Rang 00 O
Montant total
14. N 15 Compléter avec des 0 à gauche O
virements
Nombre total
virements

Statut Ebauche
16. N 301 Zone libre Compléter avec des blancs à droite F
Longueur : 380 caractères
O = obligatoire / F = facultatif
9.5.2.2 Enregistrement détail
1. N 01 Sens 1 / 2 (Envoi / Réception) O
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.

3. N 02 O
LR = Liberia
Code participant
remettant
Date de présentation à la compensation

8. N 08 Date de présentation O
JJMMAAAA
Date de présentation Date de présentation appliquée par le

9. N 08 O
appliquée centre de compensation JJMMAAAA
Num remise interne à la banque

10. N 07 Numéro de la remise O
Compléter avec des 0 à gauche
11. N 02 Code enregistrement 21 / 22 / 23 / 24 O
270 (GM) /694 (SL) / 324 (GN) /430

(LR)
13. N 02 Rang 00 (enregistrement détail) O

Statut Ebauche
0 : virement de particulier.
1 : Virement Entreprise.
14. N 01 Nature du virement O
2 : virement de banque.
3 : Mandat Postal
15. N 15 Montant du virement Compléter avec des 0 à gauche O
(attribué par le participant remettant)

16. N 07 Numéro du virement O
Code Agence
remettante
Date de remise de l’opération par le

18. N 08 Date de remise O
client à sa banque JJMMAAAA
(code banque, code agence,

19. N 18 RIB du payeur numéro de compte, clé de contrôle O
compte)
Nom ou raison
20. N 30 Compléter avec des blancs à droite F
sociale du payeur
21. N 30 Adresse du payeur Compléter avec des blancs à droite F
Code participant
destinataire
GM = Gambie.
Code pays du SL = Sierra Leone

23. 02 O
destinataire GN = Guinée
LR = Liberia

compte du
24. N 18 numéro de compte, clé de contrôle O
bénéficiaire
compte)
Nom ou raison
25. N 30 sociale du Compléter avec des blancs à droite F
bénéficiaire
Adresse du
bénéficiaire
Numéro ou référence
27. N 20 du dossier relatif au Compléter avec des blancs à droite F
paiement

Statut Ebauche
Nombre
28. N 02 d’enregistrements 00 O
complémentaires
29. N 45 Motif de l’opération Compléter avec des blancs à droite F
Motif de Uniquement en cas de représentation

30. N 15 F
représentation Compléter avec des blancs à droite
Date de présentation appliquée + DR

31. N 08 Date de règlement O
de la valeur (JJMMAAAA)
Code du motif de rejet (4 motifs)

32. N 08 Motif du rejet O
33. N 33 Zone libre - Compléter avec des blancs à droite F
O = obligatoire / F = facultatif
9.5.2.3 Enregistrement Complémentaire
00 : Intrabancaire. O
Code centre de
2. N 02 01 : Interbancaire national.
compensation
GM = Gambie. O

3. N 02
LR = Liberia
4. N 08 Date de génération Date de génération O
5. N 06 Heure génération Heure de génération O
Code participant O
7. N 03 Code banque (avec 00 à gauche)
remettant
Date de
Date de présentation à la O
8. N 08 présentation
compensation JJMMAAAA

Statut Ebauche
Date de Date de présentation appliquée par la O
9. N 08 présentation compensation JJMMAAAA
appliquée
Numéro de la - O
10. N 07
remise
Code O
11. N 02
enregistrement
270 (GM) /694 (SL) / 324 (GN) /430
(LR)
Rang 01 à 20 enregistrements O
13. N 02
complémentaires
0 : virement de particulier. O

1 : Virement Entreprise.
14.
2 : virement de banque.
N 01 Nature du virement 3 : Mandat Postal
Montant du O
15.
N 15 virement Compléter avec des 0 à gauche
Numéro du O
16. N 07 (attribué par le participant remettant)
virement
17. N 110 Message F
1 : Identité Nationale O

18. N 1 Type Pièce
2 : Passeport
19. N 15 Numéro Pièce O
adresse du F
20.
aN 30 bénéficiaire
21. N 147 Zone Libre - F
Longueur: 380 caractères
O = Obligatoire / F = facultatif
9.5.3 Virements en provenance de l’Etranger (ENV/RCP)

Statut Ebauche
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.
3. N 02 l’émetteur du O
virement GN = Guinée
LR = Liberia
6. N 02 Code valeur 12 O
Code participant
remettant
8. N 08 O
présentation JJMMAAAA
Date de
centre de compensation JJMMAAAA
appliquée
Code
11. N 02 11 / 12 / 13 / 14 O
enregistrement
270 (GM) /694 (SL) / 324 (GN) /430

(LR)
13. N 02 Rang 00 (constante) O
Montant total
virements
Nombre total
virements

Statut Ebauche
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.

3. N 02 O
LR = Liberia
4. N 08 Date de génération JJMMAAAA O
Code participant
remettant

8. N 08 O
Date de
appliquée
Num remise interne à la banque
Code
11. N 02 21 / 22 / 23 / 24 O
enregistrement
270 (GM) /694 (SL) / 324 (GN) /430

(LR)
13. N 02 Rang 00 (enregistrement détail) O
Montant du
virement
(attribué par le participant remettant)

15. N 10 Numéro du virement O
16. N 03 Code devise initial Code devise de l’opération initiale O
Montant de l’opération dans la devise

17. N 15 Montant initial O
initiale. Compléter avec des 0 à gauche
Code Agence
remettante

Statut Ebauche
Date de réception du virement en
19. N 08 Date de réception O
provenance de l’étranger JJMMAAAA
Numéro de compte (code banque, code agence, numéro

20. N 18 O
du donneur d’ordre de compte, clé de contrôle compte)
Nom et prénom ou
21. N 30 raison sociale du Compléter avec des blancs à droite O
donneur d’ordre
Adresse du donneur
22. N 30 Facultatif F
d’ordre
Code participant
destinataire
GM = Gambie.
Code pays du SL = Sierra Leone

24. 02 O
destinataire GN = Guinée
LR = Liberia
compte du (code banque, code agence, numéro

25. N 18 O
bénéficiaire de compte, clé de contrôle compte)
Nom ou raison
26. N 30 sociale du Compléter avec des blancs à droite O
bénéficiaire
Adresse du
27. N 30 Facultatif F
bénéficiaire
Numéro ou
28. N 20 référence du dossier Compléter avec des blancs à droite F
relatif au paiement
Nombre
29. N 02 d’enregistrements 00 O
complémentaires
30. N 45 Motif de l’opération Compléter avec des blancs à droite F
Référence de la banque Etrangère,

Référence Banque
31. N 30 émettrice du virement. Compléter avec O
Etrangère
des blancs à droite
Frais banque Frais perçus par la banque donneur

32. N 15 F
Donneur Ordre d’ordre. Compléter avec des 0 à gauche
Frais banque Frais perçus par la banque Etrangère.

33. N 15 F
Etrangère Compléter avec des 0 à gauche

Statut Ebauche
Date de présentation appliquée + DR de
la valeur JJMMAAAA
Code du motif de rejet (4 motifs)

35. N 08 Motif du rejet O
9.5.4 Prélèvements (ENV/RCP)
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.

3. N 02 O
LR = Liberia
Date de
4. N 08 Date de génération (JJMMAAAA) O
génération

8. N 08 O
Date de
appliquée
Numéro de la
remise

Statut Ebauche
Code
11. N 02 11 / 12 / 13 / 14 O
enregistrement
270 (GM) /694 (SL) / 324 (GN) /430

(LR)
Montant total des

prélèvements
Nombre total des
prélèvements
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.
SL = Sierra Leone
3. N 02 Code pays O
GN = Guinée
LR = Liberia
Date de Date de génération (JJMMAAAA)

4. N 08 O
génération
Code participant Compléter avec des 0 à gauche

7. N 03 O
remettant

8. N 08 O
présentation (JJMMAAAA)
Date de
centre de compensation (JJMMAAAA)
appliquée

Statut Ebauche
Numéro de la Compléter avec des 0 à gauche
10. N 07 O
remise
Code
11. N 02 enregistrement 21 / 22 / 23 / 24 O
détail
Code devise 270 (GM) /694 (SL) / 324 (GN) /430

12. N 03 O
(LR)
Montant du Compléter avec des 0 à gauche

13. N 15 O
prélèvement
Numéro du Compléter avec des 0 à gauche

14. N 07 O
prélèvement
Code Agence Compléter avec des 0 à gauche

15. N 03 O
remettante

16. N 08 Date de remise O
client à sa banque (JJMMAAAA)
Compte du (code banque, code agence, numéro

17. N 18 débiteur O
Nom et prénom
du client Débiteur
Adresse du client
Débiteur

20. N 03 O
destinataire
Code pays du GM = Gambie.

participant
SL = Sierra Leone
21. N 02 destinataire O
GN = Guinée
LR = Liberia
Compte du (code banque, code agence, numéro

22. N 18 créancier O
Nom et prénom
23. N 30 du client Compléter avec des blancs à droite F
Créancier
Adresse du client
Créancier
Code émetteur du Code national de l’émetteur du

25. N 10 prélèvement prélèvement. Compléter avec des 0 à O
gauche

Statut Ebauche
Numéro de Compléter avec des blancs à droite
26. N 20 O
l’autorisation
libellé Libellé / motif du prélèvement.

27. N 45 F
Compléter avec des blancs à droite
Motif de Uniquement en cas de représentation.

28. N 15 F
représentation Compléter avec des blancs à droite.
Date de compensation appliquée + DR
Date de
29. N 08 du prélèvement (JJMMAAAA) O
règlement
Motif du rejet Code du motif de rejet (4 motifs).

30. N 08 O
31. N 08 Date échéance JJMMAAAA O
32. N 08 Date de la facture JJMMAAAA F
33. N 22 Zone libre Compléter avec des blancs à droite. F
Longueur: 390 caractères
Remarque :
Le débiteur doit autoriser le l’institution bénéficiaire à lui envoyer des prélèvements pour
paiement
L’autorisation de prélèvement est transmise par la banque du bénéficiaire à la banque du
débiteur.
Le formulaire d’autorisation contient les informations suivantes :
- Le numéro/référence de l’organisme émetteur: référence/numéro qui identifie le
bénéficiaire qui va présenter le prélèvement pour paiement. ce référence/numéro doit
être déclaré dans le référentiel du centre de compensation.
- Le RIB du créancier
- Le nom ou raison sociale de l’organisme bénéficiaire
- Le nom du débiteur
- Adresse du débiteur
- Le RIB débiteur
- Object du prélèvement
- Date d’échéance du prélèvement
- Numéro de l’autorisation de prélèvement
- Le montant plafond
- La durée de validité de l’autorisation de prélèvement

Statut Ebauche
9.5.5 Chèques
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.

3. N 02 O
LR = Liberia

Date de présentation
Date de présentation à la
8. N 08 O
Date de présentation appliquée par
appliquée
9. N 08 le centre de compensation O
JJMMAAAA
270 (GM) /694 (SL) / 324 (GN)

/430 (LR)
Montant total des

chèques
Nombre total des

chèques

Statut Ebauche
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.
SL = Sierra Leone
GN = Guinée
LR = Liberia
Code participant
remettant

appliquée
JJMMAAAA
Référence interne à la banque

10. N 07 Numéro de la remise remettante. Compléter avec des 0 O
à gauche.
Code enregistrement
11. N 02 21 / 22 / 23 / 24 O
détail
270 (GM) /694 (SL) / 324 (GN)

/430 (LR)
1 : chèque personnel

13. N 1 Nature du chèque 2 : chèque Entreprise O
3 : chèque de banque
14. N 15 Montant du chèque Compléter avec des 0 à gauche O

Statut Ebauche
15. N 08 Numéro du chèque Compléter avec des 0 à gauche O
Code Agence
remettante

17. N 08 Date remise O
client à sa banque JJMMAAAA

18. N 18 compte du tireur numéro de compte, clé de O
contrôle compte)
Nom ou raison sociale

19. N 30 Compléter avec des blancs à droite. O
du Tireur
20. N 30 Adresse du Tireur Compléter avec des blancs à droite. F
Code participant
destinataire

participant destinataire
SL = Sierra Leone
22. N 02 O
GN = Guinée
LR = Liberia

23. N 18 Compte du bénéficiaire numéro de compte, clé de O
contrôle compte)

24. N 30 Compléter avec des blancs à droite. O
du bénéficiaire
25. N 30 Adresse du bénéficiaire Compléter avec des blancs à droite. F
Date d’émission du
26. N 08 JJMMAAAA O
chèque
Uniquement en cas de
27. N 15 Motif de représentation représentation. Compléter avec des F
blancs à droite.
Date de présentation appliquée +

DR de la valeur. JJMMAAAA
Code du motif de rejet (4 motifs).

29. N 08 Motif de rejet O
- Compléter avec des blancs à

30. N 23 Zone libre F
droite.
Statut Ebauche
Statut Ebauche
9.5.6 Lettre de change
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.
Code pays de SL = Sierra Leone.

3. N 02 O
l’émetteur GN = Guinée.
LR = Liberia

Code valeur 40 / 43
6. N 02 O
7. N 03 O
appliquée
JJMMAAAA
Numéro de la remise Compléter avec des 0 à gauche
10. N 07 O
Code enregistrement 11 / 12 / 13 / 14
11. N 02 O
global
Code devise 270 (GM) /694 (SL) / 324 (GN)
12. N 03 O
/430 (LR)
Rang 00 (constante)
13. N 02 O
Montant total des Compléter avec des 0 à gauche
14. N 15 O
lettres de changes
Nombre total des Compléter avec des 0 à gauche
15. N 10 O
lettres de changes
Zone libre Compléter avec des blancs à droite
16. N 401 F

Statut Ebauche
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.
SL = Sierra Leone.
GN = Guinée.
LR = Liberia

40 / 43
6. N 02 Code valeur O
7. N 03 O
remettant

appliquée
JJMMAAAA

Code enregistrement
11. N 02 21 / 22 / 23 / 24 O
détail
270 (GM) /694 (SL) / 324 (GN)
/430 (LR)
00 (enregistrement détail)
13. N 02 Rang O
1 : Effet de particulier
14. N 01 Nature Effet 2 : Effet d’entreprise O
3 : Traite de bancaire

Montant de la lettre
de change
16. N 15 Montant des intérêts Compléter avec des 0 à gauche F

Statut Ebauche
Montant des frais du
17. N 15 Compléter avec des 0 à gauche F
protêt
Numéro de la lettre
de change
Code Agence Compléter avec des 0 à gauche
19. N 03 O
remettante
JJMMAAAA
20. N 08 Date remise O
(code banque, code agence, numéro
21. N 18 Compte du tiré O
22. N 18 Compte du tiré initial O
23. N 03 O
destinataire
Code pays du 270 (GM) /694 (SL) / 324 (GN)
24. N 02 participant /430 (LR) O
destinataire
25. N 18 Compte bénéficiaire O
du bénéficiaire
Adresse du cédant
(bénéficiaire)
28. N 30 Nom du tiré Compléter avec des blancs à droite F
29. N 30 Adresse du tiré Compléter avec des blancs à droite F

Références
commerciales du tiré
31. N 01 Code d’acceptation Code acceptation * O
Code endossement et
32. N 01 Code endossement/aval * O
aval
33. N 08 Date d’échéance JJMMAAAA O
Date d’échéance
34. N 08 JJMMAAAA O
initiale
Date de création de la
35. N 08 JJMMAAAA O
lettre de change
Ville ou localité. Compléter avec des
36. N 30 Lieu de création F
blancs à droite
Références
37. N 30 commerciales du Compléter avec des blancs à droite F
tireur
Motif de
38. N 15 représentation. Compléter avec des F
représentation
blancs à droite
39. N 08 Date de règlement JJMMAAAA O


Statut Ebauche
Code acceptation Code endossement et aval
0 : LDC acceptée 0 : Non suivi

1 : LDC non acceptée 1 : Suivi d'un endosseur
2 : Le tireur désire faire présenter la LDC 2 : Suivi d'un avaliseur
à l'acceptation par la banque
3 : Suivi d’un avaliseur et d’un endosseur.
9.5.6.3 Information complémentaire
00 : Intrabancaire. O
Code centre de
2. N 02 01 : Interbancaire national.
compensation
GM = Gambie. O
SL = Sierra Leone.
3. N 02 Code pays
GN = Guinée.
LR = Liberia
Date de O
4. N 08 Date de génération
génération
5. N 06 Heure génération Heure de génération O
6. N 02 Code valeur Code valeurs O

Code participant
remettant
Date de Date de présentation à la O
8. N 08
présentation compensation
Date de
Date de présentation appliquée par le O
9. N 08 présentation
centre de compensation
appliquée
Numéro de la
10. N 07 - O
remise
Code
11. N 02 21 / 22 / 23 / 24 O
enregistrement
270 (GM) /694 (SL) / 324 (GN) /430
(LR)
Statut Ebauche
01 à 20 enregistrements
13. N 02 Rang O
complémentaires
1 : Effet de particulier O
14. N 01 Nature Effet 2 : Effet d’entreprise
3 : Traite de bancaire

Numéro de la
15. N 12 O
lettre de change
Nom ou raison Nom ou raison sociale de l’endosseur
16. N 30 N
sociale ou de l’avaliseur
17. N 30 Adresse - N
Nature de 1 : pièce identité nationale
18. N 01 O
l’identifiant 2 : passeport
Numéro
19. N 15 - O
identifiant
20. N 337 Zone libre N

Statut Ebauche
9.5.7 Transactions Cartes
9.5.7.1 Enregistrement Global
N° Type Longueur Name Description Mandatory
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.

3. N 02 O
LR = Liberia
Date de génération
4. N 08 Date de génération O
JJMMAAAA
Heure de génération
5. N 06 Heure génération O
HHMMSS
Compléter avec des 0 à

7. N 03 Code participant O
gauche
8. N 08 O
appliquée
9. N 08 appliquée par le centre de O
Compléter avec des 0 à

gauche
270 (GM) /694 (SL) / 324

(GN) /430 (LR)
Montant total des Compléter avec des 0 à

13. N 15 O
transactions gauche
Nombre total des Compléter avec des 0 à

14. N 10 O
transactions gauche

Statut Ebauche
Compléter avec des blancs à
droite
Length: 310 characters
9.5.7.2 Enregistrement Détail
N° Type Length Name Description Manda
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.

3. N 02 O
LR = Liberia

8. N 08 O
appliquée
JJMMAAAA
270 (GM) /694 (SL) / 324 (GN)

/430 (LR)
1 : ATM
13. N 01 Type Transaction O
2 : POS
14. N 15 Montant Transaction Compléter avec des 0 à gauche O

Statut Ebauche
15. N 10 Numéro Transaction Compléter avec des 0 à gauche O
16. N 03 Agence remettante Compléter avec des 0 à gauche N
17. N 10 Date Transaction JJMMAAAA O
Numéro de
18. N 15 l'autorisation de la Compléter avec des 0 à gauche O
banque tirée
Code participant
destinataire
Code pays du GM = Gambia.

destinataire
SL = Sierra Leone
20. N 02 O
GN = Guinea
LR = Liberia

21. N 18 RIB Bénéficiaire numéro de compte, clé de contrôle O
compte)

22. N 30 Nom du bénéficiaire N
droite.
23. N 30 adresse du bénéficiaire Compléter avec des blancs à droite N
24. N 12 Référence de la Carte O
Mode de lecture de la
25. N 1 O
carte
Date de début de
26. N 08 O
validité de la carte
Date de fin de validité

27. N 08 O
de la carte
28. N 10 Référence ATM/POS O
Référence du
29. N 12 O
bénéficiaire
Commission Crédit
30. N 01 C : Crédit / D : Débit N
/Débit
Montant de la
31. N 15 N
commission
Uniquement pour les

Motif de
32. N 15 représentations. Compléter avec N
représentation

Statut Ebauche

35. N 25 Free zone Complete with blanks to the right. N
Length: 310
9.5.8 Message libre

Sens
1. N 01 1 / 2 (Envoi / Réception) O
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.
SL = Sierra Leone.
GN = Guinée.
LR = Liberia
Code participant Codes participants. Compléter avec

7. N 03 O
remettant des 0 à gauche
Date de
Date de
présentation
9. N 08 le centre de compensation. O
appliquée
JJMMAAAA
Numéro de la Codes participants. Compléter avec

10. N 07 O
remise des 0 à gauche
Code 11
11. N 02 O
enregistrement

Statut Ebauche
Code devise 270 (GM) /694 (SL) / 324 (GN) /430
12. N 03 O
(LR)
Nombre total de Nombre de messages dans la

13. N 10 messages libres remise. Compléter avec des 0 à O
gauche
Longueur : 200
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.
SL = Sierra Leone.
GN = Guinée.
LR = Liberia

7. N 03 O
8. N 08 O
compensation. JJMMAAAA
appliquée
9. N 08 le centre de compensation. O
JJMMAAAA
11. N 02 Code enregistrement 21 O

Statut Ebauche
Code devise 270 (GM) /694 (SL) / 324 (GN)
12. N 03 O
/430 (LR)
13. N 10 Numéro du message Compléter avec des 0 à gauche O

14. N 03 O
destinataire des 0 à gauche

participant
SL = Sierra Leone.
15. N 02 destinataire O
GN = Guinée.
LR = Liberia
Zone message Zone de saisie de message.

16. N 100 F
Compléter avec des blancs à droite
Longueur : 200 O = Obligatoire / F = facultatif
9.5.9 Avis de Non paiement
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.
SL = Sierra Leone.
GN = Guinée.
LR = Liberia

7. N 03 O
Date de Date de présentation à la

8. N 08 O
présentation compensation JJMMAAAA

Statut Ebauche
Date de Date de présentation appliquée par
9. N 08 présentation le centre de compensation O
appliquée JJMMAAAA
Numéro de la
remise
Code
11. N 02 11 O
enregistrement
270 (GM) /694 (SL) / 324 (GN)

/430 (LR)
Montant total des

13. N 15 avis de non Compléter avec des 0 à gauche
paiement
Nombre total des

14. N 10 avis de non Compléter avec des 0 à gauche O
paiement
Longueur : 370
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.
SL = Sierra Leone.
GN = Guinée.
LR = Liberia
Code participant
remettant

Statut Ebauche
8. N 08 O
Date de présentation appliquée
appliquée
9. N 08 par le centre de compensation O
JJMMAAAA
11. N 02 Code enregistrement 21 O
Code devise 270 (GM) /694 (SL) / 324 (GN) /

12. N 03 O
430 (LR)
Nature de l'ANP 1 pour personne physique,

13. N 01 2 pour personne morale, O
3 autre
Montant du chèque ou Compléter avec des 0 à gauche

14. N 15 O
de l'effet
Numéro de Numéro du chèque ou de l’effet.

l’instrument de
paiement
Code Agence
remettante
17. N 08 Date de Remise JJMMAAAA O
18. N 18 Compte du Tiré O
Code participant
destinataire
GM = Gambie.
Code pays du SL = Sierra Leone.

20. N 02 O
participant destinataire GN = Guinée.
LR = Liberia
21. N 18 compte du bénéfic O
Nom ou raison sociale Compléter avec des blancs à

22. N 30 O
du bénéficiaire droite

23. N 30 Adresse du bénéfic F
droite
Nom ou raison sociale Compléter avec des blancs à

24. N 30 F
du Tiré droite

Statut Ebauche
25. N 30 Adresse du Tiré F
droite
Type identifiant du 1 : pièce identité nationale

26. N 01 O
contrevenant 2 : Passeport
N° de la pièce d'identité du O
contrevenant si personne
N° identifiant du physique
27. N 15
contrevenant
droite
Référence commerciale du Tiré O

Référence commerciale (N° Statistique du contrevenant)
28. N 30 du Tiré (N° Statistique si personne morale
du contrevenant) Compléter avec des blancs à
droite
N 01 Genre du contrevenant M : masculin, F : féminin, I : F

29. indéterminé pour une personne
Morale
N 2 Type du moyen de Pour les chèques : 30 / 33 

30. paiement
Pour les effets : 40 / 43.
31. N 08 chèque où Date de JJMMAAAA O
création de l’effet
32. N 15 Motif de représentation représentation. Compléter avec F
33. N 08 Date de règlement JJMMAAAA O
Code du motif de rejet (4

34. N 08 Motif de rejet motifs). O
35. N 08 Date échéance JJMMAAAA O

droite
Longueur : 370

Statut Ebauche
9.5.10 Attestation de Reconstitution de Provision
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.

3. N 02 O
LR = Liberia

8. N 08 O
appliquée
JJMMAAAA
270 (GM) /694 (SL) / 324 (GN)

/430 (LR)
Montant total des

chèques
Nombre total des

chèques

Statut Ebauche
00 : Intrabancaire.
Code centre de
compensation
GM = Gambie.
SL = Sierra Leone
GN = Guinée
LR = Liberia
Code participant
remettant

appliquée
JJMMAAAA
Référence interne à la banque

10. N 07 Numéro de la remise remettante. Compléter avec des 0 O
à gauche
Code enregistrement
11. N 02 21 / 22 / 23 / 24 O
détail
270 (GM) /694 (SL) / 324 (GN)

/430 (LR)
13. N 15 Montant du chèque - Compléter avec des 0 à gauche O
14. N 15 Montant Ajusté - Compléter avec des 0 à gauche O
15. N 08 Numéro du chèque - Compléter avec des 0 à gauche O
Code Agence
remettante

Statut Ebauche
Date de rejet de l’opération
17. N 08 Date rejet O
JJMMAAAA
18. N 18 Compte du tireur - O
Nom et prénom ou
19. N 30 Compléter avec des blancs à droite O
raison sociale du Tireur
20. N 30 Adresse du Tireur Compléter avec des blancs à droite F
Code participant
destinataire

participant destinataire
SL = Sierra Leone
22. N 02 O
GN = Guinée
LR = Liberia
23. N 18 compte du bénéficiaire O
Nom et prénom ou
24. N 30 raison sociale du Compléter avec des blancs à droite O
bénéficiaire
25. N 30 Adresse du bénéficiaire Compléter avec des blancs à droite F
26. N 08 JJMMAAAA O
chèque
27. N 15 Motif de représentation représentation. Compléter avec des F
blancs à droite



Statut Ebauche
9.5.11 Structures des Remises de rejets techniques
Les fichiers de rejets techniques ont les mêmes structures des fichiers ENV auxquels a
été rajoutée une zone de rejet contenant deux champs : code rejet et libellé rejet. Les
fichiers de rejet techniques ont l’extension RJT.
Structure Longueur Code rejet Libellé rejet Longueur

Remise ENV
RJT
10/13 380 Numérique (5) Alpha -Numérique (70) 455
12 430 Numérique (5) Alpha -Numérique (70) 505

Statut Ebauche
9.5.12 Structures Des Comptes rendus
9.5.12.1 Structure des fichiers compte rendu (CPR/CRS)
9.5.12.1.1 Enregistrement global
N° Type Longueur Désignation Description
1. N 01 Sens 2 : Retour Compensation
Code centre de
2. N 02 01
compensation
GM = Gambie.
SL = Sierra Leone
GN = Guinée
LR = Liberia
4. N 08 Date de génération Date de génération
5. N 06 Heure génération Heure de génération
6. N 02 Code Enregistrement 11
7. N 08 Date valeur
270 (GM) /694 (SL) / 324

8. N 03 Code Devise
(GN) /430 (LR)
9. N 03 Code Banque -
10. N 10 Nombre global des remises Nombre de remises
11. N 15 Montant global des remises Montant des remises
12. N 113 Zone Libre
Longueur 175
9.5.12.1.2 Enregistrement détail
N° Type Longueur Désignation Description
1. N 01 Sens 2 : Retour Compensation
Code centre de
2. N 02 01
compensation

Statut Ebauche
GM = Gambie.
SL = Sierra Leone
GN = Guinée
LR = Liberia
4. N 08 Date de génération Date de génération
5. N 06 Heure génération Heure de génération
6. N 07 N° de la remise Numéro de la remise traitée
7. N 02 Code Enregistrement
8. N 08 Date Compensation
Code valeur de la remise

9. N 02 Codes valeurs
traitée
270 (GM) /694 (SL) / 324

10. N 03 Code Devise
(GN) /430 (LR)
11. N 03 Code Banque -
Date de génération de la
12. N 08 Date de génération
remise
Heure de génération de la
13. N 06 Heure génération
remise
Date et heure d’arrivée de la

14. N 14 Date et heure d’arrivée
remise
Date et heure début Date et heure de contrôle de

15. N 14
traitements la remise
Date et heure fin Date et heure fin traitements

16. N 14
traitements de la remise
Date de présentation Date de présentation calculée

17. N 08
appliquée de la remise
Date de règlement calculée

Date de règlement
18. N 08 par le centre de
appliquée
compensation
1 : Aller compensation
19. N 1 Sens de la remise traitée
2 : Retour compensation
1 : Acceptée ; 2 : Rejetée ;
20. N 01 Etat de contrôle
3 : Acceptée partiellement
Nombre d’opérations Nombre total d’opérations

21. N 10
acceptées acceptées dans la remise

Statut Ebauche
Montant des opérations Montant total des opérations
22. N 15
acceptées acceptées dans la remise
Nombre d’opérations Nombre total d’opérations

23. N 10
rejetées rejetées dans la remise
Montant des opérations Montant total des opérations

24. N 15
rejetées rejetées dans la remise
25. N 07 Zone libre
Longueur : 175
9.5.12.2 Structures des fichiers compte rendu opération (CRO)
Les fichiers de compte rendus CRO ont les mêmes structures des fichiers ENV auxquels a été
rajoutée un statut et un libellé. Les fichiers de compte rendus ont l’extension CRO.
Structure Longueur Statut Libellé Longueur

Remise ENV
CRO
12 430 Numérique (1) Alpha -Numérique (75) 506

Statut Ebauche

Guide Participants ACP-ACH FR 22112013 GN V.1.0.2

Transféré par

Droits d'auteur :

Formats disponibles

Guide Participants ACP-ACH FR 22112013 GN V.1.0.2

Transféré par

Informations du document

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

Guide Participants ACP-ACH FR 22112013 GN V.1.0.2

Transféré par

Droits d'auteur :

Formats disponibles

Rue lac Ghar El Melh

Les berges du lac

Ref.: BFI.WAMI.26062010. GUIPART.1.0.1

Auteur : BFI Date: 26/06/2010

GUIDE DES PARTICIPANTS

Version : 1.0.1 164 pages

Projet Système ACP /ACH Sous Projet Guide Participant

Il ne peut pas être recopié, vendue, ni donné, en totalité ou par

Projet Système ACP /ACH Sous Projet Guide Participant

RÉDACTEURS VÉRIFICATEURS APPROBATEURS

NOM ET PRÉNOM DATE NOM ET PRÉNOM DATE NOM ET PRÉNOM DATE

BFI 26/06/2010 BFI WAMI

POUR ACTION POUR INFORMATION

Equipe projet Banque de Banque de

Equipe projet Banque Banque Centrale

Historique des versions

Version Rédacteur Commentaires

1.0.0 BFI Rédaction du document

- Mise à jour du planning de mise en œuvre (page

Projet Système ACP /ACH Sous Projet Guide Participant

Projet Système ACP /ACH Sous Projet Guide Participant

Projet Système ACP /ACH Sous Projet Guide Participant

Ce document expose les éléments suivants :

 Normes et formats d’échange

 Description fonctionnelle des modules de la solution

 Etapes et planning du projet

 Pré-requis des participants

1.1 DÉFINITIONS COMMUNES

ACP Automated Cheque Processing: traitement automatisé des

ACH Automated Clearing House: Chambre de compensation

ADT Automatic Data Processing : Permet le traitement automatique

Adresse IP Champ numérique propre à chaque machine lui servant

Algorithme Algorithme qui permet le cryptage des données et des images

Algorithme symétrique Algorithme qui permet le cryptage et le décryptage avec la

Altération Modification ou perte des données d'une image chèque ou lettre

Projet Système ACP /ACH Sous Projet Guide Participant

Authentification Opération de vérification de l'intégrité d'une image chèque ou

Bac de rejet Emplacement au niveau du scanner où seront acheminées les

Bac principal Emplacement au niveau du scanner où seront acheminées les

Banque destinataire La contrepartie de la banque remettante, i.e. celle dont le

Banque présentatrice Banque qui présente la remise au système de compensation. Elle

BDD Base de données.

Bourrage Blocage d'un chèque/ lettre de change dans le scanner lors de sa

Capture Scannérisation de l'image recto et verso du chèque / lettre de

CIP Centrale des incidents de paiements.

Projet Système ACP /ACH Sous Projet Guide Participant

Clé courante Clé valide servant à la signature ou à l’authentification des

Clé privée Clé secrète de signature que seul l'expéditeur connaît.

Clé publique Clé d’authentification connue par tous les correspondants.

Collecte Récupération, par l’Autocollecte, des remises et des informations

Condensé Chaîne de caractères qui représentent le document haché.

Confrontation Opération de comparaison de deux chaînes de caractères.

Contrôle bloquant Contrôle qui en cas d’échec, engendre le blocage de l’opération

Cryptage Procédé mathématique qui transforme un message d'origine en

Projet Système ACP /ACH Sous Projet Guide Participant

Délai de règlement DDR - Nombre de jours ouvrés entre le jour de la présentation

Délai de rejet Nombre de jours ouvrés, depuis la date de remise en

Doubles Deux chèques/ lettres de change qui passent en même temps

Endossement Ecriture d'un texte sur l'endos de la valeur physique.

Enregistrement Ensemble des données à échanger d’une façon électronique