Trasferimenti IP/IP e IPZip

IP to IP (IPIP)

I trasferimenti da IP a IP costituiscono una fase del processo di trasferimento di valuta o di attività, passività e patrimonio netto, o di dati, dai conti di banche corrispondenti tra diverse istituzioni finanziarie o diversi sistemi, mediante l'uso di indirizzi Internet Protocol (IP). Nel contesto delle operazioni finanziarie, l'indirizzo IP è un identificativo numerico univoco assegnato a ogni dispositivo connesso a internet e viene utilizzato per instradare le informazioni tra sistemi diversi. In ambito bancario, i trasferimenti da IP a IP comportano la comunicazione diretta tra due sistemi attraverso i rispettivi indirizzi IP, al fine di eseguire un'operazione finanziaria. A tutela dell'integrità e della sicurezza delle informazioni si applicano, a livello ulteriore, specifici metodi di autenticazione e autorizzazione.

È tuttavia importante rilevare che i trasferimenti da IP a IP non sono diffusi né raccomandati nel settore bancario, per diverse ragioni, tra cui motivi di sicurezza, affidabilità e conformità. I punti seguenti forniscono un contesto in merito a tali criticità:

1. Sicurezza: i trasferimenti da IP a IP possono risultare meno sicuri rispetto alle reti bancarie consolidate, come SWIFT o ACH, che adottano molteplici livelli di sicurezza, crittografia e autenticazione. La comunicazione diretta tra due indirizzi IP può esporre informazioni sensibili a potenziali minacce, tra cui hacking, phishing o attacchi man-in-the-middle.
2. Affidabilità: il ricorso ai trasferimenti da IP a IP non garantisce l'affidabilità della transazione, poiché nel settore bancario non esistono standard o protocolli universalmente riconosciuti per i trasferimenti basati su IP. Ciò può determinare criticità nell'elaborazione, nel tracciamento e nella riconciliazione delle transazioni.
3. Compliance: Le banche e gli istituti finanziari sono soggetti a numerose normative e requisiti, tra cui le politiche in materia di antiriciclaggio (AML) e di conoscenza della clientela (KYC). I trasferimenti da IP a IP possono non rispettare tali requisiti regolamentari, esponendo potenzialmente le parti coinvolte a rischi legali e finanziari.

In luogo dei trasferimenti da IP a IP, le banche e gli istituti finanziari preferiscono avvalersi di reti consolidate, quali SWIFT, RTGS o ACH/pagamenti istantanei, e di standard di messaggistica come ISO 20022 per eseguire trasferimenti di fondi sicuri, affidabili e conformi tra istituzioni diverse.

Le principali differenze tra server di comunicazione e server di contabilità/conti nelle banche

Nella tecnologia bancaria, i server svolgono un ruolo decisivo nel garantire il regolare funzionamento delle transazioni finanziarie e della tenuta delle registrazioni. Le due principali tipologie di server su cui si basano le banche sono i server di comunicazione e i server di contabilità/conti. Pur essendo entrambi essenziali, rispondono a finalità distinte e trattano tipologie diverse di dati.

Server di comunicazione

I server di comunicazione costituiscono la struttura portante dello scambio sicuro di dati tra banche e istituzioni finanziarie. Di seguito le principali funzioni e caratteristiche dei server di comunicazione:

1. Scambio sicuro di dati: questi server consentono lo scambio sicuro di dati, assicurando che le informazioni finanziarie sensibili possano essere trasmesse tra istituzioni senza essere compromesse.
2. Protocolli e standard: utilizzano protocolli standardizzati quali SWIFT, SEPA o ACH, ecc., per la comunicazione interbancaria, garantendo uniformità e affidabilità tra piattaforme diverse.
3. Crittografia e autenticazione: per garantire la sicurezza, i server di comunicazione impiegano metodi di crittografia avanzati e rigorosi protocolli di autenticazione, a tutela dei dati durante la trasmissione.
4. Gestione delle transazioni: in primo luogo, gestiscono le richieste, i messaggi e le istruzioni relativi alle transazioni, fungendo da intermediari che trasmettono le informazioni necessarie per il loro perfezionamento.
5. Nessun movimento di fondi: è importante precisare che tali server non movimentano fondi né aggiornano direttamente i saldi dei conti; essi si limitano ad agevolare la comunicazione necessaria per tali operazioni.

