Disposizioni di pagamento XML SEPA compliant
Rif. STIP-ST-001 (002) (003) v 00.04.00
Agenda
Funzione CBI “Disposizioni di pagamento XML”
1
Workflow di servizio
2
Struttura dei messaggi veicolati
3
Tracciato dei messaggi veicolati
2
Funzione CBI “Disposizioni di pagamento XML”
1
Overview
Caratteristiche funzionali principali
 Unico standard XSD con regole applicative di gestione (controlli) diverse sulla base di due tipologie
di distinte:
 Bonifici SEPA
 Emissione Assegni
Disposizioni di
pagamento Italia
 Lo standard si chiama “Disposizioni di Pagamento XML” e a tendere dovrà sostituire l’attuale servizio
di PORTING-PC
 Ai fini della veicolazione e per fornire un riscontro immediato al cliente verranno pubblicati sul
Directory CBI due servizi differenti:
 Disposizioni di pagamento SEPA
 Disposizioni di pagamento Italia
 I messaggi di stato avanzamento inviati all’ordinante a seguito dei controlli sostanziali rivestono
carattere di selettività (solo su richiesta del Mittente/Ordinante) per i Bonifici SEPA, mentre sono
automatici per le richieste di emissione assegni
 I messaggi fisici di richiesta di servizio rispettano il seguente criterio di omogeneità relativo alla
tipologia di distinte ivi contenute, in coerenza con i due servizi pubblicati:
 Tutte le distinte sono relative a bonifici SEPA
 Tutte le distinte sono relative a emissione assegni
3
3
Funzione CBI “Disposizioni di pagamento XML”
1
Workflow di servizio – Definizioni preliminari
Messaggio fisico di richiesta servizio (richiesta servizio)
Rappresenta il messaggio XML veicolato sulla rete CBI
Ogni messaggio di richiesta servizio risulta omogeneo per:

mittente “logico” (Banca Mittente);

destinatario “logico” (Banca Ricevente);

soggetto di riferimento del destinatario “logico” (es. STD, GPA);

indirizzo di Rete Logica del soggetto di riferimento;

tipologia di entità logiche veicolate (cfr. definizioni seguenti)
Ogni richiesta di servizio sarà veicolata in modalità file+messaggio qualora la dimensione della stessa superi 1MB
Messaggio logico di richiesta pagamento (richiesta pagamento)
Rappresenta l’entità logica di base tramite la quale l’ordinante richiede alla Banca Passiva, tramite la propria Banca
Proponente, il pagamento di una distinta. Ogni richiesta di pagamento contiene solo una distinta la quale a sua volta è
composta da più disposizioni di accredito
Messaggio logico di stato avanzamento (stato avanzamento)
Rappresenta l’entità logica di base tramite la quale la Banca Passiva fornisce alla Banca Proponente il risultato dei
controlli applicati sulle richieste di pagamento ricevute (ciascuna richiesta contiene una sola distinta)
4
4
Funzione CBI “Disposizioni di pagamento XML”
1
Definizione dei livelli di controllo – Overview
Al fine di definire in modo preciso i controlli da effettuare alla ricezione di una richiesta
di servizio, sono stati definiti i tre livelli di controllo di seguito riportati:
Step di controlli in carico al ricevente
Livello 2: controlli sostanziali
Livello 1: controlli applicativi
Livello 0: controlli formali (XSD)
Ricezione richiesta di servizio
5
5
Funzione CBI “Disposizioni di pagamento XML”
1
6
Definizione dei livelli di controllo – livello 0
Livello 0: controlli formali
Rientrano in questo livello tutti i controlli volti alla verifica che i dati veicolati
rispettino il formalismo imposto dagli standard definiti o adottati dal CBI.
In considerazione del fatto che tutti i Nuovi Servizi CBI vengono erogati
tramite messaggistica XML, per tali servizi l’insieme dei controlli formali
coincide con l’insieme dei controlli di rispondenza dei messaggi scambiati ai
corrispondenti schema XSD forniti dal CBI (controlli XSD)
Nel caso in cui i controlli di livello 0 diano esito negativo, vengono scartate
tutte le entità logiche presenti nella richiesta di servizio e si segnala l’errore
tramite invio di un messaggio General Purpose con codice di errore DG01
6
Funzione CBI “Disposizioni di pagamento XML”
1
7
Definizione dei livelli di controllo – livello 1
Livello 1: controlli applicativi
Sono i controlli che non possono essere effettuati tramite semplice validazione XSD
dei messaggi ricevuti, ma necessitano di ulteriori verifiche di tipo applicativo che
coinvolgono dati e logiche rientranti direttamente nella sfera di competenza CBI.
A titolo esemplificativo e non esaustivo, rientrano in questo livello le seguenti
tipologie di controlli:
 controlli incrociati di coerenza tra i valori assunti da due o più campi in uno stesso
