Document d'Architecture Technique (DAT)

Produit Cash Pooling - MVP

Version: 1.0
Date: Fevrier 2026
Classification: Document technique interne
Statut: Initial

Table des matieres

Introduction et contexte
Vue d'architecture globale
Responsabilites par composant
Modele de donnees canonique
Fonctionnement batch et regles metier
Points non couverts volontairement
Annexes

1. Introduction et contexte

1.1 Objet du document

Ce Document d'Architecture Technique (DAT) decrit l'architecture du produit Cash Pooling, un systeme de centralisation de tresorerie destine aux groupes d'entreprises clientes d'etablissements bancaires. Le produit permet d'optimiser les besoins et excedents de tresorerie par un equilibrage automatise des soldes entre comptes secondaires et un compte centralisateur.

1.2 Perimetre MVP

Le MVP (Minimum Viable Product) couvre exclusivement le Cash Pooling Direct avec les trois modes de nivellement suivants:

ZBA (Zero Balance Account): Ramene les comptes sources a un solde nul
TBA (Target Balance Account): Maintient un seuil cible sur les comptes sources
FBA (Fork Balance Account): Maintient le solde dans un intervalle defini (seuil min/max)

1.3 Principes directeurs

Le produit repose sur les principes architecturaux suivants:

Agnosticisme CBS: Le produit est concu pour fonctionner avec plusieurs Core Banking Systems sans modification de son noyau metier. L'adaptation a chaque CBS se fait exclusivement via les adaptateurs d'entree et de sortie.

Architecture batch-driven: L'ensemble des traitements s'execute en mode batch. Il n'existe pas d'orchestrateur applicatif; la planification est assuree par des outils techniques externes (scheduler, cron, Control-M).

Modele de donnees canonique: Toutes les donnees transitent par un modele normalise, independant des formats specifiques de chaque CBS.

Separation des responsabilites: Chaque composant possede un perimetre fonctionnel clairement delimite, sans chevauchement.

2. Vue d'architecture globale

2.1 Diagramme logique des composants

+------------------+     +---------------------------+     +------------------+
|                  |     |                           |     |                  |
|   INPUT BATCH    |     |    CASH POOLING CORE      |     |   OUTPUT BATCH   |
|   (Adapter IN)   |     |        (Noyau)            |     |   (Adapter OUT)  |
|                  |     |                           |     |                  |
+------------------+     +---------------------------+     +------------------+
        |                           |                              |
        v                           v                              v
+------------------+     +---------------------------+     +------------------+
| - Lecture CBS    |     | - Gestion des contrats    |     | - Transformation |
| - Parsing MT940  |     | - Moteur ZBA/TBA/FBA      |     | - Generation     |
| - Normalisation  |     | - Regles d'eligibilite    |     |   ecritures      |
| - Validation     |     | - Calcul mouvements       |     | - Injection CBS  |
+------------------+     +---------------------------+     +------------------+
        |                           |                              |
        v                           v                              v
+-----------------------------------------------------------------------+
|                                                                       |
|                    MODELE DE DONNEES CANONIQUE                        |
|                                                                       |
|   Contract | Account | Balance | Operation | PoolingRule |            |
|   PoolingMovement | ExecutionContext                                  |
|                                                                       |
+-----------------------------------------------------------------------+

2.2 Flux batch global

Le traitement Cash Pooling s'execute selon le flux sequentiel suivant:

[CBS Source]                                                    [CBS Cible]
     |                                                               ^
     v                                                               |
+----------+    +----------+    +----------+    +----------+    +----------+
|          |    |          |    |          |    |          |    |          |
| Fichiers |--->| INPUT    |--->| POOLING  |--->| OUTPUT   |--->| Fichiers |
| MT940    |    | BATCH    |    | CORE     |    | BATCH    |    | Ecritures|
|          |    |          |    |          |    |          |    |          |
+----------+    +----------+    +----------+    +----------+    +----------+
                     |               |               |
                     v               v               v
                +---------------------------------------+
                |        Base de donnees locale        |
                |     (Modele canonique persiste)      |
                +---------------------------------------+

2.3 Positionnement des adaptateurs CBS

Les adaptateurs constituent la couche d'abstraction entre le produit Cash Pooling et les differents Core Banking Systems. Leur positionnement garantit l'independance du noyau metier.

+-------------+     +-------------+     +-------------+
|   CBS A     |     |   CBS B     |     |   CBS C     |
| (ex: T24)   |     | (ex: Flexcube)    | (ex: SAB)   |
+-------------+     +-------------+     +-------------+
      |                   |                   |
      v                   v                   v
+-------------+     +-------------+     +-------------+
| Adapter IN  |     | Adapter IN  |     | Adapter IN  |
|    CBS A    |     |    CBS B    |     |    CBS C    |
+-------------+     +-------------+     +-------------+
      |                   |                   |
      +-------------------+-------------------+
                          |
                          v
              +------------------------+
              |   MODELE CANONIQUE     |
              +------------------------+
                          |
                          v
              +------------------------+
              |  CASH POOLING CORE     |
              +------------------------+
                          |
                          v
              +------------------------+
              |   MODELE CANONIQUE     |
              +------------------------+
                          |
      +-------------------+-------------------+
      |                   |                   |
      v                   v                   v