Server di registro/conti

I server contabili (ledger) sono invece i custodi dei registri finanziari di una banca. Ecco le loro principali caratteristiche:

1. Tenuta delle registrazioni finanziarie: questi server conservano e gestiscono le registrazioni finanziarie fondamentali della banca, assicurando che ogni transazione sia registrata con precisione.
2. Registrazione delle operazioni: registrano tutte le operazioni, inclusi addebiti e accrediti, e sono responsabili dell'aggiornamento e della conservazione dei saldi correnti dei conti.
3. Gestione del libro mastro generale: i server del libro mastro gestiscono il libro mastro generale della banca insieme ai singoli conti dei clienti, offrendo una visione completa della solidità finanziaria.
4. Integrità dei dati: garantire la coerenza e l'integrità dei dati è essenziale, poiché tali registrazioni sono indispensabili per un'informativa finanziaria accurata e per la conformità normativa.
5. Solide misure di sicurezza: data la sensibilità dei dati, i server ledger adottano in genere misure di sicurezza più rigorose, tra cui ulteriori livelli di crittografia e rigorosi controlli di accesso.

Il server di comunicazione avvia e agevola le transazioni, ma è il server contabile a registrarle e a rifletterle definitivamente, dopo la convalida, nei libri della banca.

Nei sistemi bancari contemporanei, tali funzioni sono spesso integrate, con protocolli di comunicazione intra-bancaria sicuri che operano in sinergia con i sistemi di gestione dei registri contabili. Questa integrazione garantisce aggiornamenti in tempo reale e coerenza in tutto l'ecosistema finanziario della banca, rafforzando al contempo efficienza e sicurezza. Molte banche utilizzano una combinazione di server on-premises e basati su cloud per bilanciare requisiti di sicurezza, conformità e scalabilità.

Trasferimento effettivo di attività, passività e patrimonio netto: i trasferimenti di titoli sono registrati dai depositari centrali di titoli (CSD), che tengono il registro legale della titolarità; i prestiti, le immobilizzazioni e le altre posizioni si trasferiscono mediante cessione o accordi di trasferimento ai sensi della legge applicabile. Entrambi esulano dall'ambito dei protocolli di comunicazione. Il trasferimento di attività e di strumenti di patrimonio incide inoltre sui bilanci delle banche, modificando le passività, le attività e il patrimonio netto. Tale informativa finanziaria alle autorità di controllo competenti e il necessario aspetto di compliance esulano dalle capacità di trasmissione dei dati dei protocolli e richiedono ulteriori processi finanziari e regolamentari.

In sostanza, se i protocolli sono essenziali per lo scambio sicuro ed efficiente di informazioni nelle operazioni IPIP, il processo completo comprende ulteriori sistemi per l'effettivo trasferimento di valuta, attività, passività e capitale, il regolamento, la registrazione giuridica e la rendicontazione finanziaria, in modo che l'intera operazione sia eseguita nel rispetto degli standard regolamentari bancari.

Trasferimento IP ZIP

Trasmissione sicura basata su file di istruzioni di pagamento istituzionali

Un IP ZIP Transfer è da intendersi come un metodo sicuro, basato su file, per trasmettere istruzioni di pagamento strutturate e i relativi dati di transazione direttamente tra sistemi istituzionali autenticati attraverso una rete Internet Protocol.

La terminologia richiede una precisione particolare.

Una trasmissione IP ZIP non è un sistema di compensazione, un sistema di regolamento, un canale di pagamento né un meccanismo autonomo di trasferimento di valore monetario. L'archivio ZIP è un contenitore di trasporto. La connessione IP è il canale di comunicazione. Le informazioni contenute nell'archivio costituiscono un'istruzione, un insieme di dati o un messaggio di transazione.

Di conseguenza:

IP ZIP trasmette informazioni e istruzioni di pagamento. Di per sé, non effettua il regolamento dei fondi.

Dal punto di vista concettuale, ciò è paragonabile alla distinzione applicabile a un messaggio ISO 20022 pacs.008 (FI-to-FI Customer Credit Transfer). Un messaggio pacs.008 può veicolare un'istruzione di bonifico interbancario altamente strutturata, ma il messaggio in sé non deve essere confuso con l'effettivo trasferimento e regolamento di moneta di banca centrale, moneta di banche commerciali o saldi dei conti presso banche corrispondenti.