messaggio o messaggi differenti (riconciliazione);
 controlli di validità dei codici CUC;
 verifica hash firma digitale;
 controlli di validità su singoli campi (es. codice IBAN);
 controlli di omogeneità
 Controlli su coerenza tipo distinta (es. SEPA)
Nel caso in cui i controlli di livello 1 diano esito negativo, lo scarto viene
effettuato selettivamente sulle singole entità logiche errate mediante uso di
un messaggio di stato avanzamento
7
Funzione CBI “Disposizioni di pagamento XML”
1
8
Definizione dei livelli di controllo – livello 2
Livello 2: controlli sostanziali
Rappresentano i controlli di competenza Banca strettamente correlati al tipo di servizio
erogato. In alcuni casi possono essere applicati mediante accesso ad informazioni
esterne alle logiche CBI.
A titolo esemplificativo e non esaustivo, rientrano in questo livello le seguenti tipologie
di controlli:
 verifica di disponibilità fondi per l’erogazione di un pagamento
 controllo di corrispondenza tra ordinante e intestatario del conto di addebito
 verifica del rispetto delle clausole contrattuali firmate dal cliente
 verifica dei poteri di firma
Nel caso in cui i controlli di livello 2 diano esito negativo, lo scarto viene
effettuato selettivamente sulle singole entità logiche o sotto entità errate
mediante uso di un messaggio di stato avanzamento
8
Funzione CBI “Disposizioni di pagamento XML”
1
Schema Logico del servizio
Nell’ambito della richiesta di servizio, il Mittente/Ordinante può richiedere alla
Banca di inviare un esito di addebito anche verso il Beneficiario
Illustrativo
Invio richiesta
Verifica della
rispondenza delle
informazioni allo
standard definito
Inoltro della richiesta
con indicazione
tipologia
Esecuzione della
richiesta secondo
quanto stabilito dallo
standard
Invio esito di addebito
Mittente/
Ordinante
CBI
Ricezione esito di addebito
Banca
Proponente
Invio esito verso Beneficiario
Inoltro esito
verso
Beneficiario
Banca Passiva
Ordinante
Circuito di
regolamento
SEPA
Ricezione esito verso
Beneficiario
Beneficiario
CBI
Banca
Proponente
Tratta interbancaria
Servizio “Disposizione di pagamento XML” con esito di addebito verso l’Ordinante
Servizio di “Esito verso Beneficiario” su richiesta del cliente Ordinante
Banca Passiva
Beneficiario
10
Funzione CBI “Disposizioni di pagamento XML”
1 Analisi del workflow di servizio – Sequence diagram e livelli di controllo
Workflow di Servizio: Sequence diagram e livelli di controllo
Banca Passiva
dell’Ordinante/STD
Banca Proponente
dell’Ordinante/STD
1: Invio richiesta di servizio
2: Parsing del messaggio
(validazione XML/XSD)
3: Controlli applicativi sui dati
ricevuti
4: Invio stato avanzamento relativo a controlli formali e applicativi

