SWIFT

Trasferimenti SWIFT e comunicazione tramite messaggi MT e MX

SWIFT (Society for Worldwide Interbank Financial Telecommunication) è una rete di messaggistica sicura che consente agli istituti finanziari, quali le banche, di inviare e ricevere messaggi standardizzati relativi a operazioni finanziarie, come istruzioni di pagamento e conferme. SWIFT non detiene conti né trasferisce fondi: fornisce semplicemente una piattaforma sicura e affidabile per lo scambio di informazioni.

I normali bonifici SWIFT utilizzano una serie di tipologie di messaggi standardizzati note come messaggi MT (Message Type). Tali messaggi hanno formati e campi predefiniti, che consentono agli istituti finanziari di comprendere ed elaborare con facilità le informazioni in essi contenute.

I messaggi MX (ISO 20022) rappresentano un più recente standard di messaggistica finanziaria basato su XML (eXtensible Markup Language). Offrono un formato più ricco e strutturato, che consente uno scambio di dati più completo e un migliore straight-through processing. I messaggi MX stanno gradualmente sostituendo i messaggi MT nella rete SWIFT, con l'obiettivo di garantire una maggiore interoperabilità e migliori capacità di gestione dei dati.

Pur costituendo da decenni l'ossatura dei pagamenti internazionali, i tradizionali bonifici SWIFT presentano alcuni limiti, tra cui una trasparenza limitata, tempi di elaborazione più lenti e dati non strutturati.

Swift 103+ STP (Straight Through Processing)

Swift 103+ STP era il formato MT legacy ottimizzato per lo Straight Through Processing (STP); dalla fine del periodo di coesistenza il suo ruolo è assunto dalla linea guida di utilizzo STP del messaggio pacs.008. L'STP consente di condurre l'intero processo di pagamento, dall'avvio al regolamento finale, in forma elettronica e senza intervento manuale.

Caratteristiche aggiuntive:

1. Formato standardizzato: richiede il rigoroso rispetto di un formato standardizzato, riducendo errori e ritardi.
2. Elaborazione automatizzata: le transazioni vengono elaborate automaticamente, garantendo un trattamento più rapido ed efficiente.
3. Riduzione dell'intervento manuale: si riduce la necessità di inserimento e verifica manuali, con conseguente diminuzione del rischio di errori e ritardi.
4. Regolamento più rapido: le operazioni vengono regolate più velocemente rispetto ai metodi tradizionali.

Considerazioni per l'STP:

1. Inserimento accurato dei dati: I dati devono essere inseriti con accuratezza per evitare ritardi o rifiuti.
2. Conformità ai requisiti di formato: le banche devono garantire il rigoroso rispetto dei requisiti di formato dell'MT 103+ STP.
3. Software e sistemi: le banche devono disporre di software e sistemi adeguati per gestire efficacemente l'STP

È essenziale distinguere tra messaggistica e regolamento. SWIFT trasmette messaggi finanziari strutturati tra istituzioni, ma non movimenta di per sé fondi né detiene saldi. Una conferma SWIFT, compreso un messaggio pacs.008, è valida solo se corrisponde a una transazione effettivamente elaborata e riconciliata nei sistemi bancari degli istituti partecipanti.

Qualsiasi documento SWIFT, schermata o messaggio presentato in modo isolato e privo di verifica istituzionale non deve essere considerato prova dell'avvenuto regolamento.

Bonifici SWIFT gpi.

SWIFT gpi (Global Payments Innovation):

Lanciata nel 2017, SWIFT gpi è un'iniziativa concepita per superare i limiti dei tradizionali bonifici SWIFT, migliorando la rapidità, la trasparenza e la tracciabilità dei pagamenti transfrontalieri. SWIFT gpi si avvale degli attuali formati di messaggio MT e MX per migliorare i servizi di pagamento. Le principali caratteristiche di SWIFT gpi includono:

• Pagamenti più rapidi: gpi semplifica i processi e stabilisce accordi sul livello di servizio (SLA) più stringenti tra le banche, con conseguenti tempi di esecuzione più brevi delle operazioni, spesso nell'ordine di minuti o secondi.
• Tracciamento dei pagamenti: il gpi Tracker consente il tracciamento in tempo reale delle operazioni, migliorando la trasparenza e riducendo le verifiche manuali.
• Trasparenza sulle commissioni: le banche possono fornire ai clienti, in via preventiva, informazioni sulle commissioni applicate alle operazioni, consentendo decisioni più consapevoli.
• Dati più ricchi: gpi supporta uno scambio di informazioni più dettagliato e strutturato, agevolando una migliore riconciliazione e il rispetto degli obblighi regolamentari.

SWIFT gpi supera i limiti dei tradizionali trasferimenti SWIFT, migliorando i pagamenti transfrontalieri grazie al tracciamento end-to-end, a tempi di elaborazione più rapidi e a dati più completi.

Parametri principali per i partecipanti non aderenti a SWIFT gpi

Quando un soggetto non partecipante a SWIFT gpi (ad esempio una banca o un istituto finanziario non direttamente aderente a gpi) trasmette un'istruzione di pagamento a una banca partecipante a gpi, quest'ultima può convertirla nei formati di messaggio SWIFT richiesti (pacs.008 per i bonifici a favore di clienti, pacs.009 COV per i trasferimenti di copertura e pacs.009 per i bonifici tra istituti finanziari). Tale conversione consente l'elaborazione e il tracciamento all'interno della rete gpi, a condizione che l'istruzione contenga dati sufficienti per compilare i campi obbligatori e rispetti le regole gpi, quali la tracciabilità end-to-end.