Lo stesso principio si applica a una trasmissione IP ZIP.

2. Il file ZIP come contenitore sicuro delle operazioni

Il componente ZIP funge principalmente da meccanismo di contenitorizzazione e di confezionamento.

Anziché trasmettere separatamente i singoli componenti dell'operazione, l'istituto ordinante può raccogliere i file pertinenti in un unico pacchetto controllato.

A seconda della specifica bilaterale concordata, tale pacchetto può contenere:

• istruzioni di pagamento strutturate;
• Messaggi di pagamento in formato XML;
• insiemi di dati compatibili con ISO 20022;
• oggetti di transazione JSON;
• record di transazioni in formato CSV o a formato fisso;
• file di pagamento interbancari proprietari;
• informazioni sul debitore e sul creditore;
• informazioni sul conto di origine e sul conto del beneficiario;
• identificativi delle transazioni;
• informazioni su valuta e importo;
• date di esecuzione e di valuta richieste;
• istruzioni alla banca corrispondente;
• informazioni sulla banca intermediaria;
• informazioni di rimessa;
• informazioni sull'instradamento del regolamento;
• documentazione di compliance;
• Riferimenti KYC o KYB;
• informazioni sull'origine dei fondi;
• manifesti delle transazioni;
• firme digitali;
• hash crittografici;
• certificati;
• marcature temporali (timestamp);
• file di riconciliazione; e
• totali di controllo.

L'archivio può pertanto contenere sia l'istruzione di pagamento primaria sia le informazioni accessorie necessarie per autenticare, convalidare, elaborare e riconciliare tale istruzione.

Dal punto di vista tecnico, la compressione è meramente accessoria. La finalità principale è il confezionamento e la trasmissione controllati.

Un archivio ZIP non deve pertanto mai essere considerato prova dell'esistenza, della disponibilità, dell'assenza di vincoli o dell'avvenuto regolamento dei fondi rappresentati al suo interno.

3. Istruzione di pagamento strutturata

Ove opportunamente strutturata, l'istruzione di pagamento contenuta in un pacchetto IP ZIP può svolgere una funzione analoga a quella dei convenzionali messaggi finanziari strutturati.

A titolo di esempio, un istituto potrebbe trasmettere un'istruzione XML contenente campi corrispondenti alle informazioni normalmente riportate in un messaggio ISO 20022 pacs.008, tra cui:

• identificazione del messaggio;
• data e ora di creazione;
• numero di operazioni;
• informazioni di regolamento;
• agente ordinante;
• agente ricevente (instructed agent);
• debitore;
• conto del debitore;
• agente del debitore;
• agente del creditore;
• creditore;
• conto del creditore;
• importo ordinato;
• valuta;
• soggetto che sostiene le spese;
• identificazione del pagamento;
• identificazione end-to-end; e
• informazioni sulla rimessa.

La distinzione fondamentale è che la struttura dei dati non determina il meccanismo di regolamento.

Un'istruzione di pagamento tecnicamente valida può essere ricevuta, autenticata e accettata dal sistema ricevente, mentre il corrispondente regolamento finanziario resta in sospeso.

Pertanto:

Istruzione ricevuta ≠ fondi ricevuti

Istruzione autenticata ≠ fondi regolati

File importato correttamente ≠ beneficiario accreditato con fondi definitivi

Conferma di ricezione del server ≠ conferma di regolamento

Tale distinzione è fondamentale per il trattamento che IFB riserva alle metodologie alternative di trasferimento.

4. Protocolli di trasmissione

Le trasmissioni istituzionali IP ZIP devono avvenire esclusivamente all'interno di un ambiente di comunicazione controllato e autenticato.

A seconda dell'accordo tecnico bilaterale, la trasmissione può avvenire mediante tecnologie quali:

SFTP

Il Secure File Transfer Protocol su SSH assicura un trasporto cifrato, l'autenticazione del server e un'autenticazione controllata degli utenti.

Per la connettività istituzionale, l'autenticazione a chiave pubblica dovrebbe di norma essere preferita alla sola autenticazione tramite password.

FTPS

L'FTP può essere protetto mediante TLS ove l'infrastruttura preesistente lo richieda, a condizione che siano implementati adeguati controlli di validazione dei certificati, standard di cifratura e controlli degli accessi.

