portafogli e criteri di accesso Hot/Cold

1) Perché dividere in Hot/Warm/Cold

• Hot - depositi/conclusioni operativi (T0/T + 1), ritardi minimi, saldo limitato.
• Warm - pool intermedi per rifornimenti hot e grandi pagamenti regolari.
• Cold - conservazione a lungo termine (riserve/Tesoro), il più possibile isolato dalla rete.

Risultato: meno rischi operativi e SLA prevedibili con esposizione controllata.

2) Architettura di storage

Livelli e il loro ruolo

Hot (on-line, automatizzato) - Firma pagamenti di piccole e medie dimensioni entro i limiti diurni. La protezione è HSM/KMS, policy engine, alert.
Warm (parzialmente online/plug-in): pagamenti in batch, sostituzione hot, limiti elevati, conferma manuale.
Cold (offline/air-gapped): multisig/MRS; operazioni rare, per procedura di accesso fisico e registro.

Tecnologia

HSM/KMS per chiavi e token hot/warm

Multisig m-of-n o MPC per warm/cold;

Policy engine (limiti, 4-occhi, elenchi degli indirizzi autorizzati, finestre di tempo);

Private relay/protezione da MEV per transazioni di grandi dimensioni.

3) Criteri di accesso (Access Policy)

3. 1 Principi

Privilegi minimi (PoLP): accede esattamente in base al ruolo e alla zona (hot/warm/cold).
Separazione dei compiti (SoD): persone/servizi diversi avviano, sostengono, firmano, comunicano.
Quattro occhi: almeno due approvazioni indipendenti per operazioni critiche (limiti, indirizzi, warm→hot).
Isolamento dei tracciati: prod ≠ stage; ACL di rete, credenziali separate.

3. 2 Ruoli

Operator (Payments) - Crea pagamenti/batch entro i limiti.
Approver (Treasury/Risk) - Approvazione oltre le soglie, whitelist/hold.
Custodian (Key Owner) - Partecipazione al multisig/MRS per il warm/cold.
Compliance: holds/EDD/SAR, Travel Rule/KYT.
Sicurezza: gestione HSM/KMS, rotazione chiavi, incidenti.

4) Limiti e guardrail

Whitelist/denylist - Rubrica con TTL, soglie KYT e conferma di proprietà obbligatoria (per unhosted).

5) Flussi operativi

5. 1 Rifornimento hot da warm

1. Monitoraggio dì hot _ balance <threshold'per la richiesta di rifornimento.
2. La KUT/Sanzioni per gli indirizzi di destinazione.
3. Doppia approvazione (4-occhi), firma (warm multisig/MRS).
4. Traduzione e registrazione in un lager; alert per cambiare i limiti.

5. 2 Pagamenti da hot

Automaticamente entro i limiti per-tx e per-day.
Per il superamento, escalation in warm: batch/release parziale + controllo RBA (SoF/KYT/Travel Rule).

5. 3 Rebalance warm↔cold

Periodico (settimanale/a soglia) o per decisione del Tesoro; firma offline, due canali di conferma indipendenti, registro.

6) Protezione chiave

Generazione e storage: solo su HSM/air-gapped; rifiuto di esportare chiavi private.
Rotazione: pianificata (N mesi), fuori programma in caso di incidente; Procedure di ritiro documentate.
Backup/Shard-Management: sfere crittografate (MPC) in diverse località/giurisdizioni; test di recupero periodici.
Perimetro di rete: IP allow-list, mTLS, webhoop firmati, monitoraggio anomalie.
Cambio-control: RFC per la modifica dei criteri/limiti, registro delle modifiche (immutabile).

7) Complaens e controllo

KUT/sanzioni: pre-check per accesso/uscita; profili di rischio diversi sulla rete.
Travel Rule - IVMS101, repliche di messaggi e risultati di spedizione.
RBA - I limiti/conferma dipendono dal segmento di rischio e dall'importo.
Controllo: traccia completa: chi/quando/cosa ha avviato/approvato/firmato; la versione delle regole al momento dell'operazione.
GDPR/PII: minimizzazione, tornizzazione ID, storage separato da PAN di pagamento.

