Trade Risk Management: Un Framework Moderno per la Resilienza

Le indicazioni standard sulla trade risk management sono ancora troppo ristrette. Trattano il rischio come un problema di hedging, assicurazione del credito e buffer contro i ritardi delle spedizioni. Questi controlli continuano a essere importanti, ma non descrivono la realtà operativa di un’azienda regolamentata che dipende da piattaforme cloud, software in outsourcing, logistica di terze parti, gestione transfrontaliera dei dati e fornitori che devono reggere a un esame approfondito.

Per molte aziende, il problema più difficile non è identificare che il rischio esiste. È dimostrare che l’organizzazione capisce dove si colloca il rischio, chi possiede il controllo, quali evidenze mostrano che funziona e con quanta rapidità un team può reagire quando un fornitore, un regolatore o un auditor fanno domande. Per questo la trade risk management oggi appartiene tanto alla security, alla compliance, agli acquisti e alla resilienza operativa quanto alla tesoreria.

Un approccio moderno funziona meglio se viene trattato come un problema di sistemi. I rischi si muovono attraverso processi, vendor, interfacce, approvazioni e percorsi di eccezione. Anche i controlli dovrebbero fare lo stesso. Se l’unica evidenza di resilienza è una cartella di policy e un foglio di calcolo aggiornato l’ultima volta prima che esistesse l’attuale stack di fornitori, l’organizzazione non sta gestendo il rischio commerciale. Sta documentando un’intenzione.

Introduzione Il Nuovo Scenario del Rischio Commerciale

Un tempo il rischio commerciale veniva discusso in categorie relativamente chiare. Il cambio si muoveva. Un acquirente andava in default. Una nave arrivava in ritardo. Un contratto doveva assorbire lo shock. Quel modello oggi è incompleto perché i flussi commerciali passano attraverso infrastrutture digitali, tecnologia di terze parti e obblighi normativi che non falliscono in modo indipendente.

Un’interruzione di un fornitore può bloccare l’evasione degli ordini. Un incidente cyber può diventare un problema di reporting. Un cambiamento nelle sanzioni può invalidare una dipendenza software, non solo una rotta fisica. Nell’ambito di DORA e NIS2, le aziende devono anche dimostrare il controllo sui fornitori ICT critici e sulla gestione degli incidenti, non limitarsi a presumere che queste discipline esistano da qualche parte nell’ecosistema dei vendor. In questo contesto, la resilienza dipende dalle evidenze.

Il cambiamento pratico è semplice da descrivere e più difficile da implementare. La trade risk management deve passare dalla revisione periodica alla verifica continua. Invece di chiedersi se un fornitore sia stato approvato una volta, i team devono sapere se il fornitore è ancora nel perimetro, se gli obblighi sono mappati ai controlli, se le eccezioni sono visibili e se le evidenze sono abbastanza aggiornate da supportare una decisione reale.

Regola pratica: Se un controllo non può essere collegato a un owner, a un sistema e a una traccia di evidenze, non reggerà sotto pressione.

Questo cambia il ruolo della compliance. Smette di essere un esercizio di documentazione e diventa parte della progettazione operativa. Security, procurement, legal e risk devono condividere un modello per controlli dichiarati, comportamenti osservati, evidenze conservate e percorsi di escalation. Gli audit diventano così la verifica di un sistema funzionante, non la ricostruzione dell’ultimo minuto di uno.

Ridefinire il Rischio Commerciale per un Mondo Connesso

Un modello di trade risk utilizzabile deve coprire più dell’esposizione finanziaria. Ha bisogno di un linguaggio che rifletta come avviene il fallimento nelle aziende connesse.

Cinque categorie che appartengono allo stesso modello

Le categorie familiari continuano a contare, ma devono essere gestite come componenti collegate e non come filoni di lavoro separati.

• Rischio di mercato comprende ancora il movimento dei prezzi e del cambio. In pratica, questo incide su margini, termini contrattuali, tempistiche di acquisto ed esposizione concentrata. I controlli di tesoreria aiutano, ma non risolvono le dipendenze altrove nella catena.

• Rischio di controparte non riguarda più solo la solvibilità. Una controparte può essere finanziariamente solida e creare comunque un’esposizione materiale attraverso security debole, risposta agli incidenti carente, supervisione immatura dei subappaltatori o un modello operativo fragile.

