Portefeuille Hot/Cold et politique d'accès

1) Pourquoi diviser en Hot/Warm/Cold

• Hot - dépôts opérationnels/conclusions (T0/T + 1), délais minimaux, bilan limité.
• Warm - pools intermédiaires pour les suppléments hot et les gros paiements réguliers.
• Cold - stockage à long terme (réserves/trésorerie), le plus isolé possible du réseau.

Résultat : moins de risques opérationnels et des SLA prévisibles en exposition contrôlée.

2) Architecture de stockage de référence

Calques et leur rôle

Hot (en ligne, automatisé) : signe les petits/moyens paiements dans les limites journalières. Protection - HSM/KMS, moteur de politique, alertes.
Warm (en partie en ligne/module matériel) : paiements batch, recharge hot, limites élevées, confirmation manuelle.
Cold (hors ligne/air-gapped) : multisig/MDC ; les opérations sont rares, selon une procédure avec accès physique et journal.

Technologie

HSM/KMS pour clés et tokens hot/warm ;

Multisig m-of-n ou MPC pour warm/cold ;

Moteur de politique (limites, 4 yeux, listes d'adresses autorisées, fenêtres temporelles) ;

Relais privé/protection MEV pour les transactions importantes.

3) Politique d'accès

3. 1 Principes

Moins de privilèges (PoLP) : accès exactement par rôle et zone (hot/warm/cold).
Partage des responsabilités (SoD) : différentes personnes/services initient, affirment, signent, libèrent.
4-eye : minimum de deux approbations indépendantes pour les opérations critiques (limites, listes d'adresses, warm→hot).
Isolation des circuits : prod ≠ stage ; ACL réseau, identifiants individuels.

3. 2 Rôles

Operator (Payments) : crée des paiements/batchs dans les limites.
Approver (Trésor/Risque) : approbation au-dessus des seuils, whitelist/hold.
Custodian (Key Owner) : Participation à multisig/MDC pour warm/cold.
Conformité : holds/EDD/SAR, solutions Travel Rule/KYT.
Sécurité : gestion HSM/KMS, rotation des clés, incidents.

4) Limites et guardrails

Whitelist/denylist : carnet d'adresses avec TTL, seuils KYT et preuve obligatoire de possession (pour unhosted).

5) Flux opérationnels

5. 1 Recharge hot de warm

1. Monitoring 'hot _ balance <threshold' → une demande de reconstitution.
2. Le KUT/les sanctions sur les adresses de destination → la collecte du batch.
3. Double approbation (4 yeux), signature (warm multisig/MDC).
4. Le transfert et l'enregistrement dans le laveur ; alert sur la modification des limites.

5. 2 Paiements de hot

Automatiquement dans les limites per-tx et per-day.
Pour le dépassement - escalade en warm : batch/sortie partielle + vérification RBA (SoF/KYT/Travel Rule).

5. 3 Rebalance warm↔cold

Périodique (hebdomadaire/seuil) ou sur décision du Trésor ; signature hors ligne, deux canaux de confirmation indépendants, magazine.

6) Sécurité clé

Génération et stockage : uniquement sur HSM/air-gapped ; refus d'exporter des clés privées.
Rotation : planifiée (N mois), non planifiée en cas d'incident ; procédures de révocation documentées.
Backup/Shard Management : boules cryptées (MPC) dans différents emplacements/juridictions ; tests périodiques de récupération.
Périmètre réseau : IP allow-list, mTLS, webhooks signés, surveillance des anomalies.
Contrôle du changement : RFC pour modifier les stratégies/limites, journal des modifications (immutable).

7) Conformité et contrôle

KUT/sanctions : pré-vérification d'entrée/sortie ; différents profils de risque sur les réseaux.
Travel Rule : pour les VASP↔VASP - IVMS101, répliques de messages et résultats de livraison.
RBA : les limites/confirmations dépendent du segment de risque et du montant.
Vérification : piste complète : qui/quand/ce qui a initié/approuvé/signé ; version des règles au moment de l'opération.
GDPR/PII : minimisation, tokenisation ID, stockage séparé du PAN de paiement.