8) Osservazione, loga e riconsilazione

Lager: magping'invoice/withdrawal "txid" wallet (subaccount) "per rete/risorsa.
Reconsilazione T + 0/T + 1: importi, commissioni, tasso di cambio (fonte prezzi, timestamp), saldi non coperti.
Monitoraggio: bilanciamento hot/warm/cold, velocità di conferma, fee, pagamenti anomali, failover.
Alert: superamento dei limiti/velocity, nuovi indirizzi fuori whitelist, soluzione temporanea di compressione.

9) Playbook incidenti

Fuga/compromissione hot: rimozione immediata dei limiti a zero, trasferimento dei residui in warm/cold, rotazione delle chiavi, indagine, rapporto a regolatori/partner.
Anomalie dei pagamenti: freeze batch, KYT re-check, richiesta, rilascio parziale della parte sicura.
Degrado della rete/fee-tempesta: auto switch-over su rete/metodo di riserva, aggiornamento ETA in UI.
Il provider custody/RPC non è disponibile: feeling, rilascio manuale dei pagamenti critici tramite warm, analisi post-incidente.
Cambio di regole non autorizzato: rollback automatico, notifica SecOps/Compliance, rapporto di revisione.

10) Metriche e OKR

Sicurezza/compilazione

Quota di risorse in cold/warm/hot (intervalli di destinazione), numero di violazioni dei limiti.
KYT reject%, successo sanzionatorio, SAR-conversion (se applicabile).
Numero di modifiche alle regole/mese, richieste di aumento dei limiti completate/rifiutate.

Affidabilità/operazioni

Time-to-Payout p50/p95 per le rotte hot/warm.
Frequenza di rifornimento hot, media di sovraccarico.
Percentuale di pagamento automatico vs manuale, incidenti/trimestre.

Economia/UX

Cost per Approved (all-in per rete/asset), fee-percentuale dell'importo.
Errori di rete/memo/tag, numero di partial release, ticket di ritardo.

11) Anti-pattern

Portafogli hot affollati senza gocce diurne rigide.
Un provider castodiale/una rete senza riserva SPOF.
Assenza di 4-occhi e SoD per l'operazione warm/cold.
Chiavi senza HSM/KMS, nessuna rotazione regolare/test di ripristino.
Nessun whitelist/TTL o KYT prima di uscire è un rischio elevato.
Modifica i limiti di messaggistica senza RFC/controllo.
La mancanza di idampotenza e anti-ripresa nei retrai sono doppie cancellazioni.

12) Assegno foglio di implementazione (breve)

• Matrice livelli: hot/warm/cold con limiti per-tx/per-day e quote di asset.
• Ruoli e SoD: Operator/Approver/Custodian/Compliance/Security, 4-occhi.
• HSM/KMS per hot/warm, multisig/MRS per warm/cold, firma offline.
• Whitelist/denylist indirizzi con TTL, soglie KYT, conferma di proprietà.
• Processi: rifornimento hot, pagamenti da warm, reading in cold.
• Osservabilità: lager, riconsilazione T + 0/T + 1, alert di eccesso.
• Playbook di incidenti: compromissione, degrado della rete, indisponibilità del provider.
• Travel Rule/IVMS101, regole RBA, controllo delle modifiche.
• Idempotenza, anti-ripresa, backoff + jitter; webhoot firmati.
• Test regolari di ripristino delle chiavi e delle esercitazioni sugli incidenti.

13) Riepilogo

La strategia hot/warm/cold corretta non è solo «tre portafogli», ma la modalità di gestione dei rischi e dell'accesso: limiti e 4-occhi, HSM/KMS e multi-ISS, KYT/Travel Rule e RBA, procedure chiare di rifornimento e pagamento, osservabilità e playbook. Questo tracciato fornisce pagamenti rapidi da hot con un minimo di esposizione dei beni e la resistenza agli incidenti - la base di un'infrastruttura di pagamento sicura e redditizia.