+-------------+     +-------------+     +-------------+
| Adapter OUT |     | Adapter OUT |     | Adapter OUT |
|    CBS A    |     |    CBS B    |     |    CBS C    |
+-------------+     +-------------+     +-------------+
      |                   |                   |
      v                   v                   v
+-------------+     +-------------+     +-------------+
|   CBS A     |     |   CBS B     |     |   CBS C     |
+-------------+     +-------------+     +-------------+

3. Responsabilites par composant

3.1 Input Batch (Adapter IN)

Role: Composant d'acquisition et de normalisation des donnees en provenance du Core Banking System.

Responsabilites:

Responsabilite	Description
Lecture des fichiers CBS	Recuperation des fichiers de soldes et mouvements (format MT940 ou equivalent) depuis le repertoire d'echange
Parsing et extraction	Interpretation du format specifique CBS et extraction des donnees brutes
Validation technique	Controle de l'integrite des fichiers (checksum, structure, completude)
Normalisation	Transformation des donnees vers le modele canonique
Persistence	Ecriture des donnees normalisees dans la base locale
Gestion des erreurs	Journalisation des anomalies et generation d'alertes

Ce que fait ce composant:

Lit les fichiers MT940 ou equivalents deposes par le CBS
Valide la structure et l'integrite des fichiers recus
Extrait les soldes de cloture (J-1) et les operations du jour (J)
Convertit les donnees au format canonique
Persiste les comptes, soldes et operations dans la base locale
Genere un rapport d'execution (fichiers traites, rejetes, statistiques)

Ce que ne fait pas ce composant:

Aucune logique metier Cash Pooling
Aucun calcul de nivellement
Aucune decision d'eligibilite
Aucun acces direct au CBS (lecture fichiers uniquement)
Aucune generation d'ecritures comptables

3.2 Cash Pooling Core (Noyau)

Role: Composant central contenant l'ensemble de la logique metier Cash Pooling.

Responsabilites:

Responsabilite	Description
Gestion des contrats	Stockage et maintenance des contrats Cash Pooling (creation, modification, suspension, suppression logique)
Evaluation de l'eligibilite	Determination des comptes et contrats eligibles au traitement du jour
Moteur de nivellement	Implementation des algorithmes ZBA, TBA et FBA
Calcul des mouvements	Production des mouvements de nivellement a executer
Gestion des seuils	Application des seuils TBA et des intervalles FBA
Gestion de la hierarchie	Traitement des structures multi-niveaux (comptes parents/enfants)
Contexte d'execution	Suivi des dates de passage et etats de traitement

Ce que fait ce composant:

Charge les contrats actifs depuis la base locale
Verifie l'eligibilite de chaque contrat selon la periodicite configuree
Recupere les soldes et operations normalises
Applique les regles de nivellement selon le mode (ZBA/TBA/FBA) et le type de transfert (Solde/Date valeur/Operation)
Calcule les mouvements de nivellement en respectant la hierarchie des comptes
Persiste les mouvements calcules (PoolingMovement)
Met a jour le contexte d'execution (date dernier passage)
Gere les cas de non-eligibilite (aucun mouvement produit)

Ce que ne fait pas ce composant:

Aucune lecture directe de fichiers CBS
Aucune generation de fichiers d'ecritures
Aucune communication avec le CBS
Aucune transformation de format
Aucune gestion de l'interface utilisateur

3.3 Output Batch (Adapter OUT)

Role: Composant de transformation et d'injection des mouvements Cash Pooling vers le Core Banking System.

Responsabilites:

Responsabilite	Description
Lecture des mouvements	Recuperation des mouvements calcules par le noyau
Transformation	Conversion du format canonique vers le format CBS cible
Generation des ecritures	Production des fichiers d'ecritures/virements au format attendu par le CBS
Depot des fichiers	Ecriture des fichiers dans le repertoire d'echange CBS
Gestion des statuts	Mise a jour des statuts des mouvements (genere, injecte, en erreur)
Gestion des retours	Traitement des acquittements CBS (si applicable)

Ce que fait ce composant:

Lit les mouvements de nivellement en statut "a traiter"
Transforme chaque mouvement en ecriture comptable au format CBS
Genere les fichiers d'injection (virements, ecritures)
Depose les fichiers dans le repertoire d'echange CBS
Met a jour le statut des mouvements traites
Genere un rapport d'execution (mouvements traites, rejetes)

Ce que ne fait pas ce composant:

Aucune logique metier Cash Pooling
Aucun calcul de nivellement
Aucune decision d'eligibilite
Aucune modification des contrats
Aucune lecture de fichiers CBS entrants

4. Modele de donnees canonique

4.1 Vue d'ensemble