6: Invio stato avanzamento di “work in progress”
7: Invio stato avanzamento KO relativo a controlli sostanziali su intera distinta
9: Invio stato avanzamento relativo a controlli sostanziali sulle singole
disposizioni di accredito (contiene il CRO o numero assegno)
Messaggio obbligatorio
Messaggio facoltativo

Controlli in
ricezione
Livello 0
Livello 1
5: Verifica sostanziale dei dati
relativi (es. verifica conto
dell’ordinante - cioè che il
conto indicato corrisponda
effettivamente a quello
intestato all’ordinante)
Livello 2
8: Verifica della disponibilità
per l’esecuzione
dell’addebito
Livello 2
Obbligatorio in caso di
emissione assegni
10
11
Funzione CBI “Disposizioni di pagamento XML”
1
Analisi del workflow di servizio – Sequence diagram del workflow di veicolazione
Workflow di veicolazione: messaggi di controllo
Banca Passiva
dell’Ordinante/STD
Banca Proponente
dell’Ordinante/STD
1: Invio richiesta di servizio
2: Parsing del messaggio
(validazione XML/XSD)
4: Invio stato avanzamento relativo a controlli formali e applicativi

6: Invio stato avanzamento di “work in progress”
6.1: Parsing del messaggio
(validazione XML/XSD)
6.2: Controlli applicativi sui dati
ricevuti
7.1: Parsing del messaggio
(validazione XML/XSD)
7.2: Controlli applicativi sui dati
ricevuti
10.1: Parsing del messaggio
(validazione XML/XSD)
10.2: Controlli applicativi sui dati
10.4: Inoltro a Banca Proponente
Beneficiario
5: Verifica sostanziale dei dati
relativi (es. verifica conto
dell’ordinante - cioè che il
conto indicato corrisponda
effettivamente a quello
intestato all’ordinante)
6.3: Invio messaggio di controllo veicolazione
7: Invio stato avanzamento KO relativo a controlli sostanziali su intera distinta
7.3: Invio messaggio di controllo veicolazione
9: Invio stato avanzamento relativo a controlli sostanziali sulle singole
disposizioni di accredito (contiene il CRO o numero assegno)
9.1: Parsing del messaggio
(validazione XML/XSD)
9.2: Controlli applicativi sui dati
ricevuti
3: Controlli applicativi sui dati
ricevuti

8: Verifica della disponibilità
per l’esecuzione
dell’addebito
9.3: Invio messaggio di controllo veicolazione
10: Invio stato avanzamento relativo a controlli sostanziali sulle
singole disposizioni di accredito al Beneficiario
10.3: Invio messaggio di controllo veicolazione
11
Funzione CBI “Disposizioni di pagamento XML”
1
Analisi del workflow di servizio – Modalità di gestione
Workflow di servizio: modalità di gestione (1/2)
Con riferimento al sequence diagram riportato nella slide precedente valgono i seguenti principi:
 Ogni messaggio fisico di richiesta servizio (1) contiene uno o più richieste di pagamento (distinte)
 I messaggi fisici di stato avanzamento di livello 1 (4) di sono posti in corrispondenza 1:1 con le
richieste di servizio; ogni messaggio fisico (4) deve referenziare tutti i messaggi logici contenuti nella
richiesta di servizio corrispondente
 I messaggi logici di stato avanzamento, generati a seguito dei controlli sostanziali, possono essere di
tre tipologie:
 messaggi di “work in progress” (6)
 messaggi di stato avanzamento KO sull’intera distinta (7)
 messaggi di stato avanzamento con il dettaglio relativo alle singole disposizioni (9)
 I messaggi di “work in progress” (6) sono sempre facoltativi
 I messaggi logici di stato avanzamento (7), (9) verso l’ordinante rivestono carattere di facoltatività per
