Cosa cambia per i team Treasury e di settlement?
Per il team Treasury, il primo cambiamento è semplice: il denaro non è più in mano al provider. Per capire come funziona un gateway di pagamento crypto non-custodial, basta partire dal flusso dei fondi: il gateway invia i pagamenti direttamente a un wallet controllato dall’azienda. Il team Treasury smette quindi di ragionare in termini di saldi sulla piattaforma e passa a considerare i saldi dei wallet, le conferme sulla blockchain e la gestione interna della liquidità. Sulla carta sembra tutto lineare. Nella pratica, cambia la routine quotidiana.
Con i sistemi custodial, un analista Treasury può affidarsi a un’unica dashboard e a un unico file dei pagamenti. Con una configurazione non-custodial, potrebbe dover monitorare più wallet, annotare su quale blockchain sono arrivati i fondi e associare ogni accredito a un ordine, una fattura o un’unità aziendale. Un pagamento può risultare visibile on-chain prima di essere disponibile per l’uso interno.
Il team Treasury deve anche stabilire nuove regole per la gestione della liquidità. Se l’azienda riceve stablecoin, il team può decidere di conservarle, convertirle o trasferirle a un altro wallet, in base alle policy e alle condizioni di mercato. Se invece riceve asset volatili, deve valutare se può tollerare un’esposizione di 10 minuti, un’ora o più a lungo. Questa scelta va definita nelle policy, non lasciata a un’email nella casella di qualcuno alle 17:30.
È qui che la domanda cosa cambia per i team aziendali quando adottano un gateway di pagamento crypto non-custodial diventa concreta: il denaro non è più “parcheggiato” presso un provider mentre il reparto Finance aspetta un report sui pagamenti. Arriva direttamente in un’infrastruttura controllata dall’azienda e il flusso di lavoro Treasury diventa tanto una questione di controlli quanto di liquidità.
Cosa cambia per la riconciliazione contabile e la chiusura di fine mese?
Il cambiamento si fa sentire quasi subito per i team Finance, perché l’attività a livello di wallet non assomiglia a un normale estratto conto bancario. Ogni transazione include un hash, un tipo di token, una blockchain e spesso un indirizzo che per un contabile non significa nulla, a meno che non sia stato associato all’ordine di un cliente. Un pagamento può anche arrivare in più tranche, trasformando l’abbinamento dei dati in una piccola indagine, anziché in una semplice importazione: sono questi alcuni degli impatti dei pagamenti crypto sulla riconciliazione contabile.
La chiusura di fine mese diventa più complessa. Una piattaforma custodial può fornire un unico estratto conto o insieme di report, mentre con un gateway di pagamento crypto non-custodial spesso è l’azienda a dover produrre le prove necessarie attraverso i propri sistemi. Il team Finance potrebbe dover riconciliare gli accrediti on-chain con le registrazioni nell’ERP, verificare i tassi di cambio applicati al momento della rilevazione contabile e controllare che la transazione sia arrivata sulla rete prevista. Se un pagamento è stato inviato sulla blockchain sbagliata, non è una semplice voce contabile: è un flusso di lavoro da gestire.
C’è anche il problema dei riferimenti. Alcune blockchain forniscono ID di transazione chiari, mentre i sistemi contabili interni possono richiedere numeri di fattura, ID cliente o riferimenti di pagamento. Se questi identificativi non vengono inseriti nel processo fin dall’inizio, il team che si occupa della chiusura deve abbinare le registrazioni consultando la cronologia del wallet e gli orari delle transazioni: un’attività più lenta di quanto sembri. E più lenta di quanto dovrebbe essere.
Per iniziare in modo pratico, i team possono consultare una guida ai gateway di pagamento crypto per l’e-commerce e adattare poi la registrazione dei dati ai controlli aziendali, anziché alle abitudini di un negozio online. È un passaggio importante, perché la riconciliazione e-commerce e quella aziendale sono attività diverse, anche quando usano lo stesso circuito di pagamento.
Cosa cambia per la titolarità delle chiavi e le approvazioni interne?
La titolarità delle chiavi modifica gli accordi interni all’azienda. In un modello custodial, il provider può gestire l’infrastruttura dei wallet. In un modello non-custodial, l’azienda è responsabile delle chiavi private, degli accessi di backup, delle autorizzazioni alla firma e delle regole che stabiliscono chi può trasferire i fondi: la gestione delle chiavi crypto in azienda è quindi una questione di governance, non un semplice dettaglio tecnico.
La maggior parte delle aziende non può permettere che una sola persona controlli un wallet contenente fondi aziendali. Servono flussi di approvazione, separazione dei compiti e registrazioni chiare di chi può firmare, chi può avviare un trasferimento e chi può ripristinare l’accesso in caso di smarrimento di un dispositivo. In un reparto può bastare la regola delle due persone, in un altro no. Uno schema 3-su-5 può essere adatto a un wallet Treasury, ma eccessivo per un wallet operativo con importi ridotti. Le policy devono essere proporzionate al rischio.
C’è poi la questione dei backup. Se l’azienda perde l’accesso alle chiavi, il provider non sempre può ripristinare i fondi, perché in primo luogo non li ha mai detenuti. Per questo, il piano di ripristino deve essere trattato come parte della pianificazione della continuità operativa. Copie cartacee, procedure per gli hardware wallet, backup conservati in luoghi diversi e responsabili nominati non sono optional: fanno parte del lavoro.
Le approvazioni interne vanno messe per iscritto prima del lancio, non dopo il primo pagamento. Basta un’approvazione mancante per bloccare un trasferimento. Un diritto amministrativo troppo ampio può causare più danni di una fattura errata.
Cosa cambia per la gestione dei rischi e la risposta agli incidenti?
I team Risk devono adottare un modello mentale diverso. Un provider di pagamento che detiene i fondi a volte può risolvere un problema interno prima del settlement. Un gateway di pagamento crypto non-custodial non può farlo, perché i fondi sono già on-chain e sotto il controllo dell’azienda. Una volta firmato il trasferimento, l’azienda deve convivere con il risultato. Questo, da solo, cambia la valutazione della gravità degli incidenti.
Cambiano anche i tipi di incidenti. La compromissione di un wallet, la manipolazione degli indirizzi, la scelta della blockchain sbagliata e i trasferimenti a indirizzi errati diventano rischi prioritari. Se un cliente invia USDC sulla rete sbagliata, il team di supporto potrebbe dover seguire una procedura manuale di recupero. Se un dipendente approva un trasferimento verso un indirizzo molto simile a quello corretto, la risposta non è “apri un ticket con il processore”, ma “contieni l’incidente, verifica e documenta”.
I team Security devono predisporre controlli per la convalida degli indirizzi, la protezione dei dispositivi e le procedure di firma. Servono anche playbook per il recupero delle chiavi, perché perdere l’accesso e subire una compromissione attiva sono situazioni diverse. Nel primo caso è un problema di disponibilità, nel secondo un furto. In entrambi i casi conta la rapidità di risposta, ma le procedure non sono le stesse.
Le aziende che stanno ancora testando le procedure possono trarre vantaggio da una simulazione controllata. Un riferimento pratico è come testare un pagamento crypto, soprattutto se il piano di test include tentativi verso indirizzi errati, pagamenti parziali e conferme ritardate. Testare solo il flusso ideale è il modo migliore per scoprire le lacune una volta entrati in produzione.
Cosa cambia per gli acquisti e la due diligence sui fornitori?
La prima domanda del reparto Procurement non è più “Questo fornitore può custodire i nostri fondi?”, ma “Che cosa controlla esattamente questo fornitore?”. La differenza può sembrare sottile, ma non lo è. In una configurazione non-custodial, il provider può creare richieste di pagamento, monitorare le blockchain e inviare webhook, mentre l’azienda mantiene il controllo del wallet. Procurement deve capire bene questi confini prima di firmare il contratto.
La due diligence ora comprende l’architettura di firma, la compatibilità con i wallet, le blockchain supportate, l’integrità dei webhook, gli avvisi e la capacità di monitoraggio. Un fornitore che sembra perfetto durante una presentazione commerciale può comunque non essere adatto se non supporta lo standard di wallet richiesto dal team Security. Un’integrazione che dipende da verifiche manuali può andare bene per un progetto pilota, ma non per 200 pagamenti al giorno.
Nei questionari per i fornitori bisogna chiedere chi può vedere cosa, chi può avviare quali operazioni e chi è responsabile se una transazione viene rilevata ma non si conclude come previsto. I confini operativi del provider contano tanto quanto le funzionalità offerte. Se un fornitore dice “non custodiamo i fondi”, Procurement dovrebbe chiedere che cosa fa e che cosa non è disposto a fare. Entrambe le risposte sono importanti.
Cosa cambia per le prove di audit e i controlli interni?
Gli auditor chiedono prove, non supposizioni. Un gateway di pagamento crypto non-custodial modifica la traccia documentale perché i pagamenti vengono accreditati direttamente su wallet controllati dall’azienda. L’impresa deve quindi dimostrare la titolarità, le approvazioni, i log delle transazioni e la catena di custodia delle operazioni interne. Senza questa documentazione, la verifica si prolunga più del necessario.
Le prove dei controlli devono collegare l’ordine del cliente, l’indirizzo di pagamento generato, l’accredito on-chain e la registrazione nel sistema contabile interno. Se manca uno di questi collegamenti, il team Finance potrebbe dover ricostruire il percorso in un secondo momento. Richiede molte ore e rende scomode le riunioni di audit. A nessuno piace dover spiegare una transazione leggendo ad alta voce i dati di un block explorer.
Anche i controlli sugli indirizzi fanno parte del processo. Le aziende potrebbero aver bisogno di un elenco documentato degli indirizzi di ricezione approvati, di prove che le modifiche siano state verificate e di attestazioni che confermino il controllo aziendale del wallet. Se l’indirizzo di pagamento cambia tra il preventivo e la fattura, l’azienda deve prevedere un passaggio di approvazione. Una modifica dell’indirizzo non controllata può compromettere l’intera traccia documentale.
Anche i controlli interni vanno riesaminati periodicamente. L’obiettivo è dimostrare che approvazioni, log e registrazioni della titolarità continuino a funzionare dopo i cambiamenti del personale, la rotazione dei wallet e gli aggiornamenti delle policy.
Cosa cambia per l’assistenza, i rimborsi e le eccezioni di pagamento?
Spesso i team di assistenza si accorgono delle lacune operative prima del reparto Finance. I pagamenti crypto non funzionano come quelli con carta e non offrono lo stesso tipo di protezione dai chargeback. Per questo, rimborsi, pagamenti duplicati e importi versati in eccesso richiedono policy scritte, non soluzioni improvvisate. Un agente dell’assistenza non può risolvere un trasferimento sulla rete sbagliata con la sola empatia.
I rimborsi sono particolarmente complessi, perché il pagamento originale potrebbe essere arrivato in un asset diverso da quello che l’azienda vuole restituire. Se l’azienda ha accettato un token a un certo tasso e lo rimborsa in seguito a un tasso diverso, qualcuno deve stabilire quale importo è dovuto e quali commissioni restano a carico dell’azienda. La decisione deve derivare dalle policy e da una verifica legale, non dall’agente che gestisce il ticket.
Le transazioni bloccate aggiungono un altro livello di lavoro. Un pagamento può essere stato trasmesso ma non ancora confermato, oppure può arrivare a conferma quando il cliente ha già riaperto il ticket. Il team di assistenza ha bisogno di una matrice degli stati: in attesa, confermato, scaduto, pagato in eccesso, pagato in difetto e rifiutato. Per molti team, sei stati sono sufficienti. Se diventano troppi, la formazione perde efficacia.
Le aziende che vogliono approfondire la gestione delle eccezioni di pagamento possono consultare il materiale su come accettare pagamenti crypto per i flussi rivolti ai clienti, e poi adattare la gestione delle eccezioni agli SLA aziendali. Il messaggio mostrato al cliente e la gestione dello stesso pagamento nei processi interni sono spesso attività diverse.
Cosa cambia nella pianificazione del rollout tra i reparti?
Il rollout diventa un programma che coinvolge più funzioni, non una semplice funzionalità di pagamento. Finance deve concordare le regole di registrazione contabile. Treasury deve definire la titolarità dei wallet. Security deve approvare le procedure di firma e conservazione. Legal deve esaminare le condizioni, i rimborsi e le clausole sulle sanzioni. Il team di assistenza deve sapere cosa dire ai clienti quando una transazione è in attesa. Engineering deve integrare i sistemi senza creare un processo parallelo non controllato.
La sequenza è importante. Si parte da un wallet, una blockchain e un’unità aziendale. Poi si definiscono un piano di test, un piano di emergenza e un percorso di escalation. Infine, si avvia il progetto pilota assegnando un nome a ogni fase di approvazione. Se alle 16 di venerdì nessuno sa chi è responsabile del wallet, il rollout non è pronto.
La formazione non può ridursi a una singola presentazione. Treasury deve conoscere i limiti di firma. Finance deve sapere come i dati dei wallet arrivano nell’ERP. Il team di assistenza ha bisogno di procedure per i rimborsi. Security deve conoscere i criteri di attivazione della risposta agli incidenti. Legal deve approvare i messaggi destinati ai clienti. Se un reparto viene escluso dal rollout, l’intero programma può rallentare.
Se l’azienda paga anche collaboratori o partner, il piano di rollout potrebbe richiedere un percorso parallelo. Un riferimento utile è come impostare pagamenti crypto in massa, perché la logica dei pagamenti, i flussi di approvazione e la registrazione dei dati spesso si intrecciano con la gestione degli incassi nello stesso trimestre. Nel primo anno è una situazione frequente.
Comments