Dati e messaggistica della Travel Rule

Un programma Travel Rule è efficace solo quanto i messaggi che invia e riceve. I team di compliance non devono scrivere il codice, ma devono saper leggere un messaggio, individuare un campo mancante o malformato, valutare se un protocollo autentica la controparte e protegge i dati e decidere quando i dati devono arrivare. Questa lezione fornisce le conoscenze pratiche necessarie.

IVMS101: un modello di dati condiviso

Lo interVASP Messaging Standard (IVMS101) definisce come strutturare i dati dell’ordinante e del beneficiario, affinché due VASP qualsiasi possano leggere i messaggi reciproci. Un gruppo di lavoro congiunto del settore ha pubblicato la prima versione nel maggio 2020. La versione attuale, IVMS 101.2023, è mantenuta dall’interVASP Standards Working Group, che ha rilasciato un aggiornamento nel giugno 2024.

IVMS101 è un modello di dati, non un protocollo. La sua dichiarazione di ambito esclude sicurezza delle informazioni, privacy dei dati, identificazione dei VASP, protocolli di rete e archiviazione, e non specifica come il VASP del beneficiario utilizzi i dati. Anche i dettagli della transazione, come l’asset, l’importo e il txid, non rientrano nel suo ambito; il protocollo di messaggistica li trasporta nella propria busta.

Il modello ha un numero limitato di componenti fondamentali:

I nomi sono suddivisi in un primaryIdentifier (di solito il cognome) e un secondaryIdentifier (i nomi propri), ciascuno contrassegnato da un codice di tipo, come LEGL per il nome legale o ALIA per uno pseudonimo. I nomi in una scrittura nazionale vanno in localNameIdentifier, mentre la forma latina va in nameIdentifier. Gli indirizzi includono un addressType (HOME, BIZZ o GEOG), un townName e un country obbligatori, nonché addressLine oppure campi strutturati per la via. Gli identificativi nazionali includono un nationalIdentifierType, ad esempio CCPT (passaporto), RAID (identificativo dell’autorità di registrazione) o LEIX (LEI).

Regole di convalida da conoscere

IVMS101 associa vincoli al modello e chi esamina la conformità può usarli come lista di controllo:

• Un ordinante persona fisica deve avere almeno uno dei seguenti elementi: un indirizzo geografico, un’identificazione del cliente, un’identificazione nazionale oppure la data e il luogo di nascita. Ciò rispecchia l’elemento “uno tra” del set di dati FATF.
• Ogni persona deve avere almeno un nome di tipo LEGL.
• I valori dei paesi devono essere codici ISO 3166-1 alpha-2 (o XX) e le date devono rispettare lo standard ISO 8601. Una data di nascita deve essere nel passato.
• L’identificativo nazionale di una persona giuridica deve essere di tipo RAID, MISC, LEIX o TXID. Un LEI non riporta il paese di emissione né un’autorità di registrazione.
• I dati sono in UTF-8 e, salvo diversa indicazione, in scrittura latina.

Il superamento della convalida dimostra che un messaggio è ben formato. Non dimostra che i dati siano veri o che appartengano al cliente corretto.

Un messaggio di esempio

{
  "payloadMetadata": { "payloadVersion": "101.2023" },
  "originator": { "originatorPerson": [ {
    "naturalPerson": {
      "name": { "nameIdentifier": [ { "primaryIdentifier": "Moreau", "secondaryIdentifier": "Lea",
                "naturalPersonNameIdentifierType": "LEGL" } ] },
      "geographicAddress": [ { "addressType": "HOME", "streetName": "Harbor Road", "buildingNumber": "18",
                "townName": "Port Alder", "country": "XX" } ],
      "dateAndPlaceOfBirth": { "dateOfBirth": "1990-03-14", "placeOfBirth": "Port Alder" } },
    "accountNumber": [ "bc1q…7k3f" ] } ] },
  "beneficiary": { "beneficiaryPerson": [ {
    "naturalPerson": { "name": { "nameIdentifier": [ { "primaryIdentifier": "Okafor",
                "secondaryIdentifier": "Chidi", "naturalPersonNameIdentifierType": "LEGL" } ] } },
    "accountNumber": [ "bc1q…9m2x" ] } ] },
  "originatingVASP": { "originatingVASP": { "legalPerson": {
    "name": { "nameIdentifier": [ { "legalPersonName": "Alpha Exchange Ltd", "legalPersonNameIdentifierType": "LEGL" } ] },
    "nationalIdentification": { "nationalIdentifier": "5493…0042", "nationalIdentifierType": "LEIX" } } } }
}

Il messaggio fittizio mostra un ordinante persona fisica con un nome legale, un indirizzo di residenza e la data e il luogo di nascita: requisiti che soddisfano ampiamente la regola “uno tra”. Il beneficiario ha solo un nome e un conto, che sono le sole informazioni che ci si aspetta che il VASP dell’ordinante conosca. Il VASP dell’ordinante si identifica tramite il nome legale e il LEI (qui abbreviato). Il codice paese XX è consentito dallo standard; un messaggio reale riporterebbe il codice ISO. Normalmente seguirebbe un blocco beneficiaryVASP.