Le modele de donnees canonique constitue le socle commun a tous les composants du produit. Il est concu pour etre stable, independant du CBS, et suffisamment expressif pour couvrir l'ensemble des cas metier du Cash Pooling Direct.

+---------------+       +---------------+       +---------------+
|   Contract    |1     *|    Account    |1     *|    Balance    |
+---------------+-------+---------------+-------+---------------+
| contractId    |       | accountId     |       | balanceId     |
| clientCode    |       | contractId    |       | accountId     |
| clientRef     |       | accountNumber |       | balanceDate   |
| companyName   |       | accountType   |       | closingBalance|
| rcNumber      |       | parentAccount |       | availableBalance|
| address       |       | mirrorAccount |       | currency      |
| levelingType  |       | customLabel   |       | createdAt     |
| levelingMode  |       | status        |       +---------------+
| transferType  |       | createdAt     |
| ...           |       +---------------+
+---------------+              |1
       |1                      |
       |                       |*
       |*              +---------------+
+---------------+      |   Operation   |
|  PoolingRule  |      +---------------+
+---------------+      | operationId   |
| ruleId        |      | accountId     |
| contractId    |      | operationDate |
| accountId     |      | valueDate     |
| thresholdTBA  |      | amount        |
| thresholdFBA1 |      | currency      |
| thresholdFBA2 |      | direction     |
| thresholdFBAUser|    | label         |
| transferPeriod|      | externalRef   |
| transferDay   |      | createdAt     |
| ...           |      +---------------+
+---------------+
       |1
       |
       |*
+-------------------+       +-------------------+
|  PoolingMovement  |       | ExecutionContext  |
+-------------------+       +-------------------+
| movementId        |       | contextId         |
| contractId        |       | contractId        |
| sourceAccountId   |       | executionDate     |
| targetAccountId   |       | lastProcessingDate|
| amount            |       | lastDrainDate     |
| valueDate         |       | status            |
| movementType      |       | errorMessage      |
| status            |       | createdAt         |
| createdAt         |       | updatedAt         |
| processedAt       |       +-------------------+
+-------------------+

4.2 Entite Contract

L'entite Contract represente le contrat Cash Pooling souscrit par un groupe d'entreprises. Un groupe ne peut disposer que d'un seul contrat actif.

Attribut	Type	Obligatoire	Description
contractId	UUID	Oui	Identifiant unique du contrat (genere automatiquement)
contractNumber	VARCHAR(20)	Oui	Numero de contrat metier (genere et incremente automatiquement)
clientCode	VARCHAR(20)	Oui	Code tiers du client
clientRef	VARCHAR(50)	Oui	Reference tiers GRC
companyName	VARCHAR(100)	Oui	Raison sociale du groupe
rcNumber	VARCHAR(30)	Oui	Numero de Registre du Commerce
address	VARCHAR(255)	Oui	Adresse du client
levelingType	ENUM	Oui	Type de nivellement: DIRECT, INDIRECT
levelingMode	ENUM	Oui	Mode de nivellement: ZBA, TBA, FBA
transferType	ENUM	Oui	Type de transfert: BALANCE, VALUE_DATE, OPERATION
transferPeriodicity	ENUM	Oui	Periodicite: DAILY, WEEKLY, MONTHLY, QUARTERLY, SEMI_ANNUAL, ANNUAL
transferDays	VARCHAR(20)	Conditionnel	Jours de transfert (ex: "1,2,3,4,5" pour quotidien)
monthlyTransferDay	INTEGER	Conditionnel	Jour du mois (1-28) si periodicite mensuelle
quarterlyDates	VARCHAR(50)	Conditionnel	4 dates JJ/MM si periodicite trimestrielle
semiAnnualDates	VARCHAR(30)	Conditionnel	2 dates JJ/MM si periodicite semestrielle
annualDate	VARCHAR(10)	Conditionnel	1 date JJ/MM si periodicite annuelle
masterAccountId	UUID	Oui	Reference vers le compte centralisateur
billingAccountId	UUID	Oui	Reference vers le compte de facturation
billingType	ENUM	Oui	Type de tarification: FLAT_FEE, PER_ACCOUNT
billingAmount	DECIMAL(15,2)	Oui	Montant de la tarification
billingPeriodicity	ENUM	Oui	Periodicite paiement: MONTHLY, QUARTERLY, ANNUAL
alertEmail1	VARCHAR(100)	Oui	Email principal pour les alertes
alertEmail2	VARCHAR(100)	Non	Email secondaire pour les alertes
effectiveStartDate	DATE	Oui	Date effective de demarrage
status	ENUM	Oui	Statut: ACTIVE, SUSPENDED, DELETED
version	INTEGER	Oui	Version du contrat (incrementee a chaque modification)
createdAt	TIMESTAMP	Oui	Date de creation
updatedAt	TIMESTAMP	Oui	Date de derniere modification

Contraintes metier:

