Saldi aziendali, pagamenti, carte e approvazioni in un unico spazio di lavoro.
Controlli interni per pagamenti in stablecoin
Il framework di controllo che i revisori già richiedono, scritto nel linguaggio del ciclo dei pagamenti e non della blockchain.
I controlli sui pagamenti in stablecoin perseguono gli stessi obiettivi di quelli sui bonifici (autorizzazione, accuratezza, salvaguardia degli asset), ma devono essere preventivi e non successivi, perché il regolamento non è reversibile. In pratica servono destinazioni in whitelist, separazione dei compiti, un quorum di approvazione proporzionato all’importo, screening prima dell’esecuzione e una registrazione che colleghi policy, approvatori e hash della transazione.
Matrice dei controlli
| Rischio | Controllo | Evidenze prodotte |
|---|---|---|
| Pagamento verso indirizzo malevolo | Whitelist di destinazione nella scheda controparte; ogni modifica va riapprovata | Registro modifiche con richiedente, approvatore e timestamp |
| Pagamento non autorizzato | Separazione dei compiti: chi prepara non rilascia | Richiedente e approvatore distinti sul pagamento |
| Un solo dispositivo compromesso | Firma MPC a quorum: approvazioni m-su-n | Firme archiviate con la transazione |
| Violazione sanzioni | Screening all'origine, con blocco del rilascio in caso di riscontro | Esito dello screening con timestamp anteriore all'hash |
| Importo superiore alla delega | Limiti a scaglioni per importo, asset e controparte | Versione policy applicata al pagamento |
| Indebolimento silente dei controlli | Modifiche alle policy solo da admin, con quorum completo | Storico immutabile delle modifiche alle policy |
| Lock-in del fornitore / continuità | Self-custody con export delle chiavi documentato | Procedura di recupero testata |
Separazione dei compiti in un team ridotto
L'obiezione più frequente è che un team finance di quattro persone non possa separare nulla. Invece può: la separazione avviene per action, non per reparto. Una persona prepara i lotti di pagamento e gestisce il registro delle controparti. Altre due detengono le chiavi di firma e approvano. Un amministratore gestisce le policy ma non prepara pagamenti. Nessuno ha insieme il diritto di preparazione e la maggioranza delle chiavi di firma: è tutto ciò che serve.
- Preparatore: crea le distinte di pagamento, non può eseguirle.
- Approvatori: minimo due firmatari, impossibilitati a creare beneficiari.
- Amministratore: gestisce policy e ruoli; le modifiche richiedono il quorum.
- Osservatore: accesso in sola lettura per revisore e CFO.
Preparazione del pacchetto di evidenze
- 01Il documento di policy in vigore: limiti, approvatori, quorum, destinazioni in whitelist.
- 02Il registro delle modifiche alle policy del periodo, con chi ha richiesto e chi ha approvato ogni modifica.
- 03Esempi di pagamento con richiedente, approvatore, versione della policy, esito dello screening e hash.
- 04L'elenco dei tentativi di pagamento bloccati: la prova che il controllo preventivo scatta.
- 05L'anagrafica delle controparti con le date di aggiunta e verifica di ogni destinazione.
- 06Documentazione sulla custodia delle chiavi, inclusa la procedura di recupero e la data dell'ultimo test.
- 07Riconciliazione dei saldi on-chain con la contabilità a fine periodo.
Carenze comuni
| Cosa osserviamo | Perché fallisce | Correggi |
|---|---|---|
| Un hardware wallet condiviso | Nessuna segregazione, nessun recupero, nessuna attribuzione | Firma a quorum con chiavi personali |
| Screening settimanale | Non preventivo: il pagamento è già regolato | Screening all'origine, blocco al riscontro |
| Indirizzi incollati a ogni pagamento | La sostituzione di indirizzi è la prima causa di perdite | Whitelist nella scheda controparte |
| Approvazioni in chat | Non legato alla transazione, facile da falsificare | Approvazione registrata crittograficamente alla firma |
| Policy modificabile da qualsiasi operatore | L’accesso può essere revocato prima di un uso improprio | Modifiche alle policy solo da admin, approvate dal quorum |
Come lo applica Stablerail
Ruoli, limiti e quorum di approvazione si configurano una sola volta a livello di organizzazione e si applicano automaticamente a ogni vault. Solo gli amministratori possono modificare la policy, e ogni modifica richiede lo stesso quorum di firma di un pagamento. Lo screening avviene prima del rilascio e ogni pagamento viene esportato con versione della policy, approvatori, esito dello screening e hash: il pacchetto di evidenze descritto sopra, generato e non assemblato a mano.
Domande frequenti
Controlli interni richiesti dai revisori per i pagamenti in stablecoin
Separazione dei compiti tra chi prepara e chi approva, quorum di approvazione proporzionato all'importo, whitelist delle destinazioni consentite, screening sanzioni documentato prima dell'esecuzione, custodia delle chiavi documentata con procedura di recupero e registro immutabile di ogni modifica a policy o firmatari.
La SOX si applica ai pagamenti in cripto?
Per le società quotate negli USA, i controlli sui pagamenti in stablecoin rientrano nello stesso perimetro ICFR di qualsiasi altro processo di esborso. Gli obiettivi di controllo non cambiano (autorizzazione, completezza, accuratezza, salvaguardia degli asset): cambia solo il formato delle evidenze.
Qual è il set minimo di controlli per un piccolo team finance?
Quattro requisiti: i destinatari devono essere in whitelist e ogni modifica va riapprovata, nessuno può sia creare sia rilasciare un pagamento, lo screening avviene prima del rilascio e le chiavi richiedono un quorum. Un team di due persone può gestirli tutti; con meno persone non si dovrebbero movimentare importi rilevanti.
Come si documenta un controllo eseguito on-chain?
Conservi versione della policy, richiedente, identità degli approvatori, esito dello screening e hash della transazione in un unico record, con timestamp in quest'ordine. Il revisore può verificare l'hash in autonomia: un'evidenza più solida di un estratto conto bancario.
Controlli preventivi o di rilevazione?
Preventivi, perché i pagamenti on-chain non possono essere revocati. I controlli successivi restano utili per riconciliazioni e indagini, ma un framework basato solo sulla verifica a posteriori sarà giudicato carente per un canale di pagamento irreversibile.
Chi dovrebbe poter modificare una policy di pagamento?
Solo gli amministratori, e ogni modifica dovrebbe richiedere lo stesso quorum di firma di un pagamento. La policy vale per l'intera organizzazione, quindi una modifica incide su tutti i vault contemporaneamente: trattarla come un'impostazione di routine è la lacuna più comune che riscontriamo.
Continua a leggere
Tesoreria aziendale in stablecoin, carte e pagamenti in uscita.
Incassi, approvazioni, screening, pagamenti, spese con carta e off-ramp, con evidenze di audit su ogni transazione.