i Bonifici SEPA, mentre sono obbligatori per le richieste di emissione assegni
 I messaggi di Esito verso il beneficiario (10), inviati verso l’ordinante ed in seguito al beneficiario,
rivestono sempre carattere di facoltatività
12
Funzione CBI “Disposizioni di pagamento XML”
1
Analisi del workflow di servizio – Modalità di gestione
Workflow di servizio: modalità di gestione (2/2)
Con riferimento al sequence diagram riportato nella slide precedente valgono i seguenti principi:
 Il messaggio (4) viene indirizzato al “return address” indicato nell’header di tratta della richiesta di
servizio (1)
 I messaggi (6) (7) e (9) vengono indirizzati attraverso accesso al Directory
 A fronte di una richiesta di servizio possono essere generati più messaggi fisici di stato
avanzamento (6), (7), (9), pertanto la corrispondenza risulta 1:N
13
Funzione CBI “Disposizioni di pagamento XML”
1
Analisi del workflow di servizio – State diagram singola distinta
Workflow di Servizio – State diagram distinta (dal punto di vista del Cliente)
Distinta KO
Controlli applicativi KO
Distinta accettata
Distinta inviata
Stato avanzamento 4 OK
Distinta con controlli
sostanziali KO
Stato avanzamento 7
Distinta con controlli
applicativi OK
Tutte disposizioni OK
Verifiche in corso
(stato avanzamento
6 - work in progress)
Stato avanzamento 9 per
alcune disposizioni
Distinta con
disposizioni ancora
da esitare
Distinta
parzialmente
accettata
Alcune disposizioni KO
Stato avanzamento 9 per
tutte le disposizioni
Stato avanzamento 9 per
tutte le disposizioni
Stato avanzamento 9 per
alcune disposizioni
Distinta rifiutata
Distinta con tutte
le disposizioni
esitate
Tutte disposizioni KO
14
Funzione CBI “Disposizioni di pagamento XML”
1
Analisi del workflow di servizio – Regole di governance
Regole di governance
 In caso di fallimento dei controlli formali applicati dalla Banca Passiva/Banca Proponente sulla
richiesta di servizio ricevuta, viene effettuato lo scarto di tutte le distinte ivi contenute mediante invio
di un messaggio di errore “General Purpose”
 Il fallimento dei controlli applicativi (livello 1) porta allo scarto selettivo delle singole distinte
15
Funzione CBI “Disposizioni di pagamento XML”
1
Analisi del workflow di servizio – Indirizzamento richieste di servizio
DIRECTORY CBI
Indirizzamento richiesta di servizio
Banca Proponente ► Banca Passiva
per disposizioni di pagamento Italia
Indirizzamento richiesta di servizio
Banca Proponente ► Banca Passiva
per Bonifici SEPA
Indirizzamento richiesta di servizio
Banca Passiva ► Banca Proponente
per stati avanzamento 6-7-9
o=cbi
o=cbi
o=cbi
o=CUC Banca Passiva
o=CUC Banca Passiva
o=CUC Banca
Proponente
ou=Servizi CBI
ou=Servizi CBI
ou=Servizi CBI
ou=servizi non profilati
ou=servizi non profilati
ou=servizi profilati
cn=DISP-PAG-ITA
cn=DISP-PAG-SEPA
cn=STAT-RPT-DISP-PAG
16
Funzione CBI “Disposizioni di pagamento XML”
1
Analisi del workflow di servizio – Indirizzamento risposte verso Banca Gateway
DIRECTORY CBI
DIRECTORY CBI
Indirizzamento risposte applicative da
Banca Passiva ► Banca Gateway per
stati avanzamento 6-7-9
Indirizzamento esito verso il beneficiario
Banca Passiva Ordinante ► Banca Gateway per
messaggio 10
o=cbi
o=cbi
o=CUC Banca
Gateway
o=CUC Banca
Gateway
ou=Servizi CBI
ou=Servizi CBI
ou=PROFILO
MARKETPLACE
<codice>
ou=PROFILO
MARKETPLACE
<codice>
cn=STAT-RPT-DISP-PAG
cn=ESITO-BON-ORD-BEN
17
Funzione CBI “Disposizioni di pagamento XML”
1
Analisi del workflow di servizio – Indirizzamento Esito verso Ordinante e Beneficiario
DIRECTORY CBI
Indirizzamento esito verso il beneficiario
Banca Passiva Ordinante ► Banca Proponente
ordinante per messaggio 10
Indirizzamento esito verso il beneficiario
Banca Proponente Ordinante (Gateway) ► Banca
Proponente beneficiario per messaggio 10
o=cbi
o=cbi
o=CUC Banca Proponente
Ordinante
o=CUC Banca Proponente
Beneficiario
ou=Servizi CBI
ou=Servizi CBI
ou=servizi profilati
ou=servizi profilati
cn=ESITO-BON-ORD-BEN
cn=ESITO-BON-ORD-BEN
Agenda
Funzione CBI “Disposizioni di pagamento XML”
1
Workflow di servizio
2
Struttura dei messaggi veicolati
3
Tracciato dei messaggi veicolati
19
Funzione CBI “Disposizioni di pagamento XML”
2
Struttura dei messaggi veicolati – Richiesta di servizio
Messaggio fisico di richiesta servizio (richiesta servizio)
 Rappresenta il messaggio XML veicolato sulla rete CBI contenente uno o più messaggi logici
 Ogni messaggio di richiesta servizio risulta omogeneo per:
- mittente “logico” (Banca Mittente)
- destinatario “logico” (Banca Ricevente);
- soggetto di riferimento del destinatario “logico” (es. STD, GPA);
- indirizzo di Rete Logica del soggetto di riferimento;
- tipologia di distinte ivi contenute *
 Ogni richiesta di servizio sarà veicolata in modalità file+messaggio qualora la dimensione della stessa superi 1MB
Blocco sul quale apporre la
firma
<CBI_BON_MSG>
* Si possono presentare i seguenti
casi:
 tutte le distinte sono relative a
bonifici SEPA
 tutte le distinte sono relative a
emissione assegni (disposizioni
Italia)
<HTRT>
[1..1]
<HE2E>
[1..1]
<MSG_BODY>
[1..1]
<ENVEL>
[1..N]
<DATA>
[0..1]
<SIG_INFO>
[0..1]
OR esclusivo
Cfr. slide successiva per la composizione del singolo messaggio logico 20
Funzione CBI “Disposizioni di pagamento XML”
2
Struttura dei messaggi veicolati – Messaggio logico richiesta di servizio
Messaggio logico di richiesta di pagamento (distinta)
 Rappresenta l’entità logica tramite la quale il Mittente/Ordinante (Initiating Party) ordina alla propria Banca Passiva
(Debtor Agent) il pagamento di una distinta
 Ogni messaggio logico (distinta) risulta omogeneo per:
- Mittente/Ordinante *
- Tipologia distinta (SEPA/Disposizione di pagamento Italia) *
- Metodo di pagamento (trasferimento fondi, trasferimento fondi con esito, assegni) *
- Coordinate bancarie di addebito *
- Data richiesta esecuzione *
- Provenienza da Marketplace (medesimo codice Marketplace)
ISO compliant
Blocco <DATA> sul quale
apporre la firma
<ENVEL>
<LOGICAL_MSG>
[1..1]
<GRPHDR>
[1..1]
<PMTINF >
[1..1]
* garantito dalla struttura
del messaggio logico
<CDTTRFTXINF>
<SIG_INFO>
[1..N]
[0..1]
21
Funzione CBI “Disposizioni di pagamento XML”
2
Struttura dei messaggi veicolati – Stato avanzamento/esito
Messaggio fisico di stato avanzamento/esito
 Messaggio XML tramite il quale la Banca Passiva dell’Ordinante comunica