Un seul contrat actif par groupe (unicite sur clientCode + status=ACTIVE)
levelingType=INDIRECT implique levelingMode=ZBA uniquement (hors scope MVP)
levelingMode=FBA implique transferType=BALANCE uniquement
levelingMode=TBA implique transferType in (BALANCE, OPERATION)
Periodicite > DAILY implique levelingMode=ZBA et transferType=BALANCE

4.3 Entite Account

L'entite Account represente un compte bancaire participant au Cash Pooling.

Attribut	Type	Obligatoire	Description
accountId	UUID	Oui	Identifiant unique du compte
contractId	UUID	Oui	Reference vers le contrat
accountNumber	VARCHAR(30)	Oui	Numero de compte bancaire
accountType	ENUM	Oui	Type: MASTER (centralisateur), SOURCE, INTERMEDIATE
parentAccountId	UUID	Conditionnel	Reference vers le compte parent (si structure hierarchique)
mirrorAccountId	UUID	Conditionnel	Reference vers le compte miroir (Cash Pooling Indirect - hors scope)
customLabel	VARCHAR(14)	Non	Libelle personnalise (max 14 caracteres)
currency	VARCHAR(3)	Oui	Code devise ISO (ex: MAD, EUR)
status	ENUM	Oui	Statut: ACTIVE, SUSPENDED, DELETED
createdAt	TIMESTAMP	Oui	Date de creation
updatedAt	TIMESTAMP	Oui	Date de derniere modification

Contraintes metier:

Un contrat possede exactement un compte de type MASTER
Un contrat possede au moins un compte de type SOURCE
Un compte SOURCE peut avoir un compte parent (INTERMEDIATE ou MASTER)
Un compte n'appartient qu'a une seule branche de la hierarchie
accountType=MASTER implique parentAccountId=NULL

4.4 Entite Balance

L'entite Balance represente le solde d'un compte a une date donnee.

Attribut	Type	Obligatoire	Description
balanceId	UUID	Oui	Identifiant unique du solde
accountId	UUID	Oui	Reference vers le compte
balanceDate	DATE	Oui	Date du solde (J-1 pour solde de cloture)
closingBalance	DECIMAL(18,2)	Oui	Solde de cloture
availableBalance	DECIMAL(18,2)	Non	Solde disponible (si different du solde de cloture)
currency	VARCHAR(3)	Oui	Code devise ISO
source	VARCHAR(50)	Oui	Source de la donnee (ex: MT940, CBS_DIRECT)
createdAt	TIMESTAMP	Oui	Date de creation

Contraintes metier:

Unicite sur (accountId, balanceDate)
Le solde de cloture J-1 est utilise pour le calcul du nivellement a J

4.5 Entite Operation

L'entite Operation represente un mouvement comptable sur un compte.

Attribut	Type	Obligatoire	Description
operationId	UUID	Oui	Identifiant unique de l'operation
accountId	UUID	Oui	Reference vers le compte
operationDate	DATE	Oui	Date d'operation
valueDate	DATE	Oui	Date de valeur
amount	DECIMAL(18,2)	Oui	Montant (positif ou negatif)
currency	VARCHAR(3)	Oui	Code devise ISO
direction	ENUM	Oui	Sens: CREDIT, DEBIT
label	VARCHAR(140)	Non	Libelle de l'operation
externalRef	VARCHAR(50)	Non	Reference externe CBS
source	VARCHAR(50)	Oui	Source de la donnee
createdAt	TIMESTAMP	Oui	Date de creation

Contraintes metier:

Les operations du jour J sont utilisees pour le nivellement par operation ou par date valeur
Le regroupement par date valeur est effectue pour le transfert par VALUE_DATE

4.6 Entite PoolingRule

L'entite PoolingRule represente les regles de nivellement specifiques a un compte dans le cadre d'un contrat.

Attribut	Type	Obligatoire	Description
ruleId	UUID	Oui	Identifiant unique de la regle
contractId	UUID	Oui	Reference vers le contrat
accountId	UUID	Oui	Reference vers le compte source
thresholdTBA	DECIMAL(18,2)	Conditionnel	Seuil TBA (obligatoire si mode=TBA)
thresholdFBA1	DECIMAL(18,2)	Conditionnel	Seuil minimum FBA (obligatoire si mode=FBA)
thresholdFBA2	DECIMAL(18,2)	Conditionnel	Seuil maximum FBA (obligatoire si mode=FBA)
thresholdFBAUser	DECIMAL(18,2)	Conditionnel	Seuil cible FBA (obligatoire si mode=FBA)
isActive	BOOLEAN	Oui	Indicateur d'activation de la regle
createdAt	TIMESTAMP	Oui	Date de creation
updatedAt	TIMESTAMP	Oui	Date de derniere modification

Contraintes metier:

Une regle par couple (contractId, accountId)
thresholdFBA1 < thresholdFBAUser < thresholdFBA2
Modification du seuil TBA implique redemarrage de la branche

4.7 Entite PoolingMovement

L'entite PoolingMovement represente un mouvement de nivellement calcule par le moteur Cash Pooling.