• Rischio operativo copre i processi e i sistemi dell’organizzazione. Approvazioni errate, mancanza di segregazione dei compiti, change control debole e gestione inadeguata delle eccezioni creano rischio commerciale molto prima che una spedizione o un pagamento falliscano.

• Rischio di compliance e sanzioni è più vicino alle operazioni di quanto molte aziende ammettano. Un cambiamento normativo conta solo quando incide su un ordine, su un accesso a un sistema, su un trasferimento, su una rotta, su un fornitore o su un obbligo contrattuale su cui qualcuno deve intervenire.

• Rischio della supply chain attraversa tutti i precedenti. Include logistica, concentrazione dei vendor, dipendenze software, supporto esternalizzato, processori di dati e service provider i cui guasti interrompono l’attività commerciale.

La maggior parte delle spiegazioni pubbliche continua a puntare troppo su hedging e protezione dei flussi di cassa. Questo trascura la realtà di una regolamentazione frammentata e della dipendenza digitale. Per le aziende europee, questo divario è visibile nell’ambiente commerciale e cyber italiano. ISTAT ha riportato un calo dello 0,4% del valore delle esportazioni nel 2024, mentre l’Agenzia per la Cybersicurezza Nazionale ha evidenziato un peggioramento del contesto delle minacce cyber, mostrando come oggi la disruption economica e quella informatica si intersechino nelle operazioni commerciali reali, come discusso in questa analisi della gestione del rischio nel trading.

Perché il pensiero sistemico conta

Un elenco di categorie è utile solo se cambia le decisioni. La domanda chiave non è quale rischio sembri più grave in teoria. È dove un singolo guasto può attraversare più domini.

Un aggiornamento sulle sanzioni può diventare un problema di controllo degli accessi. Un’interruzione del cloud può diventare un problema di evasione. Una violazione di un fornitore può diventare sia una questione di risposta agli incidenti sia un problema di assurance verso il cliente. Ecco perché i team responsabili di costruire un robusto programma di cloud security spesso finiscono per migliorare anche la resilienza commerciale. Creano inventario, ownership, logging e visibilità dei controlli che servono anche alle funzioni di trade.

Il rischio commerciale diventa gestibile quando i team smettono di litigare sui confini delle categorie e iniziano a tracciare le dipendenze.

Un test operativo utile

Un’organizzazione matura può rispondere rapidamente a queste domande:

Se queste risposte dipendono dalla memoria, dalla ricerca nella posta in arrivo o da solleciti manuali, l’esposizione è operativa, non teorica.

Stabilire un Framework di Governance e Controllo

La trade risk management fallisce quando è una preoccupazione di tutti e il sistema di nessuno. La governance corregge questo problema non aggiungendo rituali, ma rendendo ripetibili le decisioni.

Un framework solido inizia con un’architettura di policy che esprima l’intento in termini chiari. Quali fornitori rientrano nel perimetro. Quali transazioni richiedono una revisione rafforzata. Quali controlli sono obbligatori per le operazioni regolamentate. Quali eccezioni richiedono approvazione. Le policy non dovrebbero sembrare un archivio legale. Dovrebbero definire regole operative.

Cosa deve collegare la governance

Il livello successivo è una control library, che rende la policy eseguibile. Se la policy afferma che i fornitori critici devono dimostrare resilienza, la control library dovrebbe specificare cosa significa in termini operativi. Documentazione richiesta, frequenza di revisione, tipi di evidenza approvati, percorsi di escalation e gestione dei fallimenti.

Questo funziona solo se l’ownership è esplicita.

• Policy owner definiscono l’intento e mantengono il set di regole.
• Control owner eseguono il processo e correggono i guasti.
• System owner forniscono l’ambiente tecnico e i log.
• Evidence owner garantiscono che gli artefatti siano conservati, accessibili e affidabili.
• Ruoli di oversight esaminano eccezioni, trend di fallimento e dipendenze irrisolte.

Senza questa separazione, le aziende spesso confondono l’amministrazione degli strumenti con la responsabilità. La persona che può esportare un report non è automaticamente quella responsabile del controllo.

Un punto di riferimento pratico per questo modello operativo è third-party risk management in practice, soprattutto quando l’assicurazione sui fornitori deve resistere a revisioni legali, questionari dei clienti e audit.

Dove la governance di solito si rompe