HTTPS / REST API

Il pacchetto può essere trasmesso tramite un endpoint HTTPS autenticato o un'architettura API che utilizzi TLS e un'adeguata autenticazione a livello applicativo.

Mutual TLS

Per le connessioni istituzionali a più elevato livello di garanzia, il mutual TLS (mTLS) consente a entrambi i punti di connessione di autenticarsi reciprocamente mediante certificati digitali.

Ciò garantisce una protezione sostanzialmente più solida contro endpoint non autorizzati rispetto alla sola autenticazione unilaterale del server.

VPN

Una VPN IPSec site-to-site, o equivalente, può stabilire un tunnel privato cifrato tra gli istituti partecipanti prima che avvenga la trasmissione a livello applicativo.

Connettività privata dedicata

Laddove i volumi delle transazioni, i requisiti di sicurezza o i profili di rischio istituzionali lo giustifichino, la connettività di rete dedicata o privata può integrare o sostituire la trasmissione attraverso la rete Internet pubblica.

Il protocollo preciso deve essere concordato bilateralmente prima dell'attivazione operativa.

5. Autenticazione degli endpoint

L'istituto ricevente deve accertare che la trasmissione provenga effettivamente dall'istituto che dichiara di rappresentare.

I controlli pertinenti possono comprendere:

• certificati digitali istituzionali;
• coppie di chiavi SSH pubblica/privata;
• certificati TLS reciproci (mutual TLS);
• credenziali API;
• inserimento degli indirizzi IP in una lista di autorizzazione (allow-list);
• autenticazione VPN;
• moduli di sicurezza hardware (HSM);
• certificate pinning ove appropriato;
• autenticazione amministrativa a più fattori;
• conti di servizio controllati;
• controlli di accesso basati sui ruoli; e
• segregazione degli ambienti di produzione e di test.

Un indirizzo IP da solo non costituisce una prova adeguata dell'identità istituzionale.

Analogamente, il possesso di un endpoint, di credenziali di accesso a un server, di una credenziale API o di una password di un file ZIP non comprova la titolarità dei fondi sottostanti.

6. Crittografia

La riservatezza dovrebbe di norma essere garantita su più livelli.

Cifratura del trasporto

Il canale di comunicazione dovrebbe essere cifrato mediante un protocollo contemporaneo adeguatamente configurato, quale TLS o SSH.

Ciò protegge le informazioni in transito.

Crittografia del payload

Ove richiesto, anche il pacchetto della transazione può essere ulteriormente crittografato.

Ciò garantisce la protezione delle informazioni finanziarie indipendentemente dal canale di trasporto e può ridurre in modo significativo l'esposizione nei casi in cui i file siano temporaneamente archiviati, instradati attraverso infrastrutture intermedie, conservati o elaborati in modo asincrono.

Crittografia dei dati a riposo

I file in attesa di elaborazione devono essere protetti in ambienti di archiviazione controllati, con adeguate restrizioni di accesso e crittografia dei dati a riposo.

La crittografia, tuttavia, assicura la riservatezza. Non attesta la validità finanziaria dell'operazione.

7. Integrità crittografica

L'istituto ricevente deve inoltre essere in grado di stabilire se il pacchetto trasmesso sia stato alterato dopo la sua creazione.

È pertanto possibile generare un hash crittografico per il pacchetto o per i singoli file che lo compongono.

Ad esempio:

Pacchetto originale della transazione
→ generazione dell'hash crittografico
→ trasmissione del pacchetto
→ il sistema ricevente calcola in modo indipendente l'hash
→ confronto tra l'hash calcolato e l'hash trasmesso o firmato

Una discordanza indica che il pacchetto ricevuto non è crittograficamente identico a quello originariamente autenticato.

Per la verifica dell'integrità possono essere impiegati algoritmi di hash crittografico contemporanei, quali quelli delle famiglie SHA-2 o SHA-3, ove appropriato in relazione all'implementazione.

8. Firme digitali

Una firma digitale svolge una funzione sostanzialmente diversa da quella della crittografia.

La crittografia tutela la riservatezza.

L'hashing contribuisce a stabilire l'integrità.

Una firma digitale correttamente implementata può contribuire a stabilire:

1. autenticità - il pacchetto è stato firmato mediante la pertinente chiave privata;
2. integrità - i dati sottoscritti non sono stati successivamente alterati; e
3. responsabilità - la firma può essere associata alla pertinente credenziale istituzionale, nel rispetto della PKI e del quadro di governance applicabili.

L'istituto ricevente dovrebbe verificare la firma rispetto al corrispondente certificato attendibile o alla chiave pubblica prima che l'istruzione relativa all'operazione entri nel processo di elaborazione dei pagamenti.

Le chiavi di firma private devono essere adeguatamente protette, preferibilmente mediante un'infrastruttura istituzionale di gestione delle chiavi e, ove opportuno, mediante Hardware Security Module.

9. Protezione da riproduzione e duplicazione

La trasmissione di file finanziari richiede controlli volti a impedire che la medesima istruzione valida venga presentata più volte.

Un'architettura adeguatamente progettata dovrebbe pertanto prevedere identificativi univoci delle transazioni e controlli appropriati, quali:

• identificativi univoci dei messaggi;
• identificativi univoci delle transazioni;
• marcature temporali (timestamp);
• numeri di sequenza;
• identificativi dei file;
• rilevamento dei messaggi duplicati;
• controlli di idempotenza;
• registri dello stato di elaborazione; e
• riconciliazione rispetto alle istruzioni già elaborate.

L'istituzione ricevente deve respingere, porre in quarantena o esaminare le istruzioni duplicate secondo la procedura operativa concordata.

10. Convalida dei file

La corretta ricezione di un file deve avviare la validazione, non il regolamento automatico.

Un ambiente di elaborazione sicuro può sottoporre il pacchetto a diversi controlli successivi:

Fase 1 – Validazione del trasporto

Conferma che il plico è pervenuto attraverso un canale autorizzato.

Fase 2 – Autenticazione dell'endpoint

Conferma del sistema trasmittente e delle credenziali istituzionali.

Fase 3 – Controlli antimalware e di sicurezza dei file

Ispezione dell'archivio e dei file che lo compongono prima dell'acquisizione nell'infrastruttura di pagamento.

Fase 4 – Verifica crittografica

Convalida di hash, firme e certificati.

Fase 5 – Validazione strutturale

Conferma che i file sono conformi allo schema concordato, alle convenzioni di denominazione, alla codifica dei caratteri e alla specifica dei dati.

Fase 6 – Validazione semantica

Conferma che i campi obbligatori del pagamento siano presenti e internamente coerenti.

Fase 7 – Convalida dell'operazione

Convalida di valuta, importo, conti, informazioni di instradamento, riferimenti dell'operazione e istruzioni di regolamento.

Fase 8 – Convalida della Compliance

AML, sanzioni, KYC/KYB, monitoraggio delle transazioni e altri controlli applicabili.

Fase 9 – Convalida del regolamento

Conferma dell'esistenza di un meccanismo effettivo mediante il quale il corrispondente valore finanziario possa essere regolato.

Solo dopo il completamento di tali controlli un'istruzione dovrebbe procedere all'esecuzione secondo le procedure applicabili dell'istituto ricevente.

11. La conferma di ricezione non equivale a regolamento

Un ambiente IP ZIP può generare diverse conferme tecniche.

Ad esempio:

ACK – File ricevuto

Ciò attesta unicamente che l'endpoint ricevente ha acquisito il pacchetto.

ACK – File autenticato

Ciò attesta che i controlli di autenticazione sono stati completati con esito positivo.

ACK – File validato

Ciò accerta che il pacchetto ha soddisfatto la validazione strutturale o tecnica applicabile.

ACK – Istruzione accettata

Ciò può accertare che l'istruzione di pagamento sia entrata nel flusso di elaborazione dell'istituto ricevente.

Nessuno di questi stati significa necessariamente:

REGOLATO

Il regolamento richiede un distinto evento finanziario.

La distinzione è paragonabile a quella propria della messaggistica finanziaria convenzionale, in cui l'avvenuta consegna e accettazione di un messaggio di pagamento deve essere tenuta distinta dal regolamento definitivo dell'obbligazione monetaria sottostante.

12. Regolamento della transazione sottostante

Una volta che un'istruzione di pagamento IP ZIP sia stata autenticata, convalidata, accettata e autorizzata, il valore monetario sottostante deve essere regolato attraverso un'idonea infrastruttura finanziaria.