Attribut	Type	Obligatoire	Description
movementId	UUID	Oui	Identifiant unique du mouvement
contractId	UUID	Oui	Reference vers le contrat
sourceAccountId	UUID	Oui	Compte source du mouvement
targetAccountId	UUID	Oui	Compte cible du mouvement (parent ou centralisateur)
amount	DECIMAL(18,2)	Oui	Montant du mouvement
currency	VARCHAR(3)	Oui	Code devise ISO
valueDate	DATE	Oui	Date de valeur du mouvement
operationDate	DATE	Oui	Date d'operation
movementType	ENUM	Oui	Type: BALANCE_TRANSFER, VALUE_DATE_TRANSFER, OPERATION_TRANSFER
levelingMode	ENUM	Oui	Mode applique: ZBA, TBA, FBA
originalOperationId	UUID	Conditionnel	Reference vers l'operation d'origine (si transfert par operation)
status	ENUM	Oui	Statut: PENDING, GENERATED, INJECTED, ERROR, CANCELLED
errorMessage	VARCHAR(500)	Non	Message d'erreur si status=ERROR
createdAt	TIMESTAMP	Oui	Date de creation
processedAt	TIMESTAMP	Non	Date de traitement par l'Output Batch

Contraintes metier:

Un mouvement est toujours du compte source vers son compte parent ou centralisateur
Le montant peut etre positif (transfert vers centralisateur) ou negatif (transfert depuis centralisateur)
Les mouvements en statut PENDING sont traites par l'Output Batch

4.8 Entite ExecutionContext

L'entite ExecutionContext represente le contexte d'execution du Cash Pooling pour un contrat.

Attribut	Type	Obligatoire	Description
contextId	UUID	Oui	Identifiant unique du contexte
contractId	UUID	Oui	Reference vers le contrat
executionDate	DATE	Oui	Date d'execution du batch
lastProcessingDate	DATE	Non	Date du dernier traitement Cash Pooling
lastDrainDate	DATE	Non	Date du dernier vidage de compte miroir (hors scope)
lastBillingDate	DATE	Non	Date du dernier prelevement de tarification
status	ENUM	Oui	Statut: SUCCESS, PARTIAL, FAILED, SKIPPED
processedAccounts	INTEGER	Oui	Nombre de comptes traites
generatedMovements	INTEGER	Oui	Nombre de mouvements generes
errorMessage	VARCHAR(500)	Non	Message d'erreur si status=FAILED
createdAt	TIMESTAMP	Oui	Date de creation
updatedAt	TIMESTAMP	Oui	Date de derniere modification

Contraintes metier:

Un contexte par couple (contractId, executionDate)
lastProcessingDate est utilise pour determiner les jours a niveler (periodicite hebdomadaire)
status=SKIPPED indique un contrat non eligible a la date d'execution

5. Fonctionnement batch et regles metier

5.1 Cycle de traitement global

Le traitement Cash Pooling s'execute quotidiennement selon le cycle suivant:

+-------------------------------------------------------------------+
|                    CYCLE DE TRAITEMENT QUOTIDIEN                  |
+-------------------------------------------------------------------+
|                                                                   |
|  [1] INPUT BATCH                                                  |
|      |                                                            |
|      +-- Lecture fichiers MT940 (soldes J-1, operations J)        |
|      +-- Validation et normalisation                              |
|      +-- Persistence dans le modele canonique                     |
|                                                                   |
|  [2] CASH POOLING CORE                                            |
|      |                                                            |
|      +-- Chargement des contrats actifs                           |
|      +-- Pour chaque contrat:                                     |
|          |                                                        |
|          +-- Evaluation de l'eligibilite (periodicite, jour)      |
|          |                                                        |
|          +-- Si eligible:                                         |
|          |   +-- Recuperation soldes et operations                |
|          |   +-- Application des regles de nivellement            |
|          |   +-- Calcul des mouvements                            |
|          |   +-- Persistence des mouvements                       |
|          |                                                        |
|          +-- Si non eligible:                                     |
|              +-- Journalisation (aucun mouvement produit)         |
|                                                                   |
|      +-- Mise a jour du contexte d'execution                      |
|                                                                   |
|  [3] OUTPUT BATCH                                                 |
|      |                                                            |
|      +-- Lecture des mouvements en statut PENDING                 |
|      +-- Transformation au format CBS                             |
|      +-- Generation des fichiers d'ecritures                      |
|      +-- Depot dans le repertoire d'echange                       |
|      +-- Mise a jour des statuts                                  |
|                                                                   |
+-------------------------------------------------------------------+

5.2 Regles d'eligibilite

L'eligibilite d'un contrat au traitement du jour est determinee par les regles suivantes:

Conditions prealables:

Le contrat doit etre en statut ACTIVE
La date d'execution doit etre >= date effective de demarrage
Les donnees (soldes, operations) doivent etre disponibles

Evaluation selon la periodicite:

Periodicite	Condition d'eligibilite
DAILY	Eligible tous les jours ouvres (selon transferDays)
WEEKLY	Eligible si le jour courant correspond a transferDays
MONTHLY	Eligible si le jour courant = monthlyTransferDay
QUARTERLY	Eligible si la date courante correspond a une des 4 dates quarterlyDates
SEMI_ANNUAL	Eligible si la date courante correspond a une des 2 dates semiAnnualDates
ANNUAL	Eligible si la date courante correspond a annualDate

Cas de non-eligibilite:

Le batch s'execute mais ne produit aucun mouvement
Le contexte d'execution est mis a jour avec status=SKIPPED
Aucune erreur n'est generee

5.3 Algorithmes de nivellement

5.3.1 ZBA (Zero Balance Account)

Objectif: Ramener le solde du compte source a zero.

ZBA par Solde:

Pour chaque compte source (du niveau le plus bas vers le centralisateur):
    solde_J = recuperer_solde(compte_source, date_J)
    Si solde_J != 0:
        mouvement = creer_mouvement(
            source = compte_source,
            cible = compte_parent ou centralisateur,
            montant = solde_J,
            type = BALANCE_TRANSFER
        )
        persister(mouvement)

ZBA par Date Valeur:

Pour chaque compte source:
    solde_J1 = recuperer_solde(compte_source, date_J-1)
    operations_J = recuperer_operations(compte_source, date_J)
    
    # Nivellement du solde J-1
    Si solde_J1 != 0:
        mouvement_solde = creer_mouvement(montant = solde_J1)
        persister(mouvement_solde)
    
    # Nivellement des operations groupees par date valeur
    Pour chaque date_valeur dans operations_J:
        total = somme(operations_J.filtrer(date_valeur))
        mouvement_dv = creer_mouvement(
            montant = total,
            date_valeur = date_valeur,
            type = VALUE_DATE_TRANSFER
        )
        persister(mouvement_dv)

ZBA par Operation:

Pour chaque compte source:
    solde_J1 = recuperer_solde(compte_source, date_J-1)
    operations_J = recuperer_operations(compte_source, date_J)
    
    # Nivellement du solde J-1 (au demarrage)
    Si est_demarrage:
        mouvement_solde = creer_mouvement(montant = solde_J1)
        persister(mouvement_solde)
    
    # Nivellement de chaque operation
    Pour chaque operation dans operations_J:
        mouvement_op = creer_mouvement(
            montant = operation.montant,
            date_valeur = operation.date_valeur,
            type = OPERATION_TRANSFER,
            operation_origine = operation.id
        )
        persister(mouvement_op)

5.3.2 TBA (Target Balance Account)

Objectif: Maintenir un seuil cible sur le compte source.

TBA par Solde:

Pour chaque compte source:
    solde_J = recuperer_solde(compte_source, date_J)
    seuil = recuperer_seuil_TBA(compte_source)
    
    ecart = solde_J - seuil
    Si ecart != 0:
        mouvement = creer_mouvement(
            source = compte_source,
            cible = compte_parent ou centralisateur,
            montant = ecart,
            type = BALANCE_TRANSFER
        )
        persister(mouvement)
    # Resultat: solde final = seuil

TBA par Operation:

Pour chaque compte source:
    seuil = recuperer_seuil_TBA(compte_source)
    
    # Au demarrage: atteindre le seuil
    Si est_demarrage:
        solde_J1 = recuperer_solde(compte_source, date_J-1)
        ecart = solde_J1 - seuil
        mouvement_seuil = creer_mouvement(montant = ecart)
        persister(mouvement_seuil)
    
    # Nivellement des operations du jour
    operations_J = recuperer_operations(compte_source, date_J)
    Pour chaque operation dans operations_J:
        mouvement_op = creer_mouvement(
            montant = operation.montant,
            type = OPERATION_TRANSFER
        )
        persister(mouvement_op)

5.3.3 FBA (Fork Balance Account)

Objectif: Maintenir le solde dans un intervalle [seuil1, seuil2].

FBA par Solde:

Pour chaque compte source:
    solde_J = recuperer_solde(compte_source, date_J)
    seuil1 = recuperer_seuil_FBA1(compte_source)  # minimum
    seuil2 = recuperer_seuil_FBA2(compte_source)  # maximum
    seuil_cible = recuperer_seuil_FBA_user(compte_source)
    
    Si solde_J < seuil1:
        # Solde insuffisant: transfert depuis le centralisateur
        ecart = seuil_cible - solde_J
        mouvement = creer_mouvement(
            source = centralisateur,
            cible = compte_source,
            montant = ecart
        )
    Sinon Si solde_J > seuil2:
        # Solde excessif: transfert vers le centralisateur
        ecart = solde_J - seuil_cible
        mouvement = creer_mouvement(
            source = compte_source,
            cible = centralisateur,
            montant = ecart
        )
    Sinon:
        # Solde dans l'intervalle: aucun mouvement
        rien
    
    Si mouvement existe:
        persister(mouvement)

5.4 Gestion de la hierarchie multi-niveaux

Le nivellement s'effectue toujours du niveau le plus bas vers le centralisateur:

Niveau 0: Compte Centralisateur (Master)
              |
Niveau 1: Comptes Intermediaires
              |
Niveau 2: Comptes Sources (feuilles)

Ordre de traitement:

Identifier tous les comptes sans enfants (feuilles)
Niveler ces comptes vers leur parent
Remonter d'un niveau et repeter jusqu'au centralisateur

Regle fondamentale: Un compte parent ne peut etre nivele qu'apres tous ses comptes enfants.

5.5 Cas particuliers

Demarrage de contrat:

Le premier nivellement inclut le solde de cloture J-1
Pour TBA: le seuil est atteint des le premier traitement
La date de demarrage effectif est enregistree

Redemarrage de branche:

Declenche par modification de: nivellement, mode, type transfert, seuils, comptes
Le traitement reprend comme un demarrage initial
L'historique des mouvements precedents est conserve

Suspension de contrat/branche:

Les comptes suspendus sont exclus du traitement
La suspension d'un compte implique la suspension de toute sa branche descendante
Aucun mouvement n'est genere pour les comptes suspendus

Absence de donnees:

Si les soldes/operations ne sont pas disponibles, le contrat est marque en erreur
Une alerte est envoyee aux adresses email configurees
Le traitement des autres contrats continue

6. Points non couverts volontairement

Ce DAT exclut explicitement les elements suivants du perimetre MVP:

6.1 Cash Pooling Indirect

Le Cash Pooling Indirect, qui utilise des comptes miroirs pour isoler les ecritures Cash Pooling des operations courantes, n'est pas couvert par ce MVP. Cette fonctionnalite implique:

La gestion des comptes miroirs
Le vidage automatique et manuel des comptes miroirs
Les regles specifiques de nivellement indirect

Raison de l'exclusion: Complexite additionnelle significative, cas d'usage moins frequent.

6.2 Traitement temps reel

Le produit fonctionne exclusivement en mode batch. Les fonctionnalites temps reel suivantes sont exclues:

Nivellement intra-journalier
Notifications en temps reel
API synchrones de declenchement
Integration evenementielle avec le CBS

Raison de l'exclusion: Le mode batch repond aux besoins metier identifies et simplifie l'architecture.

6.3 Orchestration applicative

Il n'existe pas d'orchestrateur applicatif dans le produit. Les aspects suivants sont exclus:

Workflow de validation des contrats
Enchainement conditionnel des batchs
Gestion des dependances entre traitements
Reprise automatique sur erreur

Raison de l'exclusion: La planification est assuree par des outils externes (Control-M, cron). Les decisions metier sont prises dans le moteur Cash Pooling.

6.4 Reporting avance

Le reporting avance est hors scope MVP:

Tableaux de bord interactifs
Rapports personnalisables
Export multi-format (PDF, Excel avance)
Historique detaille des mouvements
Statistiques et indicateurs de performance

Raison de l'exclusion: Fonctionnalite prevue pour un lot ulterieur (LOT 2).

6.5 Interface utilisateur

L'interface utilisateur de gestion des contrats n'est pas couverte par ce DAT:

Ecrans de creation/modification de contrats
Consultation et recherche
Gestion des suspensions/suppressions
Authentification et habilitations (SAS)

Raison de l'exclusion: Ce DAT se concentre sur l'architecture technique du moteur batch. L'IHM fera l'objet d'un document separe.

6.6 Tarification

Le module de tarification (prelevement des frais de gestion) n'est pas detaille:

Calcul des frais par forfait ou par compte
Prelevement automatique selon periodicite
Gestion des premieres echeances

Raison de l'exclusion: Module annexe au Cash Pooling, traite separement.

7. Annexes

7.1 Glossaire

Terme	Definition
CBS	Core Banking System - Systeme bancaire central
Cash Pooling	Technique de centralisation de tresorerie
Compte Centralisateur	Compte principal (Master Account) recevant les fonds
Compte Source	Compte secondaire participant au nivellement
Compte Intermediaire	Compte servant de relais dans une structure multi-niveaux
Compte Miroir	Compte fictif utilise en Cash Pooling Indirect
ZBA	Zero Balance Account - Nivellement a solde nul
TBA	Target Balance Account - Nivellement a seuil cible
FBA	Fork Balance Account - Nivellement a intervalle
MT940	Format SWIFT standard pour les releves de compte
Nivellement	Action de transfert des fonds entre comptes
Periodicite	Frequence d'execution du nivellement

7.2 Combinaisons valides Mode/Type de transfert

Mode	Solde	Date Valeur	Operation
ZBA	Oui	Oui	Oui
TBA	Oui	Non	Oui
FBA	Oui	Non	Non

7.3 Contraintes de periodicite

Periodicite	Modes autorises	Types de transfert autorises
Quotidienne	ZBA, TBA, FBA	Tous selon le mode
Hebdomadaire	ZBA, TBA, FBA	Tous selon le mode
Mensuelle	ZBA uniquement	Solde uniquement
Trimestrielle	ZBA uniquement	Solde uniquement
Semestrielle	ZBA uniquement	Solde uniquement
Annuelle	ZBA uniquement	Solde uniquement