Molti programmi diventano fragili per ragioni prevedibili:

• Le policy sono scollegate dai sistemi. I team dichiarano requisiti che nessun workflow o controllo tecnico applica.
• I controlli sono scritti in modo troppo ampio. “Rivedere regolarmente i vendor” non è un controllo. È un’aspirazione.
• Le eccezioni sono invisibili. Il personale crea workaround perché il percorso formale è troppo lento, e poi nessuno traccia il rischio residuo.
• Le evidenze sono sparse. Procurement ha una vista, security un’altra, legal una terza, e nessuno riesce a ricostruire l’intera catena decisionale.

Il video qui sotto offre un contesto utile sulla governance e sulla supervisione operativa in ambienti ad alto rischio.

Una buona governance è una scelta ingegneristica

I framework di governance più solidi si comportano come un’architettura, non come burocrazia. Collegano la policy dichiarata al controllo eseguibile, all’ownership assegnata, agli eventi registrati e alle evidenze conservate. Ciò significa che un auditor può tracciare un requisito fino a un controllo, e un operatore può tracciare un controllo fallito fino al team responsabile.

Insight operativo: La burocrazia crea documenti. La governance crea decisioni affidabili.

Questa distinzione conta. La prima consuma tempo. La seconda riduce l’incertezza.

Implementazione Pratica e Monitoraggio Continuo

La maggior parte delle organizzazioni ha già alcuni pezzi di un sistema di trade risk. I record dei fornitori sono negli acquisti. Gli alert sono negli strumenti di security. I contratti vivono nei repository legali. I ticket degli incidenti sono nelle piattaforme di service management. Il problema di implementazione non è la mancanza di artefatti. È la mancanza di collegamenti controllati.

Iniziare da perimetro e criticità

Inizia definendo cosa rientra nel perimetro del rischio commerciale. Di solito include fornitori critici, processi cross-border, workflow di pagamento e ordine, partner logistici, piattaforme ospitate esternamente e qualsiasi servizio ICT che supporti attività regolamentate.

Poi classifica la criticità in termini che portino all’azione. “Importante” non basta. I team devono sapere quali fornitori possono interrompere le operazioni, attivare obblighi di notifica, bloccare la produzione di evidenze o creare esposizione legale se falliscono.

Per le aziende soggette a DORA e NIS2, il rischio più importante è spesso il fallimento delle evidenze, non la semplice consapevolezza dell’esposizione. Il problema è dimostrare che la resilienza del fornitore è compresa e controllata. Questo è particolarmente rilevante in Italia, dove l’Agenzia per la Cybersicurezza Nazionale ha riportato un aumento del 23% degli incidenti cyber nel 2024 nel contesto descritto da questa discussione sul trade risk e sulla resilienza normativa.

Integrare l’esecuzione dei controlli nel lavoro quotidiano

I controlli dovrebbero trovarsi dove il lavoro avviene già. Se la revisione dei fornitori è un esercizio annuale separato, resterà indietro rispetto ai cambiamenti operativi. Se onboarding, approvazione degli accessi, modifica contrattuale, gestione degli incidenti e processi di rinnovo richiedono tutti gli stessi campi di evidenza fondamentali, la qualità del controllo migliora perché è il processo stesso a richiederlo.

Un pattern di implementazione utile è questo:

1. Mappare il workflow in modo che ogni processo rilevante per il trade abbia punti di ingresso, approvazioni e percorsi di eccezione chiari.
2. Collegare i controlli agli eventi come onboarding, richieste di modifica, ticket degli incidenti, rinnovi e offboarding.
3. Definire in anticipo l’output delle evidenze includendo log, approvazioni, risultati dei test, attestazioni di policy e note di revisione.
4. Impostare trigger di revisione per cambiamenti materiali, non solo per scadenze di calendario.
5. Escalare i gap irrisolti attraverso ruoli nominati con autorità di accettare, rimediare o interrompere l’attività.

I team che lavorano sulla continuità dovrebbero applicare la stessa logica ai test di resilienza e al ripristino dei servizi. Un modello complementare utile è business continuity and disaster recovery planning, perché la resilienza commerciale dipende dalla capacità dell’azienda di continuare o riprendersi dopo un’interruzione delle attività essenziali.

Misurare ciò che aiuta a intervenire in anticipo