I partecipanti non gpi forniscono tipicamente tali parametri tramite schemi di pagamento nazionali, API o formati legacy, mentre la banca gpi gestisce le integrazioni specifiche di gpi (ad esempio la generazione di un UETR, se non fornito, sebbene la sua trasmissione sia facoltativa per le entità non gpi). I requisiti esatti possono variare in funzione della giurisdizione, della valuta e degli accordi bilaterali, ma i parametri essenziali sono tratti dalle linee guida CBPR+ (Cross-Border Payments and Reporting Plus) e dagli standard ISO 20022. Dalla fine del periodo di coesistenza, il 22 novembre 2025, le istruzioni di pagamento transfrontaliere vengono scambiate nel formato ISO 20022; i riferimenti ai campi MT legacy riportati di seguito sono forniti esclusivamente a titolo orientativo.
1. Identificazione delle parti (dati del debitore e del creditore)
Questi dati identificano l'ordinante e il beneficiario, garantendo il rispetto della Raccomandazione 16 del FATF in materia di travel rule.

• Debitore/Cliente ordinante: nome completo, indirizzo strutturato (via, città, codice postale, paese) e identificazione del conto (ad es. IBAN o numero di conto). Nei precedenti MT103/MT202 COV corrisponde al campo 50a; per pacs.008/pacs.009, a <Dbtr> e <DbtrAcct>.
• Cliente creditore/beneficiario: nome completo, indirizzo strutturato e identificativo del conto. Corrisponde al campo 59a dell'ex MT 103/MT 202 COV; <Cdtr> e <CdtrAcct> nei messaggi pacs.008/pacs.009.
• Debitore/creditore finale (se applicabile): Se diversi dalle parti principali, includerne i dati per una maggiore trasparenza (facoltativo ma raccomandato per il tracciamento gpi). Corrisponde a <UltmtDbtr>/<UltmtCdtr> in pacs.008/pacs.009.

Perché è richiesto: consente un corretto instradamento e i controlli regolamentari; dati incompleti possono comportare rifiuti o ritardi.

2. Informazioni su agenti e instradamento
Specifica gli istituti finanziari coinvolti nella catena.

• Debtor Agent: BIC (Bank Identifier Code) o altro identificativo della banca ordinante. Corrisponde al campo 52a dell'ex MT 103; <DbtrAgt> in pacs.008/pacs.009.
• Banca del creditore: BIC della banca ricevente. Corrisponde al campo 57a degli ex MT 103/MT 202 COV; <CdtrAgt> in pacs.008/pacs.009.
• Agenti intermediari (se noti): BIC degli eventuali corrispondenti (fino a 3 livelli). Corrisponde al campo 56a dell'ex MT; <IntrmyAgt1-3> in pacs.008/pacs.009.
• Agenti istruenti/istruiti: BIC del mittente/destinatario immediato nella catena. Facoltativi, ma utili nei metodi seriali o di copertura (cover).
• Agenti istruttori precedenti (se applicabile): per le catene a più passaggi, fino a 3 agenti precedenti.

Perché è richiesto: Garantisce un corretto instradamento tramite gli intermediari; utilizzare il BICFI anziché i nomi per maggiore precisione nei messaggi pacs.009 COV.

3. Dettagli dell'operazione
Elementi finanziari essenziali ai fini del regolamento.

• Importo e valuta: importo del regolamento interbancario e codice di valuta ISO 4217 (ad es. USD, EUR). Corrisponde al campo 32A dei precedenti MT 103/MT 202 COV; <IntrBkSttlmAmt> in pacs.008/pacs.009.
• Importo ordinato (se diverso): importo originario prima delle detrazioni.
• Interbank Settlement Date: data valuta del regolamento. Corrisponde a una parte del campo 32A nell'MT; <IntrBkSttlmDt> in pacs.008/pacs.009.
• Metodo di regolamento: indicare se tramite RTGS (CLRG), cover (COVE) o agente (INDA/INGA). Nessun equivalente MT diretto, ma implicito.

Motivo dell'obbligatorietà: Definisce il trasferimento di valore; obbligatorio per tutti i formati.

4. Riferimenti e identificativi di tracciamento
Per garantire la tracciabilità, in particolare nel gpi.