7.4 Diagramme de sequence - Traitement ZBA par Solde

Scheduler       InputBatch      Database        PoolingCore     OutputBatch      CBS
    |               |               |               |               |             |
    |--[trigger]--->|               |               |               |             |
    |               |--[read MT940]------------------------------------------>|   |
    |               |<-------------------------------------------------[file]--|   |
    |               |--[parse & normalize]->|               |               |     |
    |               |               |<--[persist balances]--|               |     |
    |               |               |<--[persist operations]|               |     |
    |               |--[complete]-->|               |               |             |
    |               |               |               |               |             |
    |--[trigger]---------------------------->|               |               |     |
    |               |               |<--[load contracts]----|               |     |
    |               |               |<--[load balances]-----|               |     |
    |               |               |               |               |             |
    |               |               |   [evaluate eligibility]      |             |
    |               |               |   [calculate movements]       |             |
    |               |               |               |               |             |
    |               |               |<--[persist movements]--|               |     |
    |               |               |<--[update context]-----|               |     |
    |               |               |               |               |             |
    |--[trigger]---------------------------------------->|               |         |
    |               |               |<--[load movements]---------|               | |
    |               |               |               |               |             |
    |               |               |   [transform to CBS format]   |             |
    |               |               |               |               |             |
    |               |               |               |--[write file]-------------->|
    |               |               |<--[update status]------|               |     |
    |               |               |               |               |             |

Fin du document

#Produit Cash Pooling - MVP

#Table des matieres​

#1. Introduction et contexte​

#1.1 Objet du document​

#1.2 Perimetre MVP​

#1.3 Principes directeurs​

#2. Vue d'architecture globale​

#2.1 Diagramme logique des composants​

#2.2 Flux batch global​

#2.3 Positionnement des adaptateurs CBS​

#3. Responsabilites par composant​

#3.1 Input Batch (Adapter IN)​

#3.2 Cash Pooling Core (Noyau)​

#3.3 Output Batch (Adapter OUT)​

#4. Modele de donnees canonique​

#4.1 Vue d'ensemble​

#4.2 Entite Contract​

#4.3 Entite Account​

#4.4 Entite Balance​

#4.5 Entite Operation​

#4.6 Entite PoolingRule​

#4.7 Entite PoolingMovement​

#4.8 Entite ExecutionContext​

#5. Fonctionnement batch et regles metier​

#5.1 Cycle de traitement global​

#5.2 Regles d'eligibilite​

#5.3 Algorithmes de nivellement​

#5.3.1 ZBA (Zero Balance Account)​

#5.3.2 TBA (Target Balance Account)​

#5.3.3 FBA (Fork Balance Account)​

#5.4 Gestion de la hierarchie multi-niveaux​

#5.5 Cas particuliers​

#6. Points non couverts volontairement​

#6.1 Cash Pooling Indirect​

#6.2 Traitement temps reel​

#6.3 Orchestration applicative​

#6.4 Reporting avance​

#6.5 Interface utilisateur​

#6.6 Tarification​

#7. Annexes​

#7.1 Glossaire​

#7.2 Combinaisons valides Mode/Type de transfert​

#7.3 Contraintes de periodicite​

#7.4 Diagramme de sequence - Traitement ZBA par Solde​

Produit Cash Pooling - MVP

Table des matieres

1. Introduction et contexte

1.1 Objet du document

1.2 Perimetre MVP

1.3 Principes directeurs

2. Vue d'architecture globale

2.1 Diagramme logique des composants

2.2 Flux batch global

2.3 Positionnement des adaptateurs CBS

3. Responsabilites par composant

3.1 Input Batch (Adapter IN)

3.2 Cash Pooling Core (Noyau)

3.3 Output Batch (Adapter OUT)

4. Modele de donnees canonique

4.1 Vue d'ensemble

4.2 Entite Contract

4.3 Entite Account

4.4 Entite Balance

4.5 Entite Operation

4.6 Entite PoolingRule

4.7 Entite PoolingMovement

4.8 Entite ExecutionContext

5. Fonctionnement batch et regles metier

5.1 Cycle de traitement global

5.2 Regles d'eligibilite

5.3 Algorithmes de nivellement

5.3.1 ZBA (Zero Balance Account)

5.3.2 TBA (Target Balance Account)

5.3.3 FBA (Fork Balance Account)

5.4 Gestion de la hierarchie multi-niveaux

5.5 Cas particuliers

6. Points non couverts volontairement

6.1 Cash Pooling Indirect

6.2 Traitement temps reel

6.3 Orchestration applicative

6.4 Reporting avance

6.5 Interface utilisateur

6.6 Tarification

7. Annexes

7.1 Glossaire

7.2 Combinaisons valides Mode/Type de transfert

7.3 Contraintes de periodicite

7.4 Diagramme de sequence - Traitement ZBA par Solde