Le metriche lagging creano comfort, non controllo. Indicatori migliori dicono se il sistema sta deragliando.

Queste metriche non devono essere matematicamente complesse per essere utili. Devono spingere all’azione.

Il monitoraggio migliore non produce più dashboard. Riduce il tempo tra il guasto del controllo e l’intervento del responsabile.

L’automazione aiuta, ma non possiede il rischio

Gli strumenti possono raccogliere log, inviare promemoria, riconciliare record e segnalare deviazioni. Questo è prezioso. Ma l’automazione non decide se un’eccezione è accettabile, se un fornitore resta valido o se la progettazione di un controllo è ancora adeguata allo scopo. Un ruolo nominato deve comunque prendere queste decisioni.

Questa è la differenza pratica tra uno strumento e un sistema. Uno strumento esegue attività. Un sistema collega le attività alla responsabilità.

Costruire un Sistema per la Prontezza agli Audit

La prontezza agli audit è spesso trattata come un progetto stagionale. I team sospendono il lavoro normale, rincorrono screenshot, ricostruiscono approvazioni e sperano che nulla di importante sia rimasto in una casella di posta privata. Questo approccio non resiste a un esame serio perché produce artefatti senza dimostrare nel tempo il funzionamento dei controlli.

Un modello migliore è trattare le evidenze come un output operativo. Ogni controllo importante dovrebbe lasciare una traccia quando viene eseguito. Un’approvazione crea un record. Una revisione crea una decisione datata. Un test produce un report. Una modifica di policy crea un aggiornamento versionato. Le impostazioni di accesso e conservazione proteggono l’integrità di quei record una volta creati.

La lezione delle dogane resta valida

Le dogane moderne si sono allontanate dall’ispezione universale per una ragione precisa. La Revised Kyoto Convention dell’Organizzazione Mondiale delle Dogane, entrata in vigore nel 2006, ha formalizzato la gestione del rischio come principio cardine della dogana e ha favorito profiling e ispezioni mirate invece del controllo di tutto, come descritto in questa panoramica sulla risk management nel trading. Questa logica resta utile nelle operazioni di compliance.

Non serve lo stesso livello di revisione umana per ogni evento a basso rischio se il processo è controllato e l’evidenza è affidabile. Serve una supervisione più forte dove la posta in gioco, le eccezioni o l’incertezza sono maggiori.

Cosa devono dimostrare le evidenze

Le evidenze devono rispondere a un piccolo numero di domande difficili:

• Il controllo era definito chiaramente in modo che un operatore potesse eseguirlo in modo coerente?
• Il controllo è stato eseguito quando avrebbe dovuto esserlo in base al processo o al trigger?
• Chi ha eseguito o approvato l’attività, ed era autorizzato a farlo?
• Il risultato era accettabile, oppure è stata sollevata e gestita un’eccezione?
• Il record è affidabile perché conservazione, accesso e integrità erano protetti?

Ecco perché access control, encryption, versioning e audit trail contano. Non sono funzioni decorative di sicurezza. Proteggono la credibilità del set di evidenze stesso.

Evitare la trappola comune della prontezza agli audit

Molti team acquistano automazione e poi replicano vecchie abitudini dentro una nuova interfaccia. Caricano documenti statici, ma non li collegano all’esecuzione dei controlli. Raccolgono evidenze, ma non definiscono l’ownership. Esportano report, ma non sanno spiegare quale decisione supporti il report.

Qui può essere utile confrontare le compliance automation solutions con un approccio molto pratico. Non partire dalle liste di funzionalità. Parti dalla lineage delle evidenze, dalla chiarezza dei ruoli, dall’integrità della conservazione e dal fatto che la piattaforma rifletta i processi operativi reali.

Principio di audit: Un auditor dovrebbe poter seguire un controllo dal requisito all’owner fino all’evidenza senza dover ricostruire la storia a parole.

Progettare per il recupero, non solo per l’archiviazione

La semplice archiviazione non è prontezza. I team hanno bisogno di evidenze indicizzate, circoscritte, attribuibili ed esportabili senza assemblaggi manuali. Se un regolatore chiede prova della supervisione sui fornitori, la risposta dovrebbe arrivare da un set di evidenze controllato, non da una campagna interna improvvisata per raccogliere documenti.

Questo è ciò che “audit-ready” significa in termini operativi. La prova esiste già perché il sistema l’ha prodotta mentre il lavoro era in corso.