• Identificazione end-to-end: riferimento che collega l'intera catena (ad es. fattura o ID dell'operazione). <EndToEndId> in pacs.008/pacs.009.
• Instruction Identification: riferimento del mittente (limitato a 16 caratteri nell'MT). Corrisponde al campo 20 del precedente MT; <InstrId> nei messaggi pacs.008/pacs.009.
• Unique End-to-End Transaction Reference (UETR): un UUID per il tracciamento end-to-end. È obbligatorio nei messaggi pacs.008/pacs.009 e, nei precedenti MT103/MT202, nel campo 121; se il canale di origine del pagamento non lo fornisce, la prima banca Swift della catena lo genera.
• Identificazione dell'operazione: ulteriore riferimento interno.

Motivo della richiesta: consente il tracciamento e il collegamento gpi (ad es. da pacs.008 a pacs.009 COV); l'UETR è fondamentale per le conferme universali.

5. Finalità e informazioni sul servizio
Classifica la tipologia di pagamento.

• Codici di finalità (Purpose) e di categoria di finalità (Category Purpose): codici ISO (ad es. SALA per lo stipendio) che indicano la natura dell'operazione. Obbligatori su determinate direttrici; <Purp> e <CtgyPurp> in pacs.008.
• Codice del livello di servizio: identifica il servizio gpi (ad es. G001 per un bonifico gpi a favore della clientela); le banche non aderenti a gpi non devono includere codici specifici gpi salvo diverso accordo. Corrisponde al campo 23E nell'MT; <SvcLvl> nei messaggi pacs.008/pacs.009.
• Local Instrument Code: per schemi specifici (ad es. trasferimenti infragruppo).

Motivo della richiesta: garantisce la conformità normativa e la priorità di elaborazione; sempre più obbligatorio dopo la migrazione allo standard ISO.

6. Rimessa e istruzioni aggiuntive

• Informazioni sulla rimessa: Non strutturate (fino a 140 caratteri) oppure strutturate (ad es. dati della fattura). Corrispondono al campo 70 dell'ex MT 103; <RmtInf> in pacs.008/pacs.009.
• Istruzioni per gli agenti: ad esempio /REC/ per il ricevente, /ACC/ per il conto, oppure istruzioni telefoniche (PHOB). Corrisponde al campo 72 del precedente MT; <InstrForNxtAgt>/<InstrForCdtrAgt> in pacs.008/pacs.009.
• Indicatori dei tempi di regolamento: orari richiesti (ad es. CLSTm per l'orario CLS).

Perché è richiesto: Fornisce il contesto e le istruzioni di gestione; essenziale per i metodi di copertura nei messaggi pacs.009 COV.

7. Dati regolamentari e di compliance

• Segnalazioni regolamentari: codici o dettagli (ad es. codice fiscale, indicatore di segnalazione come CRED/DEB). Corrisponde al campo 77B nei messaggi MT; <RgltryRptg> in pacs.008/pacs.009.
• Codici dei motivi di restituzione (se applicabili alle restituzioni): Ad es. AC04 per conto estinto, nei messaggi pacs.004 collegati ai messaggi originari.

Motivo della richiesta: Soddisfa gli obblighi in materia di AML/KYC e di segnalazione; obbligatorio nei corridoi regolamentati.

Come migliore prassi, i partecipanti non gpi dovrebbero strutturare i dati in modo da evitare il troncamento durante le conversioni da MT a MX e consultare la banca membro gpi per esigenze specifiche. Qualora il pagamento preveda metodi di copertura, i dati del cliente sottostante devono essere riportati in modo identico in tutti i messaggi (ad es., da pacs.008 a pacs.009 COV).

Messaggi di pagamento in SWIFT gpi

Nel quadro di SWIFT gpi (Global Payments Innovation), i messaggi di pagamento originali (ad es. pacs.008 per i bonifici della clientela o pacs.009 COV per i trasferimenti di copertura) sono considerati immutabili una volta inviati. Le banche riceventi non possono modificarne direttamente il contenuto, poiché i messaggi SWIFT sono concepiti per preservare l'integrità e la verificabilità lungo l'intera catena di pagamento. Eventuali modifiche, correzioni o annullamenti sono invece gestiti mediante messaggi successivi distinti, aggiornamenti di stato tramite il gpi Tracker o servizi dedicati come gSRP (gpi Stop and Recall Payment). Ciò garantisce la tracciabilità end-to-end mediante l'Unique End-to-End Transaction Reference (UETR).

Le banche riceventi (che agiscono tipicamente in qualità di banca del creditore o di intermediario) possono tuttavia dare seguito alle richieste di modifica del mittente o avviare azioni che determinano di fatto modifiche all'esito del pagamento (ad esempio storni o blocchi). Possono inoltre richiedere al mittente chiarimenti o rettifiche a determinate condizioni. Tali processi sono disciplinati dai regolamenti di SWIFT, dalle linee guida di prassi di mercato (ad esempio quelle del Payments Market Practice Group – PMPG) e dai requisiti normativi, che privilegiano l'automazione, la trasparenza e la prevenzione delle frodi.

Condizioni alle quali le banche riceventi possono richiedere o agevolare modifiche
Le banche riceventi possono richiedere modifiche (ad es. correzioni di dati) o intraprendere azioni che presuppongono la necessità di una modifica quando il pagamento originario non può essere elaborato secondo le istruzioni ricevute. Ciò avviene tipicamente tramite messaggi di richiesta (ad es. MT 195/199) o risposte a richieste avviate dal mittente. Le condizioni principali comprendono:

• Errori nei dati di pagamento: in caso di inesattezze quali un conto del beneficiario errato (ad esempio un conto chiuso – codice AC04), una valuta errata (codice CURR), un instradamento errato dell'agente (codice AGNT) o problemi tecnici (codice TECH), la banca ricevente può sospendere il pagamento e chiedere all'ordinante di fornire informazioni corrette o di inviare un nuovo pagamento. Ciò evita un rifiuto definitivo consentendo al contempo la risoluzione del problema.
• Impossibilità di accreditare il pagamento: ai sensi del codice CUTA (Cancel Upon Unable to Apply), qualora il pagamento non possa essere accreditato a causa di difformità (ad es. discrepanza di nominativo/conto o dettagli insufficienti), la banca ricevente può richiedere al mittente la cancellazione o i dati di rettifica per porvi rimedio.
• Sospetta frode o operazioni non autorizzate: in caso di frode (codice FRAD), la banca destinataria può rilevare autonomamente le anomalie e avviare la restituzione dei fondi senza una previa richiesta del mittente. Può inoltre dare seguito alle richieste di richiamo del mittente isolando i fondi e richiedendo una manleva (codice INDM) qualora i fondi siano già stati accreditati, al fine di mitigare il rischio prima della restituzione.
• Pagamenti duplicati o indebiti: codici come DUPL (pagamento duplicato) o UPAY (pagamento indebito) consentono alla banca ricevente di segnalare l'operazione e di richiederne l'annullamento se errata o ingiustificata.
• Problemi regolamentari o di compliance: Se il pagamento viola leggi locali, sanzioni o requisiti AML (codice LEGL), la banca ricevente può respingerlo o trattenerlo e richiedere al mittente documentazione aggiuntiva o rettifiche.
• Decisioni del cliente o del beneficiario: Se il beneficiario rifiuta il pagamento (codice CUST o NOAS – nessuna risposta dal beneficiario), la banca ricevente può restituirlo e informarne il mittente, richiedendo eventualmente la conferma delle modifiche.
• Casi in sospeso: per i casi in sospeso (codice PDCR), ad esempio in attesa dell'autorizzazione di addebito (RQDA) o della risposta dell'agente successivo (PTNA), la banca ricevente può trattenere il pagamento e richiedere ulteriori istruzioni o modifiche per procedere.

In ogni caso, le richieste devono essere strutturate in modo da consentirne l'automazione (ad esempio includendo l'UETR, i riferimenti originali quali i campi 20/32A/50/59 e codici specifici nel campo 79 dei messaggi) a supporto dell'elaborazione straight-through. Possono essere richiesti accordi di manleva su base bilaterale qualora i fondi siano accreditati, e la banca ricevente non ha alcun obbligo di accettare le richieste, ma deve dare priorità a quelle urgenti (ad esempio in caso di frode).

Processi coinvolti

• Risposta ai richiami avviati dall'ordinante: L'ordinante (banca del debitore) avvia in genere un richiamo tramite MT 192/292 (o equivalenti ISO 20022 quali camt.056) attraverso il servizio gSRP, inviato in serie o direttamente alla banca ricevente. La banca ricevente deve confermare la ricezione immediatamente e rispondere con MT 196/296 (o MT 199/299 se strutturato), utilizzando codici quali CNCL (annullato), RJCR (rifiutato con motivazione) o PDCR (in sospeso). Se il richiamo è accettato, i fondi vengono restituiti tramite pacs.004 (Payment Return).
• Iniziative autonome delle banche riceventi: Qualora una frode venga rilevata internamente, la banca ricevente può restituire i fondi mediante pacs.004 con informazioni strutturate, dandone comunicazione tramite il Tracker per aggiornamenti di stato in tempo reale.
• Richieste di modifica/chiarimento: le banche riceventi utilizzano messaggi di richiesta (ad es. MT 195/295) per chiedere modifiche, quali informazioni aggiuntive. Ciò avviene frequentemente per i pagamenti sospesi.
• Integrazione con il Tracker: tutte le operazioni aggiornano in tempo reale il gpi Tracker, accessibile tramite API o interfaccia grafica, garantendo visibilità a tutte le parti. I membri gpi sono tenuti a rispettare i regolamenti obbligatori per gCCT (Customer Credit Transfer), gCOV (Cover) e gSRP.
• Limiti e fattori di successo: le modifiche non sono garantite; il successo dipende dalla fase del pagamento (più semplice prima dell'accredito), dalla collaborazione del beneficiario e dalla giurisdizione. Se l'importo è stato accreditato, la restituzione richiede il consenso del beneficiario o una manleva. Le disposizioni regolamentari prevalgono sempre sulle linee guida.

Tali prassi si applicano principalmente ai membri gpi, ma le banche non aderenti al gpi possono partecipare tramite gateway. Per i dettagli più aggiornati si rimanda ai regolamenti ufficiali di SWIFT, poiché i processi sono in evoluzione (ad esempio con la migrazione a ISO 20022).

Separazione tra messaggistica e regolamento in SWIFT gpi

SWIFT gpi gestisce principalmente istruzioni di pagamento e relativo tracciamento tramite messaggistica (ad esempio formati ISO 20022 come pacs.008 per i bonifici della clientela, pacs.009 per i trasferimenti finanziari, oppure i formati tradizionali MT103/MT202), mentre l'effettivo movimento di denaro avviene separatamente a livello di regolamento. Il regolamento avviene tipicamente mediante rapporti di banche corrispondenti (conti Nostro/Vostro), compensazione bilaterale o meccanismi di compensazione e regolamento (Clearing and Settlement Mechanisms, CSM), quali i sistemi di regolamento lordo in tempo reale (Real-Time Gross Settlement, RTGS) (ad esempio T2, già TARGET2, in Europa, Fedwire negli Stati Uniti o CHAPS nel Regno Unito). Il gpi Tracker offre visibilità in tempo reale sullo stato dei messaggi, ma il trasferimento dei fondi si basa su tali sistemi sottostanti.

Il periodo di coesistenza per le istruzioni di pagamento transfrontaliere si è concluso il 22 novembre 2025: le istruzioni di pagamento quali MT103 e MT202 sono state sostituite dai messaggi ISO 20022 (MX) quali pacs.008 e pacs.009, mentre le altre categorie MT saranno dismesse a date successive. Di seguito si illustra come avvengono gli storni e gli sblocchi dei fondi trattenuti a livello di conto, di compensazione e di regolamento.

Come i fondi vengono restituiti a livello di conto, compensazione e regolamento
Le restituzioni vengono avviate a seguito di una richiesta di richiamo andata a buon fine (tramite il servizio gSRP – gpi Stop and Recall Payment) oppure di una rilevazione autonoma (ad esempio frodi, errori). Il gSRP utilizza il messaggio camt.056 (Payment Cancellation Request) trasmesso dalla banca mittente, a cui si risponde con il messaggio camt.029 (Resolution of Investigation). Una volta accolta la richiesta, la restituzione dei fondi viene eseguita mediante una nuova istruzione di pagamento che inverte il flusso, addebitando il conto della banca ricevente e riaccreditando lungo la catena. Non si tratta di una modifica del messaggio originario, bensì di un’operazione distinta.

Principali metodi di regolamento e procedure di restituzione
I metodi di regolamento determinano le modalità di restituzione:

• CLRG (Clearing via Market Infrastructure): regolamento tramite un RTGS o un CSM (ad esempio, per il tramite di una banca centrale). Gli storni utilizzano il messaggio pacs.004 per istruire l'infrastruttura di mercato ad addebitare il conto dell'agente ricevente e ad accreditare quello dell'agente precedente, spesso in tempo reale o nella stessa giornata.
• INGA (Instructing Agent Settles First): Il mittente regola i fondi prima di inviare il messaggio. I resi tramite pacs.004 addebitano il conto dell'agente istruito dopo il regolamento.
• INDA (l'agente istruito regola alla ricezione): il ricevente regola alla ricezione del messaggio. Se il regolamento non avviene, il messaggio viene respinto tramite pacs.002 (nessun movimento di fondi); se il regolamento è avvenuto, i fondi vengono restituiti tramite pacs.004.
• COVE (metodo di copertura): Utilizzato per pagamenti di importo elevato con trasferimento di copertura (pacs.009 COV). Le restituzioni seguono la catena inversa: pacs.004 dall'agente del beneficiario agli intermediari, con addebito e accredito dei conti di corrispondenza di conseguenza.

Procedura di restituzione passo per passo a livello di regolamento

1. Avvio e accettazione: il mittente richiede il richiamo (ad esempio tramite camt.056 con UETR). Il destinatario risponde (camt.029) e accetta se i fondi sono disponibili o non ancora accreditati al beneficiario (più agevole prima dell'accredito). Se i fondi sono già stati accreditati, può essere necessario il consenso del beneficiario o una manleva.

2. Istruzione di restituzione dei fondi: il ricevente emette un messaggio pacs.004 (Payment Return) oppure un MT 103/MT 202 tradizionale con codici di restituzione (ad es. RETN). Tale messaggio comprende:

• Riferimenti originali (UETR, End-to-End ID, Instruction ID).
• Ruoli invertiti: il creditore originario diventa debitore; l'agente del debitore originario diventa creditore.
• Dettagli di regolamento: importo e data di regolamento interbancario originari, tasso di cambio (in caso di operazione in cambi), commissioni (se dedotte).
• Codice del motivo di restituzione (ad es. AC04 per conto chiuso, FRAD per frode).
• Campo Settlement Account (se presente nel messaggio originale) per indicare il conto da accreditare.

3. Esecuzione del regolamento:

• Il messaggio pacs.004 determina l'addebito sul conto Nostro/Vostro della banca ricevente (detenuto presso l'agente precedente o l'MI).
• I fondi vengono riaccreditati nodo per nodo lungo la catena, utilizzando lo stesso metodo di regolamento (ad esempio, un trasferimento RTGS in CLRG).
• In caso di restituzione parziale, indicare «PART» nelle Informazioni aggiuntive con l'importo proporzionale.
• Il tracker aggiorna lo stato (ad es. «Returned») in tempo reale, consultabile tramite API o GUI.

4. Accredito finale: il conto dell'ordinante originario viene accreditato, spesso al netto delle commissioni. Se l'operazione transita attraverso un CSM, il regolamento è atomico; negli schemi bilaterali può comportare un netting a fine giornata.

5. Notifiche successive alla restituzione: Utilizzare camt.053/054 (estratto conto / notifica di addebito-accredito) per confermare l'aggiornamento delle registrazioni contabili. Non è previsto un ulteriore pacs.004 per la «restituzione di una restituzione»: utilizzare invece le richieste di indagine.
Le restituzioni sono automatizzate ove possibile, ma può rendersi necessario un intervento manuale per ragioni di compliance o qualora i fondi siano congelati. Il recupero non è garantito; dipende soprattutto dalla rapidità con cui viene inviato il richiamo e dal fatto che i fondi siano già stati accreditati. In caso di mancato regolamento (ad es. rifiuto prima del regolamento), non si ha alcun movimento di fondi: utilizzare invece pacs.002.

Come vengono rilasciati (autorizzati) i pagamenti sospesi a livello di conto, compensazione e regolamento

Si ha un blocco (hold) quando un pagamento non può essere elaborato immediatamente (ad esempio per errori, controlli di compliance o in attesa di chiarimenti) e viene collocato in stato «pending» senza regolamento. Fino alla risoluzione non viene effettuato alcun addebito o accredito. Il gpi Tracker mostra stati quali «On Hold» o «Pending» (ad esempio il codice PDCR); la risoluzione avviene mediante messaggi di richiesta (MT 195/199 o camt.029).

Condizioni che determinano un blocco

• Discrepanze (ad es. incongruenza tra conto e nominativo – codice CUTA).
• Controlli regolamentari (ad es. sanzioni – codice LEGL).
• In attesa della risposta del beneficiario (codice NOAS) o dell'autorizzazione all'addebito (RQDA).
• Orari di inattività o elaborazione in batch presso la banca del beneficiario.

Procedura di rilascio a livello di regolamento
1. Notifica di blocco: il ricevente invia un messaggio pacs.002 (aggiornamento di stato) o un MT 199 con codice di sospensione, trattenendo i fondi su un conto transitorio/vincolato (escrow) in caso di regolamento parziale (ad esempio nei metodi di cover).
2. Risoluzione: il mittente fornisce le modifiche o i chiarimenti necessari (ad esempio mediante risposta MT 195 o camt.029). Se la questione è risolta, il ricevente dà il proprio via libera dando corso all'istruzione originaria.
3. Esecuzione del regolamento:

• Il messaggio originale pacs.008/pacs.009 viene rilasciato dal blocco.
• I fondi vengono regolati secondo il metodo specificato: addebito sul conto dell'ordinante, accredito sul conto del destinatario (ad esempio tramite RTGS in CLRG) e infine accredito definitivo sul conto del beneficiario.
• La fase del beneficiario (dalla banca ricevente al cliente finale) è spesso quella in cui si verificano i ritardi, in particolare nei mercati con controlli sui capitali o infrastrutture limitate.
• Il tracker passa allo stato «Accreditato» o «Completato», con conferma tramite pacs.002 (Payment Status Report).

4. In caso di mancato rilascio: se la questione resta irrisolta (ad esempio, dopo la scadenza del termine), restituire tramite pacs.004 come sopra indicato, oppure respingere con pacs.002 (nessun regolamento).

Le regole gpi prevedono, ove possibile, l'accredito nello stesso giorno; nel 2018 Swift ha riferito che quasi il 50% dei pagamenti gpi veniva accreditato entro 30 minuti e la quasi totalità entro 24 ore. Fattori quali i controlli sui capitali o gli orari di chiusura delle banche possono prolungare i tempi di blocco, ma gpi punta sull'automazione per ridurli al minimo.

SwiftNet Instant

SwiftNet Instant. È una piattaforma di messaggistica in tempo reale, a bassa latenza, disponibile 24 ore su 24, 7 giorni su 7, che supporta lo scambio sicuro di flussi di pagamento istantanei tra i meccanismi di compensazione e regolamento (CSM) e i rispettivi partecipanti.

I clienti possono collegarsi a SwiftNet Instant tramite l'infrastruttura di connettività e sicurezza Swift già in uso, compresi VPN box, linee dedicate e moduli di sicurezza hardware. L'integrazione con l'ambiente informatico della banca avviene tramite l'Alliance Gateway Instant (AGI).

Tutte le parti lungo la catena dei pagamenti istantanei possono utilizzare AGI e la messaggistica SwiftNet Instant. Le applicazioni comprendono l'avvio di pagamenti da un servizio overlay, le comunicazioni tra un membro indiretto e il relativo membro sponsor oppure la ricezione, da parte di un'impresa, della conferma di un pagamento.

SWIFT Instant si collega ai sistemi nazionali di pagamento istantaneo per consentire l'elaborazione delle transazioni in tempo reale, sia a livello nazionale sia internazionale, utilizzando lo standard ISO 20022. Tali sistemi rappresentano gli sforzi in corso per modernizzare e semplificare i processi di pagamento nel settore finanziario.

Addebito diretto SWIFT

L'addebito diretto nel sistema SWIFT è un metodo di pagamento che consente a imprese e privati di incassare fondi da conti bancari di debitori in più valute e in diversi paesi. A differenza dell'addebito diretto SEPA, concepito specificamente per l'area SEPA e limitato alle operazioni denominate in euro, l'addebito diretto in SWIFT ha una portata globale e supporta un'ampia gamma di valute.

Il processo di avvio di un addebito diretto nell'ambito del sistema SWIFT comprende, di norma, le seguenti fasi:

1. Accordo tra creditore e debitore: Il creditore e il debitore devono aver preventivamente concluso un accordo che definisca i termini e le condizioni delle operazioni di addebito diretto. Tale accordo può comprendere anche il rilascio di un mandato o di un'autorizzazione che consenta al creditore di incassare i pagamenti dal conto bancario del debitore.
2. Scambio di messaggi: La banca del creditore avvia l'addebito diretto inviando un messaggio SWIFT alla banca del debitore – in ISO 20022 un pacs.003 (addebito diretto della clientela) o un pacs.010 (addebito diretto tra istituzioni finanziarie), in precedenza MT 104 o MT 204. Tale messaggio contiene i dettagli dell'operazione, quali importo, valuta, coordinate del conto del debitore ed ogni altra informazione necessaria.
3. Verifica e autorizzazione: la banca del debitore verifica i dettagli dell'operazione, controlla la disponibilità dei fondi sul conto del debitore e conferma l'autorizzazione all'operazione. Se tutto è in ordine, la banca del debitore procede ad addebitare i fondi sul conto del debitore.
4. Trasferimento dei fondi: i fondi vengono regolati tra la banca del debitore e la banca del creditore tramite conti di corrispondenza o un sistema di compensazione e regolamento.
5. Conferma: alla ricezione dei fondi, la banca del creditore invia al creditore un messaggio di conferma, notificandogli il buon esito dell'addebito diretto.

I presupposti per l'avvio di un'operazione di addebito diretto nel sistema SWIFT sono i seguenti:

1. Conti bancari: sia il creditore sia il debitore devono essere titolari di conti presso istituti finanziari aderenti alla rete SWIFT.
2. Accordo e autorizzazione: per consentire le operazioni di addebito diretto deve sussistere un accordo preventivo e un'autorizzazione (mandato) tra creditore e debitore.
3. Formati dei messaggi SWIFT: il creditore e la sua banca devono utilizzare i formati di messaggio appropriati: pain.008 per disporre un addebito diretto, pacs.003 o pacs.010 tra banche.
4. Commissioni bancarie: il creditore e il debitore devono essere consapevoli di eventuali commissioni connesse alle operazioni di addebito diretto all'interno del sistema SWIFT, poiché tali commissioni possono variare a seconda delle banche e dei paesi coinvolti.

RMA nella messaggistica interbancaria SWIFT

Nel settore bancario e finanziario, una comunicazione sicura ed efficiente tra le banche è essenziale. È qui che SWIFT (Society for Worldwide Interbank Financial Telecommunication) svolge un ruolo cruciale, veicolando la maggior parte dei messaggi interbancari internazionali. Una componente determinante per garantire la sicurezza e la selettività di tali comunicazioni è la Relationship Management Application (RMA).

Che cos'è la RMA?

La Relationship Management Application (RMA) è un'applicazione software SWIFT che consente agli istituti finanziari di definire quali controparti possano inviare loro messaggi SWIFT e garantisce che la comunicazione sulla rete SWIFT sia limitata ai soli utenti autenticati. L'RMA è uno strato di sicurezza fondamentale nella gestione della comunicazione interbancaria, in quanto filtra i messaggi non autorizzati e riduce il rischio di frode.

L'importanza dell'RMA

Per le banche attive nella finanza internazionale, come IFB, lo strumento RMA è indispensabile. Esso non solo rafforza i protocolli di sicurezza, ma garantisce anche la conformità alla normativa bancaria globale. Gestendo quali istituti possano inviare loro messaggi, le banche possono prevenire richieste di informazioni e istruzioni finanziarie non autorizzate, tutelando sia i propri interessi sia quelli della clientela.

Come funziona la RMA

Il processo RMA si articola in diverse fasi fondamentali:

1. Instaurazione di relazioni RMA: prima di poter scambiare informazioni tramite SWIFT, due banche devono concordare reciprocamente l'istituzione di un RMA. Tale accordo equivale a una stretta di mano digitale, che esprime fiducia e consenso a comunicare.
2. Scambio delle chiavi: ciascuna banca invia un'autorizzazione RMA tramite l'applicazione RMA, che la controparte accetta. L'RMA ha sostituito il precedente scambio bilaterale di chiavi (BKE); i messaggi stessi sono autenticati tramite SWIFTNet PKI (Public Key Infrastructure).
3. Configurazione delle impostazioni RMA: ciascuna banca utilizza lo strumento RMA per configurare le autorizzazioni e specificare quali tipi di messaggi accettare dall'altra banca. Ciò può avvenire per categorie generali oppure in modo mirato, includendo specifici tipi e sottoclassi di messaggi.
4. Attivazione e monitoraggio: una volta configurate e attivate le impostazioni RMA, le banche possono monitorare i messaggi in entrata per verificarne la conformità alle autorizzazioni stabilite. L'RMA offre inoltre strumenti per modificare o revocare le autorizzazioni qualora lo richiedano esigenze operative o di sicurezza.

Applicazioni pratiche

Per IFB, che è specializzata in servizi di investimento e gestione patrimoniale per soggetti di elevato patrimonio e società, la RMA offre diversi vantaggi:

• Maggiore sicurezza: Controllando il traffico dei messaggi, IFB può proteggere le operazioni e le informazioni sensibili dei clienti da accessi non autorizzati.
• Efficienza operativa: comunicazioni snelle con soggetti attendibili consentono un'elaborazione più rapida dei messaggi legittimi, migliorando i tempi di risposta e la soddisfazione della clientela.
• Conformità normativa: la RMA agevola il rispetto delle normative bancarie internazionali, che impongono un rigoroso controllo sullo scambio di informazioni al fine di prevenire reati finanziari quali il riciclaggio di denaro e la frode.

RMA e MT799. Le banche possono utilizzare un MT799 per richiedere o coordinare una relazione RMA, purché il canale lo consenta. L'autorizzazione RMA in sé viene concessa nel sistema RMA; un MT799 da solo non attiva alcuna autorizzazione. Qualora manchi l'autorizzazione RMA richiesta per l'MT799, essa non può essere aggirata inviando direttamente un MT799. La configurazione viene allora concordata mediante la funzione di comunicazione RMA del Relationship Management Portal di Swift, concepita per il coordinamento con le controparti prima dello scambio delle autorizzazioni, oppure attraverso un altro canale consentito. «RMA tramite MT799» può quindi designare la corrispondenza bancaria di accompagnamento; l'autorizzazione RMA tecnica costituisce una fase distinta.

In sintesi

Per IFB, l'efficace attuazione della RMA non è soltanto un requisito tecnico, ma un asset strategico nelle sue attività globali. Essa rafforza l'impegno della Banca per la sicurezza e la conformità regolamentare, migliorando al contempo l'efficienza delle sue reti di comunicazione. Con l'evoluzione del contesto della finanza internazionale, strumenti come la RMA restano essenziali nel patrimonio di strumenti delle banche impegnate a mantenere i più elevati standard di integrità operativa e di servizio alla clientela.

Gli RMA costituiscono la struttura portante di una comunicazione interbancaria sicura e selettiva, garantendo che ogni messaggio scambiato tramite la rete SWIFT rispetti i più elevati standard di sicurezza e sia pienamente autenticato. Per banche come IFB, comprendere e gestire gli RMA è essenziale per tutelare la propria operatività e consolidare la fiducia dei partner globali.

Istruzioni finanziarie blockchain digitali Swift

Nel settembre 2025 Swift ha annunciato di aver avviato, insieme a oltre 30 istituti finanziari, la progettazione e lo sviluppo di un registro digitale condiviso. Il 9 luglio 2026 Swift ha dichiarato il registro pronto per il primo utilizzo, con 17 banche in preparazione per avviare un progetto pilota di transazioni reali in depositi tokenizzati: ANZ, BNP Paribas, BNY, Citi, DBS, First Abu Dhabi Bank, FirstRand, HSBC, Itaú Unibanco, Lloyds, Mashreq, MUFG, OCBC, Standard Chartered, UBS, UOB e Wells Fargo. La prima applicazione sarà incentrata sull'abilitazione di istruzioni transfrontaliere in tempo reale, 24 ore su 24, 7 giorni su 7, tra banche – un miglioramento decisivo per il tessuto dell'elaborazione delle transazioni internazionali.

Il primo prototipo concettuale è stato realizzato con Consensys. Il registro è concepito come un libro mastro sicuro, immutabile e in tempo reale delle istruzioni finanziarie tra istituzioni. Registrerà, sequenzierà e convaliderà i messaggi relativi alle transazioni, applicando al contempo regole operative e di compliance tramite smart contract. L'interoperabilità è un principio centrale: il registro si collegherà sia alle infrastrutture esistenti sia a quelle emergenti, mantenendo la resilienza, l'affidabilità e la conformità normativa che contraddistinguono Swift.

Come ha spiegato Javier Pérez-Tasso, Chief Executive di Swift:
«La combinazione di un registro condiviso con la messaggistica, le API e lo standard ISO 20022 già offerti da Swift dà vita a una struttura ancora più potente, in grado di integrare fin dall'origine nei flussi transazionali i requisiti di rischio, controllo e compliance, consentendo al contempo istruzioni interbancarie transfrontaliere in tempo reale, 24 ore su 24 e 7 giorni su 7, con la stessa affidabilità, sicurezza, resilienza, scalabilità ed eccellenza operativa per cui Swift è nota. Il tutto in linea con l'approccio di innovazione responsabile che abbiamo sempre adottato.»

Estensione dell'infrastruttura

Il registro condiviso integra le infrastrutture esistenti di Swift; non le sostituisce. È concepito per ampliare l'orchestrazione e l'interoperabilità, consentendo agli istituti finanziari di scambiarsi istruzioni più rapidamente, con maggiore prevedibilità e su scala realmente globale.

In occasione di Sibos, Pérez-Tasso ha sottolineato questo approccio su due binari:
«Le infrastrutture finanziarie devono mantenere un'attenzione costante sui fondamentali dell'eccellenza operativa, della conformità normativa e della governance. Allo stesso tempo, devono prepararsi al futuro. In Swift il nostro approccio consiste nell'innovare su due binari paralleli.»

Collaborazione in tutto il settore

Istituzioni finanziarie di 16 paesi sono state coinvolte fin dall'inizio nella definizione dell'impostazione, della governance e del percorso di sviluppo del registro condiviso. Questo impegno collettivo sottolinea una consapevolezza comune: far progredire l'infrastruttura globale per le istruzioni interbancarie richiede scala e collaborazione.

Prospettive future

Il registro condiviso rappresenta una naturale evoluzione delle precedenti sperimentazioni di Swift sugli asset digitali e rientra in un più ampio impegno a favore dell'interoperabilità tra reti pubbliche e private. Ciò consentirà a valore tokenizzato regolamentato e a strumenti tradizionali di circolare agevolmente tra i diversi sistemi.

Pérez-Tasso ha riassunto la visione:
«Questa è una piattaforma potente per il futuro. E in futuro potrà essere ancora più trasformativa.»

Domande frequenti

Che cos'è il registro condiviso basato su blockchain di Swift?
Un'infrastruttura blockchain che fornisce un registro condiviso e in tempo reale delle istruzioni finanziarie tra istituzioni, consentendo un'elaborazione transfrontaliera continua e conforme.

A chi si rivolge?
Banche e istituti finanziari che devono fornire istruzioni di transazione più rapide e trasparenti, preparandosi al contempo al futuro digitale.

Quali sono i vantaggi?

• Visibilità in tempo reale e sequenziamento delle istruzioni
• Compliance automatizzata tramite smart contract
• Interoperabilità tra reti tradizionali e digitali
• Gestione sicura di flussi regolamentati di valore tokenizzato

Come si inserisce nella piattaforma di Swift?
Estende l'infrastruttura affidabile di Swift, integrando funzionalità di istruzioni digitali e mantenendo al contempo resilienza, sicurezza e compliance.

Qual è il primo caso d'uso?
Istruzioni di transazione interbancaria transfrontaliera in tempo reale, 24 ore su 24, 7 giorni su 7.

Chi è coinvolto?
Oltre 30 istituzioni finanziarie di 16 Paesi hanno contribuito a definirne l'impostazione; 17 banche stanno sperimentando le prime operazioni in produzione.

Quando sarà disponibile?
Swift ha dichiarato il ledger pronto per l'utilizzo iniziale il 9 luglio 2026. Le banche pilota eseguono le prime transazioni reali in una fase di avvio controllata; il regolamento definitivo continua ad avvenire attraverso i sistemi esistenti. Funzionalità e disponibilità saranno ampliate in seguito.

Per maggiori informazioni sul trasferimento di fondi attraverso il sistema delle banche corrispondenti, La invitiamo a contattare il nostro Responsabile delle Banche corrispondenti, il Sig. Amri Elarisse.