Le versioni sono importanti. Nella versione del 2020, l’elenco degli ordinanti era plurale (originatorPersons), il numero di conto si trovava direttamente sotto l’ordinante e il beneficiario, e l’elemento del tipo di nome della persona fisica era nameIdentifierType (un esempio svolto nel testo del 2023 usa ancora il vecchio nome, quindi è utile un’analisi sintattica tollerante). Un parser che si aspetta una sola versione può eliminare silenziosamente i dati dell’altra; per questo IVMS 101.2023 rende obbligatorio payloadVersion.

Esaminare un messaggio in entrata

Quando arriva un messaggio, il VASP del beneficiario segue una sequenza prestabilita prima di accettarlo:

1. Versione e validità. Legge payloadVersion, analizza il messaggio con lo schema corrispondente ed esegue i controlli dei vincoli. Un messaggio che non supera i controlli costituisce un’eccezione, non un successo parziale.
2. Corrispondenza del conto. Verifica che accountNumber (o l’indirizzo e il tag nella busta del protocollo) sia un indirizzo di deposito di uno dei suoi clienti.
3. Corrispondenza del nome. Confronta il nome del beneficiario con il nome verificato del titolare del conto. Utilizza una corrispondenza approssimativa che tolleri l’inversione degli identificativi primario e secondario, l’assenza di accenti, le differenze di traslitterazione e i secondi nomi, e registra il punteggio e il motivo dell’accettazione o del rifiuto.
4. Controllo dell’ordinante. Verifica il nome dell’ordinante e, se presente, la data di nascita rispetto agli elenchi di sanzioni e inserisce i dati nel monitoraggio.
5. Verifica della controparte. Conferma che originatingVASP corrisponda al mittente autenticato e a una controparte sottoposta a due diligence aggiornata.
6. Decisione e archiviazione. Accetta o rifiuta, invia la risposta e archivia insieme il messaggio, la risposta e il txid definitivo.

È nei passaggi 3 e 4 che emergono la maggior parte dei problemi concreti: pagamenti alla persona sbagliata, conti utilizzati da qualcuno che non ne è il titolare e corrispondenze con le liste di sanzioni.

Protocolli e reti

IVMS101 ha bisogno di un sistema di trasporto. Le soluzioni rientrano in due grandi categorie:

• Protocolli aperti: le relative specifiche sono pubblicate e chiunque può implementarli. TRP (Travel Rule Protocol), ora gestito nell’ambito della OpenVASP Association, è un protocollo basato su API che utilizza TLS con autenticazione reciproca e un “Travel Address” che codifica l’endpoint del VASP del beneficiario. TRISA (Travel Rule Information Sharing Architecture) combina una directory, certificati rilasciati a VASP verificati, connessioni con autenticazione reciproca e buste sigillate che solo il destinatario può decifrare. OpenVASP è nato come protocollo separato prima che la sua associazione assumesse la gestione di TRP.
• Reti chiuse: sono gestite da un unico operatore che ammette i membri, ospita la directory e spesso instrada i messaggi. Possono essere più facili da utilizzare, ma vincolano l’azienda alla copertura di quell’operatore.

Ogni soluzione deve affrontare gli stessi quattro problemi:

L’interoperabilità è la lacuna pratica più comune. Un’azienda che supporta un solo protocollo può raggiungere solo i membri di quel protocollo; perciò la maggior parte delle aziende ne supporta diversi o utilizza bridge e verifica che i campi siano conservati durante la traduzione.

Flussi pre-transazione e post-transazione

In un flusso pre-transazione, il VASP dell’ordinante invia i dati, attende che il VASP del beneficiario li accetti e solo allora trasmette la transazione e invia il txid. In un flusso post-transazione, la transazione viene trasmessa per prima e i dati seguono.

Lo scambio pre-transazione è il controllo più efficace, perché un trasferimento confermato non può essere annullato. I flussi post-transazione restano comuni quando lo strumento della controparte non può rispondere in tempo reale; in tal caso, l’azienda deve monitorare quanto tardano effettivamente ad arrivare i dati.

Focus sull'esame: IVMS101 è un modello di dati, non un protocollo, e gli elementi che il suo ambito esclude (sicurezza, identificazione dei VASP, trasporto, dati della transazione); le principali entità ed elementi di IVMS 101.2023, i tipi di nome come LEGL, i tipi di indirizzo e i tipi di identificativo come LEIX; le principali regole di convalida (la regola “uno tra” per gli ordinanti persone fisiche, un nome legale obbligatorio, i formati ISO per paesi e date); la lettura di un messaggio di esempio e l’individuazione di un elemento mancante; le differenze tra le versioni 2020 e 2023 e l’importanza di payloadVersion; i protocolli aperti rispetto alle reti chiuse e i quattro problemi di individuazione, autenticazione, cifratura e interoperabilità; i flussi pre-transazione rispetto a quelli post-transazione.