A seconda delle valute, degli istituti e delle giurisdizioni coinvolti, il regolamento può avvenire attraverso:

• banche corrispondenti;
• Conti Nostro/Vostro;
• conti presso banche centrali;
• Infrastruttura RTGS;
• sistemi di compensazione riconosciuti;
• sistemi di pagamento nazionali;
• infrastrutture di pagamento istantaneo;
• banche di regolamento corrispondenti; oppure
• un altro meccanismo di regolamento giuridicamente e operativamente riconosciuto.

14. Principio di sicurezza

IFB applica una distinzione fondamentale a tutte le metodologie alternative di trasferimento:

La trasmissione sicura dimostra che i dati possono essere trasmessi in modo sicuro. Non dimostra che il denaro possa essere regolato.

• La crittografia non costituisce prova della disponibilità dei fondi.
• Una firma digitale non costituisce prova dei fondi.
• Il saldo risultante da un server non costituisce prova dei fondi.
• Un file di transazione non costituisce prova dei fondi.
• Il corretto caricamento di un file non costituisce prova dell'esistenza dei fondi.
• Una conferma tecnica di ricezione non costituisce prova di regolamento.

La questione finanziaria decisiva resta se l'istituto originante abbia verificato la disponibilità di liquidità e un percorso di regolamento operativo in grado di trasferire il corrispondente valore monetario attraverso un'infrastruttura bancaria riconosciuta.

15. Quadro di accettazione di IFB

IFB può prendere in considerazione trasmissioni IP ZIP esclusivamente per controparti istituzionali approvate e clienti accettati, a seguito di una verifica tecnica, legale e di compliance soddisfacente.

Prima dell'attivazione della connettività in ambiente di produzione, IFB può richiedere la verifica di:

• l'istituzione di origine;
• poteri istituzionali per trasmettere l'operazione;
• titolarità effettiva e parti dell'operazione;
• origine e legittimità dei fondi;
• finalità economica sottostante;
• infrastruttura di invio e ricezione;
• titolarità degli endpoint;
• architettura IP e di rete;
• metodologia di autenticazione;
• certificati e credenziali crittografiche;
• standard di crittografia;
• formato e schema del file;
• struttura del messaggio di pagamento;
• metodologia di identificazione delle operazioni;
• protocollo di conferma di ricezione;
• controlli sui duplicati e sulla ripetizione dei messaggi (replay);
• gestione delle eccezioni;
• procedure di riconciliazione;
• rapporti di corrispondenza bancaria;
• conti di regolamento;
• accordi di liquidità; e
• il percorso di regolamento finale.

L'interoperabilità tecnica, da sola, non è sufficiente.

IFB non considererà la corretta trasmissione di un pacchetto ZIP IP come ricezione dei fondi. L'operazione si considera finanziariamente conclusa soltanto quando il corrispondente valore sia stato regolato con successo tramite l'infrastruttura bancaria o di regolamento concordata e il regolamento possa essere riconciliato in modo indipendente.

Principio fondamentale

L'IP ZIP è la trasmissione sicura di un'istruzione. Il regolamento è il trasferimento del corrispondente valore finanziario.

I due processi possono far parte dello stesso flusso operativo della transazione, ma non costituiscono il medesimo evento.

Nella terminologia bancaria istituzionale:

Trasmissione del messaggio → autenticazione → convalida → accettazione → esecuzione → regolamento → riconciliazione

Solo il completamento del relativo processo di regolamento attesta che la componente monetaria dell'operazione è stata portata a termine.

La terminologia associata a metodi di trasferimento alternativi o tradizionali va interpretata nel contesto dell'infrastruttura bancaria. Tali termini possono descrivere canali di comunicazione, metodi di elaborazione interna o prassi storiche, ma non sostituiscono l'obbligo di ricorrere a istituti regolamentati, a sistemi di pagamento riconosciuti e a procedure formali di regolamento.

Qualsiasi trasferimento, a prescindere dalla terminologia utilizzata, deve in ultima analisi essere elaborato, compensato e riconciliato all'interno del sistema finanziario consolidato.

Se desidera maggiori informazioni su come trasferire fondi o attività sui Suoi conti presso di noi, La preghiamo di contattare Marie Mayer.