Scenari Reali e Metriche Raccomandate

I framework diventano credibili quando resistono sotto pressione. Due scenari mostrano dove la trade risk management funziona o collassa.

Scenario uno con un provider logistico compromesso

Un fornitore logistico di terze parti critico subisce una violazione che coinvolge dati di spedizione, record dei clienti e coordinamento operativo. La tentazione immediata è trattarlo come un problema del fornitore. È l’approccio sbagliato per un’azienda regolamentata.

Se il modello di governance è solido, il team sa già se il provider è nel perimetro, quali servizi sono critici, quali clausole di notifica si applicano, chi possiede l’escalation verso il vendor e quali evidenze esistono dalla due diligence e dalla revisione continua. Security, procurement, legal e operations possono lavorare sullo stesso record di controllo invece di aprire indagini parallele.

Le metriche utili qui sono operative:

• Tempo di risposta agli incidenti di terze parti
• Tempo al triage interno
• Tempo alla decisione su contenimento o sostituzione del servizio
• Disponibilità delle evidenze per la due diligence del fornitore e per l’assurance corrente
• Azioni di remediation aperte per owner

Questo tipo di scenario è importante perché la compromissione della supply chain è ormai sistemica. Ricerche di settore indicano che il 97% delle organizzazioni ha subito una supply chain breach nel 2025, in aumento del 20% rispetto al 2024, e si prevede che gli attacchi alla supply chain software costeranno alle aziende 60 miliardi di dollari nel 2025, in crescita rispetto ai 46 miliardi di dollari del 2023 e fino a 138 miliardi di dollari entro il 2031, secondo questo riepilogo di dati sul rischio della supply chain.

Scenario due con uno shock da sanzioni

Una nuova sanzione geopolitica colpisce un paese in cui un fornitore software chiave svolge funzioni di supporto e sviluppo. Il software può ancora funzionare, ma il rischio commerciale emerge immediatamente nell’esecutività contrattuale, nella continuità del servizio, nell’accesso ai dati e nell’esposizione da concentrazione.

Un’organizzazione matura non inizia chiedendo chi ha il foglio di calcolo più recente. Inizia identificando i fornitori coinvolti, i servizi collegati, le opzioni di fallback, le dipendenze contrattuali e le evidenze correnti della revisione. La decisione può essere continuare con un monitoraggio rafforzato, restringere il perimetro o avviare la pianificazione della sostituzione. Ciò che conta è che la decisione sia evidenziata e assegnata a un owner.

Le metriche utili in questo scenario sono diverse:

I team che vogliono una visione operativa più nitida di quest’area dovrebbero anche definire key risk indicators for control monitoring. I migliori KRI non sono punteggi astratti. Mostrano se l’organizzazione può ancora prendere una decisione tempestiva e difendibile quando le circostanze cambiano.

Conclusione Dalla Difesa Reattiva alla Resilienza Progettata

La trade risk management ha superato il vecchio modello dei controlli finanziari isolati. Hedging, assicurazione e disciplina contrattuale hanno ancora un ruolo, ma non affrontano la sfida centrale delle organizzazioni regolamentate. La parte difficile è costruire un sistema che mostri chi possiede il rischio, quali controlli operano, quali evidenze lo provano e con quanta rapidità l’azienda può rispondere quando fornitori, incidenti o regolatori mettono alla prova il modello.

Questo richiede una mentalità diversa. La compliance deve essere progettata nei workflow. La governance deve collegare la policy all’esecuzione. Il monitoraggio deve rilevare il drift abbastanza presto da permettere un’azione. La prontezza agli audit deve emergere dalle operazioni quotidiane, non da un assemblaggio dell’ultimo minuto.

Le aziende che gestiscono bene il rischio commerciale non fingono che l’incertezza possa essere eliminata. Progettano per tracciabilità, accountability e risposta controllata. Questo è l’aspetto della resilienza nella pratica.

Se ti serve un modo pratico per organizzare controlli, responsabilità ed evidenze per audit orientati a DORA, NIS2 e GDPR, AuditReady è pensato per quel modello operativo. Aiuta i team a definire il perimetro, mappare l’ownership, raccogliere evidenze verificabili e produrre pacchetti pronti per l’audit senza trasformare la compliance in un esercizio di documentazione GRC.