8) Observabilité, logs et reconsilation

Leiger : mapping 'invoice/withdrawal ↔ txid ↔ wallet (subaccount)' par réseau/actif.
Reconsilation T + 0/T + 1 : montants, commissions, taux (source des prix, timestamp), résidus non couverts.
Surveillance : équilibre hot/warm/cold, taux de confirmation, fee, paiements anormaux, commutation vers les réseaux de secours.
Alerts : dépassement des limites/velocity, nouvelles adresses hors whitelist, divergences de rapprochement.

9) Pleybooks d'incidents

Fuite/compromission hot : suppression immédiate des limites à zéro, transfert des résidus à warm/cold, rotation des clés, enquête, rapport aux régulateurs/partenaires.
Anomalies de paiement : freeze batcha, KYT re-check, demande SoF, sortie partielle de la partie sécurisée.
Dégradation du réseau/tempête fee : auto switch-over sur le réseau de secours/méthode, mise à jour de l'ETA dans l'UI.
Indisponibilité du fournisseur custody/RPC : faussaire, libération manuelle des paiements critiques via warm, analyse post-incident.
Changement de politique non autorisé : rollback automatique, notification SecOps/Compliance, rapport d'audit.

10) Métriques et OKR

Sécurité/conformité

Part des actifs dans cold/warm/hot (fourchettes cibles), nombre de violations des limites.
KYT reject %, succès de sanctions, conversion SAR (le cas échéant).
Nombre de modifications de règles/mois, demandes de relèvement de limite réussies/rejetées.

Fiabilité/opérations

Time-to-Payout p50/p95 pour les itinéraires hot/warm.
Fréquence de remplissage hot, taille moyenne de remplissage.
Pourcentage de paiement automatique vs manuel, incidents/trimestre.

Économie/UX

Cost per Approved (tout-en-un sur le réseau/actif), fee-pourcentage du montant.
Erreurs réseau/memo/tag, nombre de versions partielles, tickets par latence.

11) Anti-modèles

Porte-monnaie surchargé sans caps de jour rigides.
Un fournisseur castodial/un réseau sans réserve → SPOF.
Absence de 4 yeux et de SoD pour l'opération warm/cold.
Clés sans HSM/KMS, pas de rotation régulière/tests de récupération.
Pas de whitelist/TTL et KYT avant de retirer - risque accru.
Modification des limites « par messager » sans RFC/audit.
L'absence d'idempotence et d'anti-prise dans les retraits est une double annulation.

12) Chèque de mise en œuvre (court)

• Matrice de couches : hot/warm/cold avec limites per-tx/per-day et parts d'actifs.
• Rôles et SoD : Operator/Approver/Custodian/Compliance/Security, 4-eye.
• HSM/KMS pour hot/warm, multisig/MRS pour warm/cold, signature hors ligne.
• Adresses whitelist/denylist avec TTL, seuils KYT, preuve de possession.
• Processus : reconstitution hot, paiements batch de warm, rebalance en cold.
• Observabilité : leiger, reconsilation T + 0/T + 1, alertes de dépassement.
• Pleybooks incidents : compromission, dégradation du réseau, indisponibilité du fournisseur.
• Travel Rule/IVMS101, politiques RBA, vérification des changements.
• Idempotence, anti-doublage, backoff + jitter ; les webhooks signés.
• Tests réguliers de récupération des clés et exercices d'incident.

13) Résumé

La bonne stratégie hot/warm/cold n'est pas seulement « trois portefeuilles », mais un mode de gestion des risques et des accès : limites et 4 yeux, HSM/KMS et multisig/MRS, KYT/Travel Rule et RBA, des procédures claires de reconstitution et de paiement, de l'observation et des playbacks. Ce circuit permet de payer rapidement à partir d'une exposition minimale des actifs et de résister aux incidents - la base d'une infrastructure de paiement sûre et rentable iGaming.