al Mittente/Ordinante lo stato di
processamento delle disposizioni ricevute
 Rappresenta l’esito di uno dei livelli di controllo (0, 1, 2) definiti (es. esito Banca sui messaggi logici precedentemente
inviati)
 Ogni messaggio fisico risulta omogeneo per:
- mittente “logico” (Banca Mittente)
- destinatario “logico” (Banca Ricevente);
- soggetto di riferimento del destinatario “logico” (es. STD, GPA);
- indirizzo di Rete Logica del soggetto di riferimento
Blocco sul quale apporre la
firma
<DBTR_PMT_STS_RPT_MSG>
<HTRT>
[1..1]
<HE2E>
[1..1]
<MSG_BODY>
[1..1]
<ENVEL>
<ENVEL>
[1..N]
<DATA>
[0..1]
<SIG_INFO>
[0..1]
OR esclusivo
Cfr. slide successiva per la composizione del singolo messaggio logico
22
Funzione CBI “Disposizioni di pagamento XML”
2
Struttura dei messaggi veicolati – Messaggio logico stato avanzamento/esito
Messaggio logico di stato avanzamento/esito
 Rappresenta lo stato del processamento della singola entità logica (gruppo di distinte) inviato dalla Banca Passiva
dell’Ordinante
 Come per il messaggio logico contenuto nella richiesta di servizio, ogni messaggio logico (distinta) risulta omogeneo per:
- Mittente/Ordinante
- Tipologia distinta (SEPA/disposizione di pagamento Italia)
- Coordinate bancarie di addebito
- Provenienza da Marketplace (medesimo codice Marketplace)
ISO compliant
In caso di errore su
univocità (MsgID +
Creation Date Time +
CUC Mittente), la Banca
Passiva scarta solo le
distinte duplicate
Blocco <DATA> sul quale apporre la firma
<ENVEL>
<LOG_MSG_STS>
<SIG_INFO>
[1..N]
<GROUP_HEADER>
[1..1]
<ORGNL_GRP_STS>
[1..1]
<ORGNL_PMT_STS>
[0..1]
[0..1]
Agenda
Funzione CBI “Disposizioni di pagamento XML”
1
Workflow di servizio
2
Struttura dei messaggi veicolati
3
Tracciato dei messaggi veicolati
24
Funzione CBI “Disposizioni di pagamento XML”
3
Principali campi di informazione – Messaggio logico di richiesta servizio
<DISP_PAG>
[1..1]
[1..1]
<GROUP_HEADER>
•
•
•
•
Assegnato dal Mittente/Ordinante
(id. distinta)
Message Identification
Creation Date Time
Number Of Transactions
Control Sum
[1..1]
<PAYMENT_INFO>
•
•
•
•
•
BIC facoltativo
ABI obbligatorio
IBAN obbligatorio
per Disp. SEPA
Payment Method
Service Level
Debtor
Debtor Account
Debtor Agent
<PAYMENT_TRX>
•
•
•
•
•
•
•
•
Possibili valori:
“TRF”, “TRA”, “CHK”
Valorizzare il campo con
“SEPA” per bonifici SEPA
IBAN obbligatorio
[1..N]
Instruction Identification
EndToEnd Identification
Amount
Cheque Type
Creditor Agent
Creditor
Creditor Account
Remittance Information
Assegnato dal
Mittente/Ordinante
Contiene l’URI
Obbligatorio (BIC) per
bonifico SEPA cross-border
(IBAN≠IT )
“Strutturate” o “Non
strutturate”
Cfr. documento Excel il dettaglio
dei campi e dei controlli previsti
dallo standard
Funzione CBI “Disposizioni di pagamento XML”
3
Principali campi di informazione – Messaggio logico di stato avanzamento/esito
<ADV_STS>
[1..1]
<GROUP_HEADER>
• Message Identification
• Creation Date Time
• IDE2E
Identificativo CBI del messaggio di
richiesta originario
<ORGNL_GRP_STS> [1..1]
Identificativo distinta riportato nel
messaggio originario
• Original Message Identification
• Group Status
Status della distinta (“ACTC”, “ACSC”,
• Status reason Information
“RJCT”; “PNDG”; “PART”)
<ORGNL_PMT_STS>
[0..1]
<TRX_INF_STS>
•
•
•
•
•
•
•
[1..N]
Status Identification
Original Instruction Identification
Original EndToEnd Identification
Account Servicer Reference
Transaction Status
Status Reason Information
Original Transaction Reference
- Remittance information
- ……..
CRO/TRN (contiene il numero di assegno
in caso di emissione assegni)
Status della singola disposizione
di accredito (“ACSC”, “RJCT”)
Cfr. documento Excel il dettaglio
dei campi e dei controlli previsti
dallo standard
Funzione CBI “Disposizioni di pagamento XML”
3
Regole e contenuti Remittance Information – casi d’uso
Considerato che il messaggio interbancario per bonifici SEPA consente di veicolare un solo blocco (“strutturato” o “non
strutturato”) di informazioni di riconciliazione al massimo di 140 caratteri, sono state definite le seguenti regole per la gestione delle
“remittance information” e del campo “URI”:
Casistiche nella gestione delle “Remittance Information”
a)
se nel tracciato è presente un solo blocco (strutturato entro 140 chrt o non strutturato), tale blocco è utilizzato dalla
passiva per essere veicolato nell'interbancario unitamente all'URI (obbligatorio secondo lo standard ISO);
b)
se nel tracciato sono presenti esclusivamente 1 o più blocchi di remittance information strutturate, tutti > 140 chrt, la
banca passiva utilizza le informazioni di remittance solo nella tratta CBI, veicolando esclusivamente l'URI
nell'interbancario - in tale caso è evidente che il cliente riconcilierà con l'esito all'ordinante unitamente all'URI
ricevuto dall'interbancario;
c)
se nel tracciato sono presenti esclusivamente 1 o più blocchi di remittance information strutturate, di cui almeno uno
entro i 140 chrt, la banca passiva veicola nell'interbancario il primo blocco contenuto entro i 140 chrt unitamente all'
URI;
d)
se nel tracciato è presente un blocco non strutturato e da 0 ad n blocchi strutturati (indipendentemente dalla
dimensione di questi ultimi), la banca passiva veicola nell'interbancario il blocco non strutturato unitamente all' URI;
e)
se nel tracciato sono presenti 1 o più blocchi non strutturati e da 0 a n blocchi strutturati (indipendentemente dalla
dimensione di questi ultimi), la banca passiva veicola nell'interbancario il primo blocco non strutturato unitamente all'
URI;
f)
se nel tracciato non è presente alcun blocco di informazioni di remittance non vengono trasportate remittance
information nell’interbancario ma esclusivamente l’URI.
Sintesi:
Come naturale conseguenza delle casistiche precedenti, se presente almeno un blocco non strutturato viene trasportato
nell’interbancario sempre il primo di questi. Se al contrario non sono presenti remittance information non strutturate viene
veicolato nell’interbancario esclusivamente il primo blocco di remittance information strutturato contenuto entro i 140 chrt.
Funzione CBI “Disposizioni di pagamento XML”
3
Regole e contenuti Remittance Information – contenuti strutturate
Informazioni sul documento
di riferimento:
• tipo documento
• identificativo univoco del
documento
Tutte le informazioni
contenute sono
replicate per ogni
singolo documento
(fattura) a cui si
riferisce il pagamento
originario
Importo di riferimento:
• importo totale
• Sconto
• importo pagato
• importo nota di credito
• importo imposta (IVA)
Creditor reference
Informazioni identificative del
documento fornite dal creditore:
• Identificativo (es. n.ro fattura)
• Identificativo della disposizione
di accredito