Sei sulla pagina 1di 59

Il contenuto del presente documento costituisce materiale riservato.

Ogni violazione sar punita ai


sensi di legge.



















Nuova Architettura CBI
Porting degli attuali Servizi CBI nella Nuova Architettura






Riferimenti
Ogget t o: Por t i ng degl i at t ual i Ser vi zi CBI nel l a Nuova
Ar chi t et t ur a
Model l o Document o: CBI . doc
Nome Fi l e: PORTI NG- MO- 001 Por t i ng at t ual i Ser vi zi - v. 00. 07. 09. doc
Ver si one: 00. 07. 09 Pagi ne 59
Ul t i mo aggi or nament o: 22/ 07/ 2010 11. 35. 36
Dat a cr eazi one: 22/ 12/ 2004
Aut or e: Segr et er i a Tecni ca CBI
Revi sor e: GdL Ar chi t et t ur a GdL st andar d



Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
2/ 59


Revisioni


Data Ver. Presentato
a
In vigore dal Aggiornamenti
01-06-2005 00.01 Primo rilascio
30-01-2006 00.02 Par. 2.3.2 - Inserimento di chiarimenti specifici e di
esempi sui criteri di omogeneit nella creazione del
file
Par. 2.3.3 - Chiarimento sulle modalit di
composizione Header di Servizio
Par. 2.4 - Precisazioni sulla modalit di
compilazione dei blocchi Info File e Info
Supporto contenuti nel messaggio di stato
avanzamento
Par. 2.4 - Inserimento di chiarimenti specifici su
criteri e regole di composizione msg di
avanzamento e aggiornamento codici derrore
previsti nei messaggi davanzamento
Par. 2.5 - Inserimento chiarimenti specifici
sullinvio del supporto logico CN
Par. 2.6 - Chiarimento sulle modalit di invocazione
del servizio PORTING-A4
Cap. 4 - Aggiornamento Regole di Governance, con
linserimento di casi particolari di errore
Cap. 5 - Aggiornamento dei servizi esposti nel
Directory con linserimento del servizio PORTING-
I4
Cap. 5 - Inserimento modalit di indirizzamento dei
flussi nel caso di Marketplace
Par. 8.3.2 - Aggiornamento stati di avanzamento
dei supporti logici
Par. 8.3.2.3.1 Aggiornamento campi del Body del
msg XML di richiesta di servizio accompagnatorio
del file
Par. 8.3.2.3.2 - Aggiornamento campi del Body del
msg XML di stato avanzamento
Par. 8.4 Inserimento esempi di XML in Allegato D
con inserimento dei namespace in cui i vari blocchi
di informazione sono definiti
02-05-2006 00.03 Par. 8.3.2.3.2 - Inserimento rimando al documento
CBI-STD-001
Par. 2.6 Inserimento appositi chiarimenti
Cap. 8 Allegato D Aggiornamento esempi di
XML inserendo esempi specifici di 1 e 2
messaggio di avanzamento
Par. 2.4 Inserimento chiarimenti specifici sulle
modalit di correlazione tra messaggio di richiesta
e messaggi di avanzamento
Par. 2.4.1 Inserimenti chiarimenti sulle modalit
di costruzione del messaggio 17 in caso di errore
sul controllo di corrispondenza tra messaggio XML
e file
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
3/ 59


Cap. 5 Differenziazione tra supporti logici di tipo
SL inviati da Banca e supporti logici di tipo SL
inviati dal Cliente
Par. 2.3.2 Indicazione della riduzione del limite
temporale sul controllo di univocit dei supporti
logici da 13 mesi a 6 mesi
Par. 2.4.1 Inserimento ulteriore codice derrore
sul messaggio 17 (PSL4): firma digitale come
criterio di omogeneit
Par. 2.4.1 Inserimento nota relativamente ad
errori di parsing
Par. 2.2 Eliminazione dellattivit di Invio CN da
sequence e activity diagram per il servizio Porting
Par. 2.4.1 - Inserimento ulteriore controllo in
ricezione relativo al Codice ABI e al CUC della
Banca Passiva e ulteriore codice derrore sul
messaggio 17 (PSL6)
Cap. 5 Inserimento chiarimento su controlli da
effettuare su campi del Directory per
indirizzamento flussi Porting
07-06-2006 00.04 Par 2.4.1 Inserimento codice derrore PSL4
(Supporto logico non omogeneo per destinatario)
Allegato D Modifica dellesempio XML relativo al
1 messaggio di avanzamento (eliminando i blocchi
Info supporto per ricezione OK)
Par. 2.4.1 e Par. 4.4.4 Inserimento chiarimento
specifico sulle modalit di segnalazione dellerrore
in caso di incoerenza di informazioni nel solo
messaggio XML
Par. 8.3.2.3.1 Aggiornamento tipo dato del
campo Firma, contenente la Busta PKCS#7
Cap. 6 Inserimento durata Giornata Applicativa
Par. 8.3.2.3.2 Aggiornamento tipo dato associato
al campo Numero disposizione
Par. 3.3 - chiarimenti su cosa si intende per
controlli applicativi
Par. 4 eliminazione refuso nota 4 a pi di pagina
Par. 2.6 eliminata la caratteristica di
temporaneit della soluzione prevista per la
modalit di veicolazione dei flussi I4
09-06-2006 00.05 Par. 2.5 Modifica modalit di invio supporti logici
A4
17-07-2006 00.06 In vigore a partire dal
21-07-2006 per
leffettuazione dei test
Par. 2.6 Modifica modalit di trattamento dei
flussi I4
Cap. 5 - Inserimento chiarimento sulle modalit di
indirizzamento degli stati di avanzamento e degli
esiti per richieste provenienti da Marketplace
Par. 2.4.1 Inserimento chiarimento sui controlli
da effettuare dalla Banca Destinataria per
predisporre il 1 messaggio di avanzamento
20-12-2006 00.07 In vigore a partire
dallattivazione della
totalit dei servizi
Porting
Par. 8.3.2.3.1 Modifica descrizione campo
Riferimento temporale allinterno del blocco
Firma
Par. 2.6 Inserimento apposito paragrafo per la
gestione dei supporti logici Q4 e A4
Par. 4.5 Inserimento paragrafo per la gestione
del recupero flussi in caso di errore
Par. 4.5.2 Inserimento chiarimento specifico su
modalit di rinvio dei flussi da parte del Mittente
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
4/ 59


Par. 2.5 Inserimento chiarimento specifico su
invio supporti logici A4 e Q4
Cap. 5 - Inserimento precisazione su dove reperire
il codice marketplace necessario per
lindirizzamento degli esiti delle disposizioni di
pagamento
Par. 8.3.2.3.1 Eliminazione refuso XML
Signature come possibile valore del campo Tipo
firma
Par. 2.4 Variazione nei controlli da effettuare in
merito allomogeneit dei flussi per destinatario
logico
Par. 2.3.2 Variazione della nota 1 in merito ai
criteri di omogeneit
18-04-2007 00.07.04 In vigore a partire
dalla data di
attivazione del primo
set di Nuovi Servizi
CBI
Par 8.3.2.3.1 Modificata la struttura del blocco
firma che viene reso facoltativo
Par. 7 Descrizione delle modalit di scarto in
caso di errori correlati alla verifica della firma
digitale
Par. 2.4.1 e Par 2.4.2 Aggiunti i riferimenti al
paragrafo 7 per la trattazione dei temi relativi alla
gestione della firma digitale
05-07-2007 00.07.05 In vigore a partire
dalla data di
attivazione del primo
set di Nuovi Servizi
CBI
Nessuna modifica al presente documento. Sono
stati rimossi dalla documentazione specifica dei
Servizi Porting i file di schema relativi alla
definizione degli header di tratta e di servizio e del
blocco firma. Per tali file si deve fare riferimento a
quelli contenuti nella documentazione PARTE
GENERALE
31-10-2007 00.07.06 In vigore a partire dal
25 Febbraio 2008
Par. 8.3.2.3.1 Inserita precisazione circa lutilizzo
del campo <CreDt>, il quale non deve contenere il
dettaglio relativo al Time Zone
Par. 8.3.2.3.2 Inserita precisazione circa lutilizzo
del campo <CreDt>, il quale non deve contenere il
dettaglio relativo al Time Zone
18-02-2008 00.07.07 Novembre 2008 Par. 8.5: inserito elenco dei qualificatori tipo
messaggio da utilizzare per la strutturazione degli
identificativi di file e messaggi, in accordo a quanto
specificato nel documento Parte Generale
10-10-2008 00.07.08 In vigore a partire
dalla data di
attivazione della firma
digitale sui flussi
dispositivi di Porting
Par. 2.4.1: meglio dettagliato la verifica di
coerenza tra i supporti logici referenziati nel
messaggio XML e quelli contenuti nel file
Par. 4.4.6: aggiunta precisazione in merito alle
modalit di composizione dei messaggi 20 (ordine
nel quale sono referenziati i supporti originari)
Par. 4.5.1: modifica della procedura di recupero
dei flussi a seguito di un errore effettuato dal
ricevente
Par 2.4.2: inserimento chiarimento circa le
modalit di scarto in caso di codice SIA non censito
Par. 2.1: inserimento chiarimento circa la
differenza tra supporti logici informativi e
dispositivi
Par. 2.4.1: aggiunta tipologia di scarto dei flussi
firmati provenienti da mittenti fisici non autorizzati
Par. 7: inserito apposito paragrafo che descrive le
modalit di scarto di flussi firmati provenienti da
mittenti fisici non autorizzati
Par. 8.3.2.3.2: modificata descrizione relativa al
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
5/ 59


codice di errore PF5
Par. 5: inserito chiarimento circa modalit di
indirizzamento degli esiti di pagamento verso
MarketPlace
09-07-2010 00.07.09 30 agosto 2010 Par. 2.2.1.1: eliminato riferimento ai flussi CN
non previsti dalla attuale architettura di Rete
Par 2.3.2: aggiunta precisazione circa i criteri di
aggregazione dei supporti logici nel file e circa la
dimensione massima dei file. Aggiunta precisazione
in merito alla data e il periodo di riferimento per
effettuare il controllo di univocit dei supporti logici
Par. 2.4.1 aggiunta verifica omogeneit dei
supporti logici relativamente allutilizzo della
firma digitale e alla tipologia di firma utilizzata
allinterno di uno stesso flusso
Par. 7: aggiornati i riferimenti tecnici per la
gestione della firma digitale a norma (cfr.
deliberazione CNIPA n45 del 21 maggio 2009 in
vigore dal 30 agosto 2010)
Par. 7.3: inserite precisazioni circa i controlli relativi
alla firma digitale. Ordine dei controlli e
leggibilit della busta
Allegato C: modificata descrizione dei campi relativi
al blocco di informazioni sulla firma
24-05-2010 00.07.09 1 Novembre 2010 Par. 6 Definizione e determinazione dei tempi di
attraversamento sistema CBI
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
6/ 59


Riservatezza e divulgazione
Il Consorzio Customer to Business Interaction di seguito definito Consorzio CBI in qualit di titolare dei
marchi CBI fornisce queste informazioni prevedendo che siano mantenuti i livelli di correttezza e, se indicati,
di riservatezza sui relativi contenuti.
Il documento potr pertanto essere fotocopiato o riprodotto in tutto o in parte ed i contenuti potranno
essere divulgati a terzi, anche consulenti, purch siano rispettate le disposizioni di cui alla Intellectual
Property Rights disponibile sul sito web consortile.

Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
7/ 59


Indice dei Contenuti

1 Obiettivi del documento................................................................................9
1.1 Struttura del documento....................................................................................9
2 Il Servizio PORTING ATTUALI TRACCIATI...............................................10
2.1 Introduzione................................................................................................... 10
2.2 Porting degli attuali tracciati: caso duso ........................................................... 10
2.2.1 Ipotesi di base ed attori identificati ............................................................ 10
2.3 Invocazione di Servizio.................................................................................... 15
2.3.1 Regole per la creazione del supporto logico ................................................ 17
2.3.2 Regole per la creazione del file.................................................................. 17
2.3.3 Regole per la creazione del messaggio....................................................... 19
2.4 Stati di avanzamento....................................................................................... 20
2.4.1 Controlli e regole di composizione del 1 messaggio di avanzamento............ 21
2.4.2 Controlli e regole di composizione del 2 messaggio di avanzamento............ 23
2.5 Considerazioni su invio supporti logici F4, R4................................................ 24
2.6 Considerazioni su invio supporti logici Q4, A4............................................... 25
2.7 Considerazioni su invio supporti logici I4......................................................... 26
3 Diagnostica .................................................................................................27
3.1 Diagnostica sul messaggio............................................................................... 27
3.2 Diagnostica sul file.......................................................................................... 27
3.3 Diagnostica sul supporto logico........................................................................ 27
4 Regole di governance..................................................................................28
4.1 Mancato rispetto delle tempistiche di invio dei messaggi di avanzamento............. 28
4.2 Mancato rispetto della sequenza di invio dei messaggi di avanzamento................ 29
4.3 Casi specifici di errore...................................................................................... 29
4.3.1 File non trovato........................................................................................ 29
4.3.2 Non omogeneit dei supporti logici ............................................................ 29
4.3.3 Supporti logici non referenziati .................................................................. 29
4.3.4 Errori di diagnostica applicativa su alcuni supporti logici............................... 30
4.4 Casi generali di errore..................................................................................... 30
4.4.1 Non univocit della correlazione file-messaggio........................................... 30
4.4.2 Messaggio ricevuto illeggibile..................................................................... 30
4.4.3 Supporti logici duplicati ............................................................................. 30
4.4.4 Incoerenza Nome servizio e Tipologia flusso nel messaggio XML............. 31
4.4.5 Mancata corrispondenza nel 1 messaggio di avanzamento.......................... 31
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
8/ 59


4.4.6 Mancata corrispondenza nel 2 messaggio di avanzamento.......................... 31
4.5 Recupero dei flussi in caso di errore ................................................................. 31
4.5.1 Errore imputabile al soggetto ricevente...................................................... 31
4.5.2 Errore imputabile al soggetto mittente........................................................ 32
4.5.3 Gestione delle contestazioni ...................................................................... 32
5 Individuazione indirizzo di erogazione del Servizio Porting.......................33
6 Livelli di servizio..........................................................................................34
7 Firma digitale..............................................................................................39
7.1 Controllo del mittente fisico dei flussi firmati...................................................... 39
7.2 Controllo di omogeneit per apposizione della firma digitale............................... 39
7.3 Verifica della firma sui singoli supporti logici...................................................... 41
8 Allegati ........................................................................................................43
8.1 Allegato A Criteri di identificazione univoca di messaggio e file......................... 43
8.2 Allegato B - Popolamento del Directory a fini di porting ................................... 43
8.3 Allegato C Struttura dei Messaggi XML dinvio file/stato davanzamento ............ 43
8.3.1 Considerazioni generali ............................................................................. 43
8.3.2 Struttura.................................................................................................. 43
8.4 Allegato D Esempi di XML ............................................................................. 55
8.5 Allegato E strutturazione degli identificativi univoci e qualificatori di tipo
messaggio ............................................................................................................ 59
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
9/ 59



1 Obiettivi del documento

Il presente documento ha l'obiettivo di definire i criteri e le modalit con i quali deve essere realizzato il
porting degli attuali Servizi CBI sulla Nuova Architettura, nonch evidenziare le attivit che,
propedeuticamente, devono essere svolte per rendere possibile tale porting.

Il documento richiama definizioni, concetti e criteri gi espressi nella documentazione attinente sia
allattuale, sia alla Nuova Architettura CBI. In particolare presa come riferimento la seguente
documentazione:

gli standard tecnici dellattuale architettura, identificati dal Codice Classificazione CBI-XXX-NNN, ove:
- CBI: il codice di progetto assegnato dalla Segreteria Tecnica dellAssociazione per il CBI per la
documentazione relativa allattuale architettura:
- XXX: la tipologia di documento (ad esempio BON, AEA, F24, etc.);
- NNN: il codice progressivo del documento nellambito della tipologia XXX.
STPG-MO-001 Nuovi Servizi Parte Generale;
FIRMA-MO-001 Introduzione alla Firma Digitale: aspetti tecnici e generalit.

Dato il livello di approfondimento dei temi trattati, il Documento si configura come Manuale Operativo e
destinato a quanti sono chiamati ad effettuare le implementazioni necessarie al Porting.

1.1 STRUTTURA DEL DOCUMENTO

Il documento strutturato nelle seguenti sezioni:
- Definizione del Servizio Porting Attuali Tracciati;
- Regole di governance;
- Diagnostica;
- Individuazione dellindirizzo di erogazione del Servizio;
- Livelli di servizio;
- Firma digitale applicata al Porting;
- Criteri di identificazione univoca di messaggio e file (Allegato A);
- Popolamento del Directory ai fini del Porting (Allegato B);
- Struttura dei messaggi XML (Allegato C);
- Esempi di messaggi XML (Allegato D).
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
10/ 59



2 Il Servizio PORTING ATTUALI TRACCIATI

2.1 INTRODUZIONE

I supporti logici in uso nellattuale architettura sono veicolati nella Nuova Architettura mediante linvocazione,
da parte della Banca Mittente, di un Servizio PORTING ATTUALI TRACCIATI, strutturato come segue:
- invio verso la Banca Destinataria di un file di supporti logici (veicolato tramite file transfer);
- invio verso la Banca Destinataria di un messaggio XML (veicolato tramite message switching)
contenente i riferimenti del file e le informazioni riepilogative sui supporti logici in esso contenuti.

A tale invocazione di servizio, la Banca Destinataria risponde inviando verso la Banca Mittente uno o pi
messaggi XML di stato avanzamento/segnalazione errori rilevati.

In deroga a quanto definito nel documento CBI-STD-001, nel presente documento per supporti logici
informativi si intendono i supporti aventi come destinatario finale una azienda (es. RH, esiti RiBa) mentre
vengono indicati come dispositivi i supporti logici aventi come destinatario finale una banca (es. PC, RiBa).

Il Servizio PORTING ATTUALI TRACCIATI un unicum, con ununica invocazione, ancorch sia composto
da due parti logicamente correlate linvio di un file e linvio del relativo messaggio - che devono risultare
altres sincronizzate tra loro.
In linea con tale principio, i capitoli che seguono sono stati redatti in accordo ai seguenti criteri base:
- la funzionalit di sincronizzazione, in invio e ricezione, di file+messaggio fornita da un apposito
modulo applicativo, realizzato e messo a disposizione delle Banche della Comunit CBI. Tale funzionalit,
pertanto, non a carico delle Applicazioni Bancarie;
- tutti i flussi (supporti logici, file di supporti logici e messaggi) devono essere sottoposti a diagnostica
prima del loro invio sulla Rete Logica; tale diagnostica deve essere effettuata tramite un diagnostico
certificato (in accordo ai requisiti definiti da ACBI);
- la responsabilit delle attivit di diagnostica in capo alla Banca, fermo restando la facolt di
questultima di delegare tale attivit ad un soggetto terzo (Gestore del Punto dAccesso, STD etc.).


2.2 PORTI NG DEGLI ATTUALI TRACCI ATI : CASO DUSO

Al fine di descrivere le funzionalit e le caratteristiche tecnologiche offerte dalla Nuova Architettura rispetto
alla veicolazione dei supporti logici, stato identificato un caso duso descrittivo dellinvocazione della
richiesta di servizio da parte della Banca Mittente e delle relative risposte inviate dalla Banca Destinataria.

Il caso duso prende in considerazione linvocazione del Servizio ed i relativi stati di
avanzamento/segnalazioni derrore ed stato sviluppato costruendo un modello UML rappresentato da:
sequence diagram: descrive le interazioni tra i vari soggetti/attori in funzione dello scorrere del tempo,
rappresentato dallasse verticale del diagramma;
activity diagram: descrive il flusso delle attivit svolte dai diversi attori evidenziandone i possibili
parallelismi.

2.2.1 Ipotesi di base ed attori identificati

Al fine di garantire la generalit del modello, questo stato costruito in accordo alle seguenti ipotesi di
base:
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
11/ 59


le attivit potenzialmente delegabili ad una STD sono state assegnate alla Banca; il che comporta che nel
modello i due attori sono coincidenti. A ciascuna Banca lasciata la valutazione se tali attivit debbano
essere svolte in proprio o, sotto la propria responsabilit, tramite STD;
le modalit di accesso alla Nuova Architettura (NA) dipendono dal contesto tecnologico/architetturale di
riferimento esistente presso ciascuna Banca (es. Punto di Accesso NA presso la STD della Banca). Per
questo motivo il Gestore del Punto di Accesso non identificato come attore autonomo, ma coincide
con la Banca. A ciascuna Banca lasciata la valutazione se tali attivit debbano essere svolte in proprio
o, sotto la propria responsabilit, tramite STD oppure un Gestore del Punto di Accesso;
linvio del file/messaggio avviene direttamente tra Banca Mittente e Banca Destinataria; non
considerato in questo modello lutilizzo di repository esterni residenti presso Terze Parti;
linvio/ricezione del file+messaggio a carico di una apposita funzione di sincronizzazione fornita da un
modulo di sistema.

Il modello logico di interconnessione utilizzato per la modellazione del caso duso riportato nella figura
seguente

Punto di
Accesso
NA
Banca
Destinataria
Punto di
Accesso
NA
Banca Mittente
Directory
Le modalit di interconnessione Banca - Punto di Accesso NA potranno essere
differenti per ciascuna banca (es. Punto di Accesso NA presso la Banca/STD)
Azienda
cliente
Azienda
cliente

Figura 1 Modello logico dinterconnessione

Alla luce di quanto sopra, gli attori utilizzati per la costruzione del caso duso sono:
Banca Mittente
Banca Destinataria
Directory

Si evidenzia inoltre che lesecuzione delle attivit di seguito descritte (Cfr. sequence e activity diagram)
presuppone limplementazione, da parte di ciascuna Banca, di uno specifico workflow applicativo, necessario
alleffettivo svolgimento delle attivit riportate.

Le modalit di implementazione di tale workflow dipenderanno dal contesto tecnologico di riferimento di
ciascuna Banca, in funzione del quale le attivit descritte potranno essere svolte direttamente dalla Banca,
dalla relativa STD o da un soggetto terzo (Centro Servizi, Gestore punto di accesso Nuova Architettura etc.).

Fermo restando che la tratta Azienda Banca funzionalmente di pertinenza della Banca stessa, lobiettivo
del caso duso quello di evidenziare le principali attivit in carico ai vari attori bancari e di fornire una
visione complessiva del workflow applicativo da implementare.


2.2.1.1 Sequence diagram

La seguente Figura riporta il sequence diagram del caso duso, unitamente ad una descrizione sintetica delle
attivit svolte; la descrizione di dettaglio di ciascuna attivit riportata nel seguito del paragrafo.

Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
12/ 59


Banca Destinataria Banca Mittente Directory
8: Invio query di
indirizzamento sul Directory
(opzionale)
File
9: Esecuzione query
10: Invio indirizzoBanca Destinataria

XML
13: Ricezione
messaggio+file
12: Invio file+messaggio
XML
File
XML
File
18: Diagnostica applicativa supporti
logici (diagnostica attuale formale) 20: Invio messaggio stato
avanzamento(OK)/ errori rilevati(KO)
XML
16: Predisposizione
messaggio di
avanzamento / di errore

19: Predisposizione stato


avanzamento/ errori rilevati
XML
1: Predisposizione supporti
logici
7: Verifica informazioni di
indirizzamento disponibili
11: Ricezione indirizzo
Banca Destinataria
2: Diagnostica applicativa
supporti logici
(attuale diagnostica formale)
4: Predisposizione messaggio
XML associato al file
3: Predisposizione e
diagnostica file
5. Diagnostica coerenza file-
messaggio
6. Diagnostica messaggio XML

17: Invio messaggio stato avanzamento


(OK) / errori rilevati (KO)
14: Diagnostica messaggio
XML (vedi 6)
15: Verifica omogeneit
file e coerenza file-
messaggio (vedi 3 e 5)



Figura 2 Sequence diagram

Descrizione delle attivit:

1 - 2: La Banca Mittente predispone e diagnostica i supporti logici da inviare (attuale diagnostica formale dei
supporti logici).
3 - 6: Predisposti i supporti logici, la Banca Mittente provvede alla predisposizione ed alla diagnostica del file
fisico e, quindi, alla creazione del messaggio XML con le informazioni sui supporti logici contenuti nel file.
La Banca Mittente diagnostica il messaggio XML predisposto e verifica la coerenza tra file e messaggio, in
termini di puntatori e referenze messaggio-file.
7-11: La Banca Mittente verifica la completezza delle informazioni di indirizzamento a propria disposizione. In
caso di verifica positiva, provvede allinvio del file+messaggio (Cfr. punto 12). Nel caso in cui le
informazioni di indirizzamento non siano gi disponibili alla Banca Mittente, questultima provvede allinvio
al directory di una query specifica di indirizzamento; Tale query viene elaborata dal Directory e la relativa
risposta viene quindi restituita alla Banca Mittente (indirizzo di Rete Logica della Banca Destinataria
corrispondente al Servizio di porting).
12: Ottenute tutte le informazioni necessarie allindirizzamento, la Banca Mittente invoca la primitiva send
file+messaggio per linvio del file e del messaggio associato verso il Destinatario.
13 - 17: Ricevuto file e messaggio, la Banca Destinataria provvede ad eseguire la diagnostica del messaggio
XML e la verifica di congruenza dei riferimenti messaggio file. Nel caso di errori, invia un messaggio
XML verso la Banca Mittente contente la descrizione degli errori rilevati (KO), sospendendo lelaborazione
del messaggio XML e del relativo file. Nel caso in cui non vi siano errori la Banca Mittente predispone ed
invia un messaggio XML di stato davanzamento (OK).
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
13/ 59


18 - 20: Eseguita lattuale diagnostica formale sui supporti logici, la Banca Destinataria predispone un
messaggio XML di stato di avanzamento (OK)/notifica errori rilevati (KO) e lo invia verso la Banca
Mittente.

2.2.1.2 Activity Diagram

Le figure seguenti riportano, in accordo alle attivit previste dal sequence diagram, lactivity diagram relativo
al caso duso descritto, unitamente alla descrizione delle attivit rappresentate sul diagramma.

Banca
Destinataria
Banca
Destinataria
Banca Mittente Banca Mittente
Directory
1.Predisposizione
supporti logici
1.Predisposizione
supporti logici
9.Esecuzione
query
10.Invio indirizzo
Banca Destinataria
2.Diagnostica applicativa
supporti logici (attuale
diagnostica formale)
2.Diagnostica applicativa
supporti logici (attuale
diagnostica formale)
3: Predisposizione e
diagnostica file
3: Predisposizione e
diagnostica file
4: Predisposizione
messaggio XML associato
al file
4: Predisposizione
messaggio XML associato
al file
7: Verifica informazioni di
indirizzamento disponibili
7: Verifica informazioni di
indirizzamento disponibili
8: Invio query di
indirizzamento sul
Directory
8: Invio query di
indirizzamento sul
Directory
11: Ricezione indirizzo
Banca Destinataria
11: Ricezione indirizzo
Banca Destinataria
12: Invio file+messaggio 12: Invio file+messaggio
Info disponibili
NO
SI
5: Diagnostica coerenza
file-messaggio
5: Diagnostica coerenza
file-messaggio
6: Diagnostica messaggio
XML
6: Diagnostica messaggio
XML


Figura 3 Activity diagram Parte 1

La Banca Mittente predispone i supporti logici da inviare, eseguendo i relativi controlli diagnostici (attuale
diagnostica formale).
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
14/ 59


Completata tale attivit, la Banca Mittente predispone il file fisico ed il messaggio XML associato, verifica la
completezza delle informazioni di indirizzamento disponibili e, in caso di verifica positiva, provvede ad
avviare la fase di invio di file+messaggio.

Nel caso in cui le informazioni dindirizzamento non fossero complete, la Banca Mittente provvede ad inviare
al Directory una query di indirizzamento al fine di ottenere tali informazioni; elaborata tale richiesta, il
Directory provvede ad inviare lindirizzo della Banca Destinataria verso la Banca Mittente.

Ottenute le informazioni per lindirizzamento, la Banca Mittente provvede quindi allinvio del file+messaggio.

Banca
Destinataria
Banca
Destinataria
Banca Mittente Banca Mittente
Directory
13: Ricezione
messaggio+file
13: Ricezione
messaggio+file
14: Diagnostica
messaggio XML (vedi 6)
14: Diagnostica
messaggio XML (vedi 6)
13: Verifica omogeneit
file e coerenza file-
messaggio (vedi 3 e 5)
Errori rilevati
14: Predisposizione e
invio messaggio di
errore
SI
NO
16: Diagnostica
applicativa supporti
logici (attuale
diagnostica formale)
16: Diagnostica
applicativa supporti
logici (attuale
diagnostica formale)
17: Predisposizione
stato avanzamento/
errori rilevati
17: Predisposizione
stato avanzamento/
errori rilevati
18: Invio messaggio
stato avanzamento/
errori rilevati
18: Invio messaggio
stato avanzamento/
errori rilevati
15: Invio messaggio
stato avanzamento
15: Invio messaggio
stato avanzamento


Figura 4 Activity diagram - Parte 2

La Banca Destinataria, ricevuti file e messaggio, provvede ad eseguire la diagnostica del messaggio XML e la
verifica di congruenza rispetto al contenuto del file.

Nel caso di errori, invia un messaggio XML verso la Banca Mittente contenente la descrizione degli errori
rilevati, sospendendo lelaborazione del messaggio XML e del relativo file (Cfr. Par. successivi per le regole di
comportamento). Nel caso in cui non vi siano errori la Banca Destinataria predispone ed invia un messaggio
XML di stato davanzamento.

Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
15/ 59


La Banca Destinataria esegue la diagnostica dei supporti logici e invia un messaggio XML di stato di
avanzamento/errori rilevati verso la Banca Mittente.

2.2.1.3 Considerazioni su Sequence e Activity diagram

Al fine di completare la descrizione del Servizio PORTING ATTUALI TRACCIATI rappresentata dal sequence
e dallactivity diagram, e ricordando quanto gi espresso precedentemente al Capitolo 2.1 - ovvero che la
responsabilit delle attivit di diagnostica in capo alla Banca, fermo restando la facolt di questultima di
delegare tale ad un soggetto terzo (Gestore del Punto dAccesso, STD etc.) - deve essere comunque
evidenziato che:
- ogni Banca Mittente ha lobbligo di garantire alla Banca Destinataria la rispondenza di quanto inviato agli
standard in uso tramite un diagnostico certificato (in accordo ai requisiti definiti da ACBI) ed
evidenziando nel messaggio le informazioni relative a tale diagnostico
- la Banca Destinataria ha il diritto di ricevere flussi conformi agli standard in uso e diagnosticati tramite
un diagnostico certificato (in accordo ai requisiti definiti dal Consorzio CBI)

2.3 INVOCAZI ONE DI SERVI ZIO

Facendo riferimento al caso duso sopra descritto, in estrema sintesi - rispetto alle procedure oggi in essere -
la Banca Mittente dovr prevedere:
nuovi criteri di omogeneit dei flussi
creazione e gestione del messaggio XML
predisposizione e gestione di workflow per il Servizio
diagnostica del messaggio XML

In particolare il processo seguir i seguenti passi:

Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
16/ 59


3a.Predisposizione e
diagnostica file
1.Predisposizione
supporti logici
1.Predisposizione
supporti logici
2.Diagnostica supporti logici
(attuale diagnostica formale)
3b.Costruzione del
messaggio XML (contiene i
riferimenti applicativi al file)
5.Spedizione file+messaggio
6.Ricezione dalla rete di ok di
trasmissione file+messaggio
3c.Diagnostica messaggio
XML
7.Attesa risposta applicativa stato
avanzamento/errori rilevati
4.Verifica coerenza file-
messaggio
8.Attesa risposta applicativa stato
avanzamento/errori rilevati


Figura 5 Processo invio messaggio + file

Rispetto alle procedure oggi in essere, la Banca Destinataria dovr gestire un processo con i seguenti passi:

Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
17/ 59


1: Ricezione
messaggio+file
1: Ricezione
messaggio+file
2: Diagnostica messaggio
XML
2: Diagnostica messaggio
XML
3: Verifica omogeneit file
e coerenza file-messaggio
Errori rilevati
4: Invio messaggio di errore 4: Invio messaggio di errore
SI
NO
6: Diagnostica supporti
logici (diagnostica
attuale formale)
6: Diagnostica supporti
logici (diagnostica
attuale formale)
7: Predisposizione stato
avanzamento/ errori
rilevati
7: Predisposizione stato
avanzamento/ errori
rilevati
8: Invio messaggio
stato avanzamento/
errori rilevati
8: Invio messaggio
stato avanzamento/
errori rilevati
5: Invio messaggio
stato avanzamento
5: Invio messaggio
stato avanzamento


Figura 6 Processo ricezione messaggio + file


2.3.1 Regole per la creazione del supporto logico

Gli standard previsti per la creazione del supporto logico sono quelli gi in essere per gli attuali Servizi CBI.
In particolare si confermano i criteri di omogeneit definiti per la creazione del supporto.


2.3.2 Regole per la creazione del file

Allinterno di un file fisico la Banca pu
1
, discrezionalmente, inserire uno o pi supporti logici.
I supporti logici devono essere omogenei per:

1
Per lo scambio di flussi informativi tra Banche si raccomanda la minimizzazione del numero di file fisici (per
ragioni legate alla performance). In particolare, per quanto riguarda i flussi informativi destinati alla Clientela
la Banca Passiva tenuta ad operare con criteri di omogeneit per Banca Proponente/Destinataria.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
18/ 59


- tipo supporto (es. PC, RH);
- destinatario logico (es. Banca Passiva per i flussi PC, Banca Proponente per i flussi RH);
- soggetto di riferimento del destinatario logico (es. STD, GPA);
- indirizzo di Rete Logica del soggetto di riferimento;
- applicazione della firma digitale.

Per i file contenenti supporti logici non firmati, il numero massimo di supporti logici da includere nel file
fisico fissato a 1500. Tale limite garantisce che i successivi messaggi di stato avanzamento abbiano una
dimensione massima di 1 MB.

Per i file contenenti supporti logici firmati, il numero massimo degli stessi (comunque non superiore a 1500)
non definito a priori ma in funzione del rispetto della dimensione di 1 MB del messaggio di
accompagnamento del file dove i supporti logici sono referenziati e dove presente codificata in base64
la busta contenente la firma digitale.

Si osserva che, alla data, la rete logica CBI non consente la veicolazione di file la cui dimensione superi 2GB
(cfr. specifiche del fornitore di rete), pertanto laggregazione dei supporti logici nei file deve essere effettuata
tenendo in considerazione anche tale limite.

Si evidenzia come, in funzione delle informazioni di indirizzamento disponibili a ciascuna Banca, le attivit di
predisposizione del file potranno prevedere uno o pi accessi al Directory al fine di verificare il rispetto dei
criteri di omogeneit definiti. Per semplicit di rappresentazione tali accessi non sono riportati sui diagrammi
ma possono essere derivati direttamente da quanto su di essi riportato (cfr. Punti 8-9-10 del sequence
diagram o punti 8-9-10-11 dellactivity diagram).

Al fine di semplificare la verifica dintegrit del file, lordine dei supporti logici che lo costituiscono dovr
essere lo stesso di quello riportato nel messaggio XML (Cfr. Par. 2.3.3.2 per i dettagli) e la corrispondenza
tra i campi Nome supporto nel messaggio XML e nel file dovr essere di tipo 1:1.

In particolare, il file dovr iniziare con il record di testa del primo supporto logico referenziato dal messaggio
XML e terminare con il record di coda dellultimo (Cfr. Standard Tecnici attuali servizi CBI per le regole di
composizione dei record di testa/coda).

Lassegnazione del Nome supporto dovr inoltre rispettare i criteri di univocit definiti (univocit per Nome
supporto, Tipologia flusso, Data creazione, Mittente e Destinatario) con un periodo di storico pari a
180 giorni di calendario.

In considerazione del fatto che non esiste alcuna correlazione tra la data di creazione del supporto logico e la
data in cui lo stesso effettivamente inviato alla controparte, la verifica di univocit deve essere effettuata
nellambito dei 180 giorni di calendario precedenti alla data in cui il controllo stesso effettuato dalla banca
e/o soggetto tecnico delegato e non alla data di creazione del supporto logico.

Sebbene il periodo entro il quale si deve effettuare il controllo di univocit delle chiavi identificative sia di 180
giorni di calendario, si raccomanda di garantire lunivocit dei supporti logici per un periodo pi ampio al fine
di facilitare eventuali attivit di storicizzazione e riconciliazione degli stessi anche a lungo termine.








Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
19/ 59


2.3.2.1 Esempi sui criteri di omogeneit

Di seguito vengono mostrati alcuni esempi sullapplicazione dei criteri di omogeneit sui supporti logici.

Esempio

Scenario File da predisporre
Flusso SL1 da Banca Passiva BS1 ad Azienda AZ1
AZ1 ha come Banca Proponente BR2
BR2 si avvale dei servizi della STD STD1 per erogare i servizi ad AZ1
File 1
Flusso SL2 da Banca Passiva BS1 ad Azienda AZ2
AZ2 ha come Banca Proponente BR2
BR2 si avvale dei servizi della STD STD2 per erogare i servizi ad AZ2
File 2

Nel caso in cui BS1 produca un unico file fisico contenente i supporti logici SL1 ed SL2, uno dei due sarebbe
recapitato al destinatario fisico errato, anche se la Banca Proponente indicata la stessa.

2.3.3 Regole per la creazione del messaggio

La Banca deve creare il messaggio XML secondo i criteri e gli standard gi previsti per i nuovi Servizi CBI. Si
faccia riferimento alla relativa documentazione per le specifiche di dettaglio (cfr. STPG-MO-001 Nuovi
Servizi - Parte Generale); nel seguito del paragrafo vengono riportate le considerazioni specifiche per il
servizio Porting.

2.3.3.1 Creazione Header di E2E di Servizio

In linea con quanto gi descritto nel documento STPG-MO-001 - Nuovi Servizi Parte Generale, le regole di
composizione dellHeader E2E di Servizio per il servizio Porting prevedono che il destinatario logico di un
flusso Banca/Cliente sia la Banca Proponente dellAzienda, la quale provveder poi a disaggregare i flussi in
base al Codice SIA dellAzienda.
In modo analogo, il mittente logico previsto nella tratta Cliente/Banca la Banca Proponente dellAzienda,
che provveder in questo caso ad aggregare i flussi diretti verso la stessa Banca Passiva.
Di seguito vengono mostrati alcuni scenari esemplificativi, in cui:

AZ1 un Cliente CBI della Banca Proponente BR1
BR1 accede alla NACBI mediante un GPA GPA1 (in alternativa si pu prevedere una STD STD1)
BS1 una Banca Passiva ed accede alla NACBI mediante un GPA GPA2 (in alternativa si pu prevedere
una STD STD2)


Scenario Hdr Campi
Richiesta di
Servizio
Mittente Fisico CUC GPA1
Header di
Tratta Destinatario Fisico CUC GPA2
Mittente Logico CUC BR1
Tipo SdR Mittente GPA
Id SdR Mitt CUC GPA1
Destinatario Logico CUC BS1
Tipo SdR Destinatario GPA
Flussi diretti da Azienda AZ1 a Banca
Passiva BS1

Header
E2E
Id SdR Dest CUC GPA2
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
20/ 59



Scenario Hdr Campi
Richiesta di
Servizio
Mittente Fisico CUC GPA2
Header di
Tratta Destinatario Fisico CUC GPA1
Mittente Logico CUC BS1
Tipo SdR Mittente GPA
Id SdR Mitt CUC GPA2
Destinatario Logico CUC BR1
Tipo SdR Destinatario GPA
Flussi diretti da Banca Passiva BS1 ad
Azienda AZ1

Header
E2E
Id SdR Dest CUC GPA1

2.3.3.2 Creazione Body di Servizio

In Allegato C sono riportate le specifiche per la strutturazione del Body di servizio unitamente alla
descrizione dello schema XML.

Nella costruzione del messaggio, lordine dei supporti logici referenziati (campo Nome supporto) dovr
essere lo stesso di quello riportato nel file.

Si evidenzia inoltre come ad ogni messaggio debba corrispondere uno ed un solo file fisico.


2.4 STATI DI AVANZAMENTO

Il sequence diagram relativo al Caso duso descrive i messaggi XML scambiati tra Banca Mittente e Banca
Destinataria durante lesecuzione di una richiesta di Servizio.

La Banca Mittente (es. Banca Proponente nel caso di PORTING-PC, Banca Passiva nel caso di PORTING-
RH) invia un messaggio XML + file verso la Banca Destinataria (es. Banca Passiva nel caso di PORTING-
PC, Banca Proponente nel caso di PORTING-RH cfr. punto 12 sequence diagram) che provvede a:
- eseguire la diagnostica del messaggio XML;
- verificare lomogeneit del file e la coerenza file-messaggio.

Dopodich, la Banca Mittente predispone e invia un primo messaggio di avanzamento/errori rilevati (cfr.
punto 17) verso la Banca Mittente.
Nel caso in cui il file sia stato ricevuto correttamente e lassociazione tra i supporti logici dichiarati nel
messaggio XML e quelli contenuti nel file sia corretta, la Banca Destinataria esegue la diagnostica applicativa
dei supporti logici (attuale diagnostica formale) e invia successivamente un secondo messaggio di
avanzamento verso la Banca Mittente (cfr. punto 20).

Lidentificazione e la correlazione dei vari messaggi (richiesta di servizio pi i 2 messaggi di stato
avanzamento) necessaria per lespletamento del servizio avviene attraverso il campo Nome file allinterno
del blocco Info file (presente sia nel messaggio XML di richiesta di servizio sia nei messaggi XML di stato
avanzamento), riportati nel body di servizio (Cfr. Allegato C per i dettagli).

Si evidenzia altres come ogni messaggio XML scambiato avr sempre un proprio IDE2E univoco e distinto; in
considerazione del fatto che lIDT legato allIDE2E, ogni messaggio avr un proprio IDT univoco e distinto.
In particolare l'Header E2E del messaggio di risposta dovr essere rigenerato in coerenza con il nuovo
Header di Tratta, prevedendo un identificativo diverso, data diversa, soggetto mittente e ricevente invertiti
rispetto al messaggio originario.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
21/ 59



Si faccia riferimento allAllegato C per le specifiche di strutturazione del messaggio di richiesta di servizio e
del relativo messaggio di stato davanzamento/errori rilevati.

Nei seguenti paragrafi vengono descritti, in dettaglio, i controlli da eseguire per linvio dei 2 messaggi di
avanzamento, unitamente alle regole da seguire per la loro composizione.

2.4.1 Controlli e regole di composizione del 1 messaggio di avanzamento

Ricevuto il file + messaggio XML dalla Banca Mittente, la Banca Destinataria dovr eseguire i seguenti
controlli:
Diagnostica messaggio XML (parsing)
2

Verifica coerenza messaggio/file:
- verifica congruenza e omogeneit dei supporti logici in base a quanto dichiarato nel messaggio XML:
o coerenza tag Nome servizio (cfr. Header di Tratta e Header di Servizio es. PORTING-
PC) e tag Tipologia flusso (es. PC); in questo caso lerrore riguarda una incoerenza
allinterno del messaggio XML e verr segnalato attraverso il messaggio derrore general
purpose (cfr. Par. 4.4.4);
o coerenza dei tag Nome servizio, Tipologia flusso (presenti nel messaggio XML) e dei
campi tipo record riportati nel record di testa di tutti i supporti logici contenuti nel file
- verifica di coerenza tra i supporti logici referenziati nel messaggio XML e quelli contenuti nel file,
mediante confronto tra campi secondo quanto riportato nella seguente tabella:

Flussi da Banca Proponente a Banca Passiva
Messaggio XML Record di testa del supporto logico
<SIACd> mittente (pos. 4-8)
<ABICd> ricevente (pos. 9-13)
<CreDt> data creazione (pos. 14-19)
<SppNm> nome supporto (pos. 20-39)
Flussi da Banca Passiva a Banca Proponente
Messaggio XML Record di testa del supporto logico
<SIACd> ricevente (pos. 9-13)
<ABICd> mittente (pos. 4-8)
<CreDt> data creazione (pos. 14-19)
<SppNm> nome supporto (pos. 20-39)


Per i soli flussi dispositivi, verifica coerenza tra Codice ABI della Banca (Banca Passiva) contenuto in
ogni blocco Info supporto del messaggio XML e CUC della Banca Destinataria (Banca Passiva)
riportato nellHeader di Servizio
3
. Si fa notare come tale controllo garantisca lomogeneit dei supporti
logici relativamente al destinatario logico cui gli stessi sono indirizzati (Banca Passiva)
Verifica omogeneit dei supporti logici per soggetto di riferimento del destinatario logico (STD/GPA)
Verifica omogeneit dei supporti logici relativamente allutilizzo della firma digitale e alla tipologia di
firma utilizzata (valore del tag <SngTyp>). (cfr. paragrafo 7.2)

2
Ad eccezione di casi particolari di errore (segnalati attraverso il primo messaggio di stato avanzamento), a
fronte del riscontro di errori di parsing nel messaggio XML, viene inviato un messaggio di errore general
purpose descritto nel documento Nuovi Standard Tecnici Parte generale.
In caso di errori non previsti dal workflow del servizio (es. errori di accesso al messaggio XML, etc.), lerrore
dovr essere comunque segnalato utilizzando il messaggio general purpose descritto nel documento
Nuovi Standard Tecnici Parte generale.
3
Tale controllo non previsto nel caso di ricezione di flussi informativi nellambito della tratta Banca
Passiva Cliente.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
22/ 59


Per i soli flussi firmati digitalmente, controllo del mittente fisico per accertarsi che lo stesso risulti
abilitato dal CBI allimmissione in rete di supporti logici firmati con la specifica tipologia di firma (cfr.
paragrafo 7.1)

Nel caso di esito positivo dei suddetti controlli (ossia supporti logici referenziati dal messaggio XML in
corrispondenza 1:1 con quelli presenti nel file, il quale termina dopo lultimo supporto logico referenziato nel
messaggio XML), le regole di composizione del messaggio 17 prevedono linvio verso la Banca Mittente di un
messaggio contenente solo il blocco di informazioni Info file con stato Ricevuto (Cfr. Appendice C per i
dettagli).

In caso di esito negativo di tali verifiche, il file viene scartato e il workflow della Banca Destinataria si chiude
con linvio del messaggio 17 costruito come segue:
In caso di errori rilevati sul file:
- blocco Info file presente, con stato Errori rilevati (+ codice derrore specifico);
- blocco Info supporto assente
In caso di errori rilevati sul supporto logico:
- blocco Info file presente, con stato Errori rilevati (+ codice derrore specifico);
- blocco Info supporto presente, con stato Errori rilevati (+ codice derrore specifico)
Relativamente alle regole di costruzione del messaggio 17, si evidenzia che:
In caso di disallineamento tra messaggio XML e file, si fa riferimento a quanto riportato nel messaggio
XML per la rilevazione e la segnalazione degli errori
In caso di errore sul singolo supporto logico, dovr essere segnalato solo il 1 errore rilevato (una sola
occorrenza del blocco SendSts nel messaggio 17)

Il sequence diagram che segue mette in evidenza i possibili stati davanzamento del file e dei supporti logici
inclusi nel messaggio 17 di risposta.

Banca Destinataria Banca Mittente Directory
13: Ricezione
messaggio+file
12: Invio file+messaggio
XML
File
XML
File
16: Predisposizione
messaggio di
avanzamento / di errore
XML
11: Ricezione indirizzo
Banca Destinataria
17: Invio messaggio stato avanzamento
(OK) / errori rilevati (KO)
14: Diagnostica messaggio
XML (vedi 6)
15: Verifica omogeneit
file e coerenza file-
messaggio (vedi 3 e 5)
1

m
e
s
s
a
g
g
i
o
Stato avanzamento file
Ricevuto
Errori rilevati
- Errore diagnostica msg XML
- File non trovato
- File inutilizzabile
- Limite massimo supporti logici superato
- Supporti non omogenei, non corrisp. o
inutilizzabili
Stato avanzamento supporti logici
Errori rilevati
- Supporto non omogeneo per tipologia
flusso
- Supporto non omogeneo per destinatario
- Supporto non omogeneo per applicazione
firma digitale
- Supporto non presente nel file
- Supporto non presente nel msgXML
- Supporto logico inutilizzabile
- ABI e CUC Banca Passiva non coerenti
Se disponibili le informazioni
sui supporti logici



La tabella riportata di seguito mostra, per ogni stato davanzamento relativo al file, i possibili stati di
avanzamento inerenti i supporti logici.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
23/ 59




Stato avanzamento file
Stato avanzamento singoli supporti logici (Cfr.
blocco Info supporto)
Ricevuto BLOCCO DI INFORMAZIONE ASSENTE
Errori rilevati
- Errore diagnostica msg XML
- File non trovato
- File inutilizzabile
- Limite massimo supporti logici
superato
BLOCCO DI INFORMAZIONE ASSENTE
Errori rilevati
- Supporti non omogenei, non
corrispondenti o inutilizzabili
Errori rilevati
- Supporto non omogeneo per tipologia
flusso
- Supporto non omogeneo per destinatario
- Supporto non omogeneo per applicazione
firma digitale
- Supporto non presente nel file
- Supporto non presente nel msg XML
- Supporto logico inutilizzabile
- ABI e CUC Banca Passiva non coerenti

Come specificato, in caso di disallineamento tra messaggio XML e file, si deve fare riferimento al messaggio
XML. In caso di errore sul controllo di corrispondenza si possono verificare 2 casi:
se il supporto logico presente nel messaggio XML ma non presente nel file, nel blocco "Info supporto"
del messaggio 17 si indica il "nome supporto" riportato nell'XML, specificando il codice d'errore "Supporto
non presente nel file"
se il supporto logico presente nel file ma non presente nel messaggio XML, nel blocco "Info supporto"
del messaggio 17 si indica il "nome supporto" riportato nel file, specificando il codice d'errore "Supporto
non presente nel msg XML".

2.4.2 Controlli e regole di composizione del 2 messaggio di avanzamento

In caso di esito positivo di tutti i controlli previsti per il messaggio 17, la Banca Destinataria esegue la
diagnostica applicativa dei supporti logici (attuale diagnostica formale e verifica della firma digitale
4
se
presente) e invia il relativo messaggio di avanzamento (cfr. punto 20 del sequence diagram), costruito come
segue:

Blocco Info file presente, con stato Ricevuto
Una occorrenza del blocco Info supporto per ogni supporto logico rilevato nel file, con stato
Diagnostica supporto logico OK/Errori rilevati (+ dettagli errore)

Per i soli flussi informativi non indirizzati verso Market Place
5
, in aggiunta alla diagnostica applicativa e ai fini
della generazione del 2 messaggio di avanzamento, la Banca Destinataria deve, per ogni supporto logico,
effettuare il controllo di congruenza tra la Banca Proponente (ricavata dal codice SIA destinatario) e il
destinatario logico (Banca Proponente) dichiarato nellapposito campo presente nellHeader di Servizio del
messaggio XML. I soli supporti per i quali tale controllo restituisce esito negativo devono essere scartati
utilizzando lapposito codice di errore 058 (Banca Proponente non coerente con anagrafica clienti) .

4
Si rimanda al paragrafo 7 per dettagli sulle modalit di composizione del 2 messaggio di stato
avanzamento in caso di errore nella verifica della firma
5
Si rammenta che i flussi indirizzati verso Market Place sono riconoscibili da specifici valori presenti in
appositi campi contenuti nel record di testa dei supporti logici
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
24/ 59


I soli supporti per i quali il codice SIA destinatario non risulti censito nellanagrafica di riferimento (nodo
cliente assente sul Directory) devono essere scartati utilizzando lapposito codice di errore 042 (soggetto non
aderente)
6
.
In caso di errori rilevati, dovranno essere segnalati da 1 a 3 errori (+ dettagli errore) per ciascun supporto
logico.

Il sequence diagram che segue mette in evidenza i possibili stati davanzamento del file e dei supporti logici
inclusi nel messaggio 20 di risposta.


Banca Destinataria Banca Mittente Directory
18: Diagnostica applicativa supporti
logici (diagnostica attuale formale)
20: Invio messaggio stato
avanzamento(OK)/ errori rilevati(KO)
19: Predisposizione stato
avanzamento/ errori rilevati
Ricevuto Diagnostica supporto logico ok
Errori rilevati
- Errori su supporto logico (+Dettagli errore)
2

m
e
s
s
a
g
g
i
o


Per quanto riguarda invece il messaggio sullo stato davanzamento al punto 20 del sequence diagram, lo
stato di avanzamento file sar sempre Ricevuto, come riportato di seguito.

Stato avanzamento file Stato avanzamento supporti logici
Ricevuto
Diagnostica supporto logico ok
Errori rilevati
- Errori su supporto logico (+ dettagli errore)


2.5 CONSI DERAZI ONI SU INVI O SUPPORTI LOGI CI F4, R4

A seguito della ricezione di un flusso F4 o di un flusso R4, la Banca Destinataria (Banca Passiva) dovr
comportarsi come segue:

predisporre ed inviare il messaggio 20 (Cfr. sequence diagram) dopo aver eseguito i controlli
attualmente in carico ai Soggetti Veicolatori (messaggio obbligatorio); in funzione del risultato di tali
controlli, potr verificarsi uno dei tre scenari riportati:

1. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori e nessun
errore riscontrato dalla Banca Passiva a seguito dei propri controlli applicativi su tutti i campi dei
supporti logici:
la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore;
la Banca Destinataria esegue gli attuali controlli Banca Passiva e predispone il flusso A4, in
accordo alle attuali regole, senza segnalare alcun errore;
la Banca Destinataria invia il flusso A4 attraverso il servizio PORTING-A4, inclusi i messaggi
di stato davanzamento previsti

6
Per la lista completa dei codici di errore disponibili si faccia riferimento al documento CBI-STD-001
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
25/ 59



2. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori ed errori
riscontrati dalla Banca Passiva a seguito degli attuali controlli Banca Passiva:
la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore;
a seguito di errori riscontrati a fronte dei controlli Banca Passiva predispone il flusso A4, in
accordo alle attuali regole, con la segnalazione degli errori;
la Banca Destinataria invia il flusso A4 attraverso il servizio PORTING-A4, inclusi i messaggi
di stato davanzamento previsti

3. Riscontro di errori a fronte dei controlli attualmente in carico ai Soggetti Veicolatori:

gli attuali controlli in carico ai Soggetti Veicolatori passano in carico alla Banca Destinataria;
la Banca Destinataria invia sempre un messaggio 20 con esito positivo e prosegue con le
elaborazioni successive (Cfr. Par. 6.3 documento CBI-F24-001); solo in caso di supporti
logici duplicati o incongruenze tra tipo record di testa e tipo record di coda, la Banca
Destinataria dovr generare un messaggio 20 con la segnalazione dellerrore senza
proseguire con le elaborazioni successive;
la Banca Destinataria, tranne che in caso di supporti logici duplicati, dovr sempre generare
un flusso A4, attraverso il servizio PORTING-A4, sia in caso di esito positivo che in
presenza di errori.

2.6 CONSI DERAZI ONI SU INVI O SUPPORTI LOGI CI Q4, A4

A seguito della ricezione di un flusso Q4 o A4, la Banca Destinataria (Banca Proponente) dovr comportarsi
come segue:

predisporre ed inviare il messaggio 20 (Cfr. sequence diagram) dopo aver eseguito i controlli
attualmente in carico ai Soggetti Veicolatori (messaggio obbligatorio)
7
; in funzione del risultato di tali
controlli, potr verificarsi uno dei tre scenari riportati:

1. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori e nessun
errore riscontrato dalla Banca Proponente a seguito dei propri controlli applicativi su tutti i campi dei
supporti logici:
la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore

2. Nessun errore riscontrato a fronte dei controlli attualmente in carico ai Soggetti Veicolatori ed errori
riscontrati dalla Banca Ricevente a seguito degli attuali controlli Banca Proponente:
la Banca Destinataria invia il messaggio 20 dove non si segnala alcun errore;
a seguito di errori riscontrati a fronte dei controlli Banca Proponente la banca segnala
lerrore attraverso il Tavolo Operativo.

3. Riscontro di errori a fronte dei controlli attualmente in carico ai Soggetti Veicolatori:
gli attuali controlli in carico ai Soggetti Veicolatori passano in carico alla Banca Destinataria;
la Banca Destinataria invia un messaggio 20 con la segnalazione dellerrore senza proseguire
con le elaborazioni successive.






7
Se il flusso risulta illeggibile, si invia un apposito messaggio di errore general pur pose
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
26/ 59


2.7 CONSI DERAZI ONI SU INVI O SUPPORTI LOGI CI I 4

La veicolazione dei flussi I4 (pagamento di deleghe F24 Internet) sulla Nuova Architettura CBI avviene
secondo le stesse regole previste per gli altri servizi Porting (cfr. sequence diagram Par. 2.2.1.1).

Come illustrato nel sequence diagram di riferimento, il 2 messaggio di stato avanzamento (20) viene
predisposto in seguito alla diagnostica applicativa. Tuttavia, a differenza degli altri servizi Porting, nel caso
dei flussi I4, al fine di predisporre il 2 messaggio di stato avanzamento (20), la Banca Destinataria
(Passiva) dovr effettuare unicamente i controlli previsti per il record di testa; in caso di esito negativo
degli stessi, la Banca Destinataria (Passiva) segnaler gli errori attraverso il messaggio 20.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
27/ 59



3 Diagnostica

Al fine di garantire la correttezza dei flussi (messaggi e file/supporti) veicolati, ciascuna Banca dovr
implementare un processo di diagnostica per la verifica di file e messaggi.

La segnalazione di eventuali problemi/errori riscontrati dovr avvenire attraverso il messaggio XML Stato di
avanzamento (cfr. Capitolo 2.4), come illustrato dal sequence diagram del servizio.

Le segnalazioni di errore non previste dal workflow di servizio dovranno essere effettuate utilizzando il
messaggio standard di segnalazioni errori descritto nel documento STPG-MO-001 - Nuovi Servizi Parte
Generale.

3.1 DI AGNOSTI CA SUL MESSAGGI O

Relativamente ai controlli sul messaggio, la Banca deve effettuare i controlli sulla strutturazione del
messaggio XML e quelli sui singoli tag del messaggio stesso secondo i criteri e gli standard gi previsti per i
nuovi Servizi CBI (Cfr. Allegato STAA-ST-00Y per i dettagli sui controlli da effettuare).

3.2 DI AGNOSTI CA SUL FI LE

I controlli da effettuare riguardano il rispetto delle regole di creazione del file descritte al Par. 2.3.1.2 (es.
criteri di omogeneit).

3.3 DI AGNOSTI CA SUL SUPPORTO LOGI CO

I controlli da effettuare sul supporto logico (diagnostica applicativa) sono quelli previsti dagli attuali standard
tecnici CBI che prevedono controlli di tipo V (validit) e di tipo F (formali), per la definizione dei quali si
rimanda al documento CBI-STD-001 in vigore alla data.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
28/ 59



4 Regole di governance

Al momento della ricezione del file + messaggio XML, deve essere fatto oggetto di controllo:
- lunivoca correlazione tra messaggio e file fisico (corretto puntamento tra messaggio e file);
- lomogeneit dei supporti logici allinterno del file fisico
8
;
- la corrispondenza 1:1 tra i supporti logici contenuti nel file e quelli contenuti nel messaggio XML (lordine
dei supporti logici riportato nel file deve essere lo stesso di quello riportato nel messaggio XML Cfr.
Par. 2.3.2).

Nel caso in cui vengano segnalati degli errori nella prima fase delle verifiche (diagnostica messaggio XML e
coerenza file-messaggio) segnalati con il 1 messaggio di avanzamento (cfr. punto 17 sequence diagram),
lelaborazione sul ricevente si interrompe ed il 2 messaggio di stato di avanzamento non viene generato.

In particolare, nel caso in cui il 1 messaggio di avanzamento riporti un errore (AdvSts diverso da RCVD), il
file si intende rifiutato dal ricevente e nessuno dei supporti logici in esso contenuto sar oggetto di ulteriore
processing da parte del ricevente stesso; solo nel caso in cui il 1 messaggio di stato di avanzamento riporti
un esito di ricezione positiva del file (AdvSts pari a RCVD), il file si intende ricevuto da parte del destinatario,
il quale proceder alla esecuzione del diagnostico attuale sui supporti logici contenuti.

Durante l'esecuzione della diagnostica applicativa il 2 messaggio di avanzamento riporter sempre il
medesimo stato di ricevuto per il file (AdvSts pari a RCVD); relativamente ai supporti logici, quelli rifiutati
(AdvSts pari a ERRR con la codifica del codice dellerrore rilevato) non subiranno alcun ulteriore processing
da parte del ricevente mentre i supporti logici accettati (AdvSts pari a RCVD) verranno sottoposti
all'esecuzione dell'opportuno processo elaborativo.

4.1 MANCATO RISPETTO DELLE TEMPI STI CHE DI I NVIO DEI MESSAGGI DI AVANZAMENTO

Relativamente alle tempistiche di invio dei messaggi di avanzamento (Cfr. Capitolo 6 per i dettagli sugli SLA),
si assume che:
- la ricezione di ACK1
9
rappresenta per il mittente una garanzia sulla consegna da parte della Rete
- lorologio di riferimento per la misura degli SLA rappresentato dalla giornata applicativa

In particolare, nel caso in cui non si riceva uno dei messaggi di avanzamento previsti (cfr. punto 17/20 del
sequence diagram) all'interno degli SLA definiti per il servizio, il Mittente deve intraprendere le seguenti
azioni:
segnalazione al Performance Management
invio notifica al Tavolo Operativo che dovr attivare le segnalazioni necessarie (es. una per ogni
Destinatario, al termine della giornata applicativa, comprendente la descrizione delle anomalie)
la richiesta di servizio sar considerata inoltrata e ad esecuzione ritardata. A riguardo viene
effettuata un'ulteriore segnalazione al Performance Management
il mittente dovr essere in grado di gestire eventuali messaggi inviati in ritardo per almeno 5 giorni
lavorativi; oltre tale limite il workflow di servizio potr essere considerato chiuso e il mittente non
sar obbligato a gestire ulteriori messaggi ricevuti
non sar necessario il rinvio dei flussi
per la risoluzione dei problemi, il mittente potr attivarsi con SIA in caso di mancata ricezione di
ACK2
10
, e con la Banca in caso di ricezione di ACK2.

8
Cfr. paragrafo 2.3.2.
9
Conferma di presa in carico del messaggio XML + file, inviata alla Banca Mittente dal proprio nodo (Cfr.
documentazione SIA per i dettagli)
10
Notifica di recapito di messaggio XML + file, inviata dal nodo della Banca Destinataria alla Banca Mittente
(Cfr. documentazione SIA per i dettagli)
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
29/ 59



4.2 MANCATO RISPETTO DELLA SEQUENZA DI INVIO DEI MESSAGGI DI AVANZAMENTO

Nel caso di mancato rispetto, da parte della Banca Destinataria, della sequenza dinvio dei messaggi di
avanzamento (cfr. punti 17 e 20 sequence diagram), la Banca Mittente dovr:
chiudere il workflow applicativo in base alle informazioni contenute nel messaggio 20
ignorare il messaggio 17 ricevuto fuori sequenza (o in ritardo, anche se allinterno degli SLA)
segnalare il mancato rispetto della sequenza di invio o la mancata ricezione del messaggio 17 al
Performance Management


4.3 CASI SPECI FI CI DI ERRORE

4.3.1 File non trovato

Nel caso in cui la Banca Destinataria non riesca a recuperare il file referenziato dal messaggio, dovr:
Inviare una segnalazione alla Banca Mittente utilizzando il messaggio di avanzamento previsto (Cfr.
Punto 17 del sequence diagram)
Eseguire una segnalazione al Performance Management

In caso di evidenza di errori derivanti dallutilizzo del sincronizzatore, la Banca Destinataria dovr inoltre
provvedere a contattare la SIA per definire le modalit di risoluzione del problema.


4.3.2 Non omogeneit dei supporti logici

Nel caso in cui la Banca Destinataria rilevi supporti logici non omogenei, la richiesta di Servizio deve essere
considerata come non completa.

La Banca Destinataria dovr inviare un messaggio di stato davanzamento (cfr. punto 17 sequence diagram)
riportante lerrore Supporti non omogenei. Oltre a ci, obbligatorio, il Tavolo Operativo della Banca
Destinataria potr mettersi in comunicazione tramite canali alternativi con il Tavolo Operativo della Banca
Mittente per la gestione dellevento.

A fronte del messaggio riportante lerrore, la Banca Mittente dovr inviare nuovamente la richiesta di
servizio.


4.3.3 Supporti logici non referenziati

Nel caso in cui si rilevino incongruenze tra le referenze allinterno del messaggio ed i supporti logici contenuti
nel file fisico (o viceversa), la richiesta di Servizio deve essere considerata dalla Banca Destinataria come non
completa.

In accordo alle regole di composizione del messaggio di avanzamento 17 (cfr. Par. 2.4.1), la Banca
Destinataria dovr inviare un messaggio di stato davanzamento (cfr. punto 17 sequence diagram) riportante
lerrore/i:
- Supporto logico non presente nel file unitamente allindicazione del supporto logico referenziato
allinterno del messaggio, ma non presente nel file fisico;
- Supporto logico non presente nel messaggio XML unitamente allindicazione del supporto logico
presente nel file fisico, ma non referenziato allinterno del messaggio XML.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
30/ 59



Oltre a questa modalit, obbligatoria, il Tavolo Operativo del Destinatario potr mettersi in comunicazione
tramite canali alternativi con il Tavolo Operativo del Mittente per la gestione dellevento.
A fronte del messaggio riportante lerrore, la Banca Mittente dovr inviare nuovamente la richiesta di
servizio.


4.3.4 Errori di diagnostica applicativa su alcuni supporti logici

Nel caso in cui si rilevino errori su alcuni supporti logici contenuti nel file fisico durante la fase di diagnostica
applicativa dei supporti logici (cfr. punto 18 sequence diagram), la richiesta di Servizio verr comunque
processata dalla Banca Destinataria.

In particolare, la Banca Destinataria proseguir lelaborazione per i supporti logici corretti, segnalando quelli
diagnosticati correttamente e quelli su cui sono stati rilevati errori (+ dettagli sullerrore Cfr. struttura
messaggio davanzamento).


4.4 CASI GENERALI DI ERRORE

4.4.1 Non univocit della correlazione file-messaggio

Nel caso di correlazione file-messaggio non univoca (es. duplicazione IUF), la richiesta di Servizio deve
essere considerata dalla Banca Destinataria come non completa.
La Banca Destinataria dovr inviare un messaggio derrore general purpose prevedendo un codice derrore
specifico Correlazione file-messaggio non univoca. Oltre a ci, obbligatorio, il Tavolo Operativo della Banca
Destinataria potr mettersi in comunicazione tramite canali alternativi con il Tavolo Operativo della Banca
Mittente per la gestione dellevento.
A fronte del messaggio riportante lerrore, la Banca Mittente dovr inviare nuovamente la richiesta di
servizio.


4.4.2 Messaggio ricevuto illeggibile

Nel caso in cui il messaggio ricevuto risultasse illeggibile, la Banca Destinataria dovr generare un messaggio
derrore general purpose (Cfr. Doc. STPG-MO-001 Nuovi Servizi Parte Generale per la descrizione della
struttura del messaggio) prevedendo un codice derrore specifico e inserendo le informazioni ricavabili dalla
Rete Logica:
- mittente fisico
- destinatario fisico
- UDR (User Data Remote)


4.4.3 Supporti logici duplicati

Nel caso in cui la Banca Destinataria rilevi un supporto logico duplicato (secondo la chiave di univocit
costituita dai campi: nome supporto, tipo supporto, data creazione, mittente e destinatario), dovr trattare il
primo e scartare il secondo, indipendentemente dal fatto siano contenuti in file fisici differenti.


Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
31/ 59


4.4.4 Incoerenza Nome servizio e Tipologia flusso nel messaggio XML

Nel caso di incoerenza tra tag Nome servizio (cfr. Header di Tratta e Header di Servizio es. PORTING-
PC) e tag Tipologia flusso (es. PC) allinterno del Body di Servizio, la Banca Destinataria dovr
generare un messaggio derrore general purpose prevedendo un codice derrore specifico Incoerenza tra
le informazioni presenti nel messaggio XML.
A fronte del messaggio riportante lerrore, la Banca Mittente dovr inviare nuovamente la richiesta di
servizio.


4.4.5 Mancata corrispondenza nel 1 messaggio di avanzamento

Nel caso in cui le informazioni riportate nel messaggio 17 (cfr. sequence diagram) non corrispondano con
quelle indicati nel messaggio di richiesta (es. campo Nome file errato, Tipologia flusso non
corrispondente - cfr. punto 12 sequence diagram), la Banca Mittente (cfr. par. 2.2.1 Attori identificati)
dovr:
scartare il messaggio 17 inviato dalla Banca Destinataria
inviare una segnalazione specifica al Tavolo Operativo
attendere il messaggio 17 corretto (nel caso in cui il messaggio 17 corretto non venga inviato, ma
venga inviato il messaggio 20 corretto, il workflow viene comunque chiuso in base alle informazioni
contenute nel messaggio 20 cfr. Par. 4.2).


4.4.6 Mancata corrispondenza nel 2 messaggio di avanzamento

Nel caso in cui i supporti logici referenziati nel messaggio 20 (cfr. sequence diagram) non siano in
corrispondenza 1:1 con quelli indicati nel messaggio di richiesta (cfr. punto 12 sequence diagram), la Banca
Mittente (cfr. par. 2.2.1 Attori identificati) dovr:
scartare il messaggio 20 inviato dalla Banca Destinataria
inviare una segnalazione specifica al Tavolo Operativo
attendere il messaggio 20 corretto per la chiusura del workflow applicativo (nel caso in cui il
messaggio 20 corretto non venga inviato, il workflow viene comunque chiuso dopo 5 giorni
lavorativi)

Si precisa che nel messaggio 20 i supporti logici referenziati possono essere inseriti in un ordine differente
rispetto a quello seguito nella richiesta di servizio corrispondente.

4.5 RECUPERO DEI FLUSSI I N CASO DI ERRORE

4.5.1 Errore imputabile al soggetto ricevente

Nel caso in cui il Soggetto destinatario di una richiesta di servizio, a fronte della ricezione di un flusso
corretto, lo considera errato a causa di un proprio errore applicativo, possono aversi tre scenari nei quali il
ricevente:

1. chiude il workflow tramite l'invio di un messaggio di errore general purpose
2. risponde con un primo messaggio di stato avanzamento (msg 17) KO
3. risponde con un secondo messaggio di stato avanzamento (msg 20) KO per un errore di anagrafica
o diagnostica

I tre diversi scenari sono accomunati dal fatto che il ricevente ha in ogni caso a disposizione il flusso corretto
e pu pertanto procedere al suo recupero.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
32/ 59



In questi casi il recupero dei supporti logici rimane in carico, salvo diverso accordo tra le parti, al ricevente,
ovvero all'attore che ha commesso l'errore.

Il recupero deve comunque essere frutto di una azione congiunta tra le parti secondo le modalit operative
di seguito illustrate in dipendenza del soggetto che per primo rileva l'errore.

Nel caso in cui lanomalia venga inizialmente rilevata dal ricevente, lo stesso tenuto ad informare la
controparte, tramite l'invio di una mail al Tavolo Operativo ed in tempi compatibili con i livelli di servizio
associati all'erogazione del servizio oggetto di errore. In ogni caso il processo di gestione
(recupero/rispedizione/blocco definitivo del flusso) dei dati deve essere preliminarmente concordato con il
mittente. Qualora il ricevente, in accordo con la controparte, proceda al recupero del flusso, deve informare
il mittente (mediante apposita mail inviata al Tavolo Operativo) circa i tempi necessari per modificare
le proprie applicazioni e sanare l'anomalia.

Se, di contro, il mittente che per primo rileva lerrore, lo stesso deve informare via mail la controparte
dell'errore riscontrato e, salvo contestazioni, pu considerare che il destinatario provveder con celerit al
recupero dei dati e alla modifica delle applicazioni.

La gestione del recupero dei flussi nella tratta tra Banca e Cliente, non rientrando nella sfera di competenza
di ACBI, non pu essere normata in sede associativa.


4.5.2 Errore imputabile al soggetto mittente

In caso in cui un workflow si chiuda con un errore imputabile al mittente, questultimo che deve procedere
al reinvio della richiesta di servizio tramite linoltro di una nuova richiesta che comporta obbligatoriamante:

- la sistemazione delle cause di scarto
- la generazione di nuovi identificativi univoci per la richiesta di servizio.

Si precisa che il Mittente non obbligato, nella rispedizione dei supporti logici corretti, a generare nuovi
identificativi univoci per i supporti logici
11
.

4.5.3 Gestione delle contestazioni

Nel caso in cui a seguito dell'interazione tra mittente e destinatario non si pervenga alla definizione delle
responsabilit, le controparti devono attivare un processo di innalzamento della contesa che porti al
coinvolgimento di ACBI.
La Segreteria Tecnica, previa analisi dellerrore riscontrato, si far carico della definizione delle responsabilit
decidendo se lerrore sia imputabile al mittente o al ricevente. Il responsabile sar quindi tenuto ad attivare il
processo di recupero previsto.

11
Il controllo di univocit degli identificativi dei supporti logici effettuato dal Ricevente solo a valle della
generazione del 2 messaggio di avanzamento (20), riportante esito positivo della diagnostica. Pertanto, un
supporto logico pu essere scartato per duplicato solo a seguito della generazione del 2 messaggio di
avanzamento (20), riportante esito positivo della diagnostica
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
33/ 59



5 Individuazione indirizzo di erogazione del Servizio Porting

Le modalit di indirizzamento dei messaggi/file sulla Nuova Architettura sono descritte nel documento
DIRECTORY-MO-001 Requisiti Directory.

Con riferimento alla struttura del Directory, si evidenzia come, esclusivamente per lindirizzamento dei flussi
Porting, gli attributi Operativit CBI e Gestione eccezioni del nodo Cliente non debbano essere controllati.

Nel seguito del paragrafo vengono tuttavia riportate considerazioni specifiche relative alle modalit/regole di
indirizzamento per la veicolazione degli attuali tracciati sulla Nuova Architettura (Porting).

A riguardo, ciascuna Banca dovr esporre nel Directory i servizi porting nello spazio dei nomi registrati da
ACBI in appositi nodi di quarto livello, come di seguito indicato:

Per i servizi esposti nel ruolo di Banca Passiva

i nodi relativi ai servizi esposti sono riportati sotto il nodo di terzo livello ou=servizi non profilati;
i nomi dei Servizi da utilizzare (Cfr. blocco Info sul servizio dellHeader E2E) sono definiti in base
alla tipologia di supporto logico veicolato, come indicato nella tabella seguente:

Nome Servizio cn=.. Descrizione
PORTING-IR R.I.D.
PORTING-IM M.AV
PORTING-IB Ri.Ba
PORTING-AL Allineamento Elettronico Archivi R.I.D.
PORTING-PC Pagamento Italia
PORTING-PE Bonifico Estero
PORTING-AP Pagamento Effetti
PORTING-AI Avviso Impagati
PORTING-AB Pagamento Bollettino Bancario
PORTING-SL-D Struttura Libera da Utente (Dispositiva)
PORTING-F4 Pagamento Deleghe F24
PORTING-I4 Pagamento Deleghe F24 Internet
PORTING-R4 Revoca Deleghe F24


Per i servizi esposti nel ruolo di Banca Proponente

i nodi relativi ai servizi esposti sono riportati sotto i nodi di terzo livello relativi ai "servizi profilati",
con i nomi dei profili definiti ed associati ai singoli nodi Azienda;
i nomi dei Servizi da utilizzare (Cfr. blocco Info sul servizio dellHeader E2E) sono definiti in base
alla tipologia di supporto logico veicolato, come indicato nella tabella seguente:


Nome Servizio cn=.. Descrizione
PORTING-EIR Esito R.I.D.
PORTING-EI M Esito M.AV
PORTING-EI B Esito Ri.Ba
PORTING-EAL Esito Allineamento Elettronico Archivi R.I.D.
PORTING-BB Bollettino Bancario
PORTING-EP Esito di pagamento
PORTING-AV Avvisatura Effetti
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
34/ 59


PORTING-RH Rendicontazione saldi e movimenti di c/c
PORTING-RA Rendicontazione conti anticipi
PORTING-EC Estratto conto periodico
PORTING-DT Dossier Titoli
PORTING-RP Rendicontazione di Portafoglio
PORTING-SL-I Struttura Libera da Banca (Informativa)
PORTING-A4 Accettazione/Rifiuti Deleghe F24
PORTING-Q4 Quietanza Deleghe F24


Si evidenzia come, nel caso di flussi in cui sia presente il qualificatore Marketplace, lindirizzamento si
differenzia a seconda che le disposizioni originarie siano di pagamento o di incasso. In particolare:

esito disposizioni di pagamento (es. PORTING-EP): la Banca Passiva invia lesito verso la
Banca Gateway e lindirizzo di Rete Logica a cui inviare lesito viene trovato consultando il Directory
nel ramo dei servizi della Banca Gateway, sotto il profilo specifico identificato dal Codice del
Marketplace e presente nellapposito campo contenuto nei supporti logici con le disposizioni di
pagamento originarie. Tale codice altres presente allinterno dei supporti logici di esito (record 10,
pos. 109-113). Ogni Banca Gateway ha infatti lobbligo di esporre sul Directory uno specifico profilo
per ogni marketplace servito, indicando nel nome del profilo il codice assegnato al marketplace
stesso. La stringa identificativa del profilo servizio fatta nel seguente modo: PROFILO
MARKETPLACE XXXXX dove XXXXX rappresenta il codice assegnato al MP
12
(cfr doc DIRECTORY-PO-
001).

esito disposizioni di incasso (es. PORTING-EIR): la Banca Passiva invia lesito verso la
Banca Proponente e lindirizzamento del flusso di esito viene risolto consultando il Directory nel ramo
dei servizi della Banca Proponente.

Si evidenzia come le modalit di indirizzamento sopra descritte si riferiscano soltanto agli esiti delle
richieste provenienti da Marketplace; per lindirizzamento dei messaggi di stato avanzamento si utilizza il
campo Return Address indicato nellHeader di Tratta (cfr. Par. 4.1.1 documento STPG-MO-001 - Nuovi
Servizi Parte Generale).


6 Livelli di servizio

La veicolazione dei flussi dispositivi soggetta ad un termine massimo generale di 30 minuti primi, avendo a
riferimento la tratta Banca Mittente (Banca Proponente) Banca Destinataria (Banca Passiva).
Tale termine (attuativo del comma 10.2.5 delle Norme del Servizio) calcolato avendo a riferimento i due
momenti temporali di cui ai commi 10.2.6 e 10.2.7 delle Norme del Servizio.
Si precisa al riguardo quanto segue:
1) Si definisce ricezione ai sensi del comma 10.2.6 listante in cui si verificano entrambe le condizioni
seguenti:
- il flusso inviato dal cliente a completa disposizione della Banca Proponente;
- il cliente ha autorizzato linoltro del flusso verso la Banca Passiva.
Si osserva che la Banca Proponente tenuta a comunicare listante di effettiva disponibilit dei flussi
autorizzati allinvio, prima che sugli stessi vengano effettuate eventuali elaborazioni.
2) La messa a disposizione della Banca Passiva di cui al comma 10.2.7 prescinde dallutilizzo della
Rete CBI per la veicolazione dei flussi tra le due banche Mittente e Destinataria, per cui la previsione
generale di tale comma valida anche nel caso di flussi destinati ad una Banca Passiva attestata sul

12
Si precisa che non consentito definire codici marketplace contenenti uno o pi caratteri pari a blank.
ATTENZIONE: quanto evidenziato in giallo in questo
paragrafo entra in vigore il 1 novembre 2010 (cfr. tabella
delle revisioni)
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
35/ 59


medesimo soggetto tecnico di cui si avvale la Banca Proponente e nel caso di coincidenza tra Banca
Proponente e Banca Passiva.
3) Il termine temporale massimo altres calcolato avendo a riguardo leffettiva disponibilit del
Servizio, ovvero al netto degli orari ufficiali di chiusura e/o di eventi eccezionali e/o cause di forza
maggiore.

La giornata applicativa per il servizio Porting rappresenta lorologio di riferimento per la misura degli SLA: la
trasmissione e la ricezione dei flussi va dal Luned al Sabato dalle ore 01:00 alle ore 23:00, eccetto festivit
nazionali previste.

I livelli di servizio per il Servizio Porting sono stati definiti partendo dalla individuazione dei punti di
rilevazione delimitanti linizio e/o fine di un intervallo temporale soggetto a controllo.
Si precisa come tali punti di rilevazione coincidano solo con un sottoinsieme di quanto richiesto alle Banche,
in termini di logging, a supporto del performance management e della governance.

La figura seguente - a partire dalla sequenza di attivit in carico alla Banca Destinataria ed esposta al
Capitolo 2.3 del presente documento - evidenzia i punti di rilevazione identificati.

1: Ricezione
messaggio+file
1: Ricezione
messaggio+file
2: Diagnostica messaggio
XML
2: Diagnostica messaggio
XML
3: Verifica omogeneit file
e coerenza file-messaggio
Errori rilevati
4: Invio messaggio di errore 4: Invio messaggio di errore
SI
NO
6: Diagnostica supporti
logici (diagnostica
attuale formale)
6: Diagnostica supporti
logici (diagnostica
attuale formale)
7: Predisposizione stato
avanzamento/ errori
rilevati
7: Predisposizione stato
avanzamento/ errori
rilevati
8: Invio messaggio
stato avanzamento/
errori rilevati
8: Invio messaggio
stato avanzamento/
errori rilevati
5: Invio messaggio
stato avanzamento
5: Invio messaggio
stato avanzamento
1
2
3


Figura 7 Punti di rilevazione Banca Destinataria

In maggior dettaglio, i punti di rilevazione sono cos definiti:
1) Completamento, con esito positivo, della chiamata receive alla Rete Logica per la ricezione di
un file+messaggio;
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
36/ 59


2) Presa in carico, con esito positivo, da parte della Rete Logica della chiamata send per linvio di
un messaggio;
3) Presa in carico, con esito positivo, da parte della Rete Logica della chiamata send per linvio di
un messaggio.

Le figura seguente mostra - a partire dalla sequenza di attivit in carico alla Banca Destinataria ed esposta al
Capitolo 2.3 del presente documento - gli intervalli significativi per le rilevazioni temporali e la
denominazione ad essi associata.

1: Ricezione
messaggio+file
1: Ricezione
messaggio+file
2: Diagnostica messaggio
XML
2: Diagnostica messaggio
XML
3: Verifica omogeneit file
e coerenza file-messaggio
Errori rilevati
4: Invio messaggio di errore 4: Invio messaggio di errore
SI
NO
6: Diagnostica supporti
logici (diagnostica
attuale formale)
6: Diagnostica supporti
logici (diagnostica
attuale formale)
7: Predisposizione stato
avanzamento/ errori
rilevati
7: Predisposizione stato
avanzamento/ errori
rilevati
8: Invio messaggio
stato avanzamento/
errori rilevati
8: Invio messaggio
stato avanzamento/
errori rilevati
5: Invio messaggio
stato avanzamento
5: Invio messaggio
stato avanzamento
T1 T2


Figura 8 Intervalli temporali soggetti a SLA Banca Destinataria

Per ci che riguarda i flussi di carattere dispositivo inviati alla Banca Destinataria si fissato il seguente
intervallo massimo:
- T2 = entro 1 ora.

Similmente, per quanto riguarda i flussi informativi, si sono definiti i seguenti intervalli temporali massimi:
- T1 = entro 1 ora;
- T2 = entro 2 ore.

Gli intervalli sopra definiti hanno validit fino alla fine del Periodo di Transizione
13
, in seguito potranno essere
ricalibrati subendo riduzioni.

13
Cfr. Circolare CBI 4/2005 del 16 giugno 2005.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
37/ 59


La figura seguente - a partire dalla sequenza di attivit in carico alla Banca Mittente ed esposta al Capitolo
2.3 del presente documento - evidenzia i punti di rilevazione identificati.

1: Ricezione
messaggio+file
1: Ricezione
messaggio+file
2: Diagnostica messaggio
XML
2: Diagnostica messaggio
XML
3: Verifica omogeneit file
e coerenza file-messaggio
Errori rilevati 4: Invio messaggio di errore 4: Invio messaggio di errore
SI
NO
6: Diagnostica supporti
logici (diagnostica
attuale formale)
6: Diagnostica supporti
logici (diagnostica
attuale formale)
7: Predisposizione stato
avanzamento/ errori
rilevati
7: Predisposizione stato
avanzamento/ errori
rilevati
8: Invio messaggio
stato avanzamento/
errori rilevati
8: Invio messaggio
stato avanzamento/
errori rilevati
5: Invio messaggio
stato avanzamento
5: Invio messaggio
stato avanzamento
4
5
6


Figura 9 Punti di rilevazione Banca Mittente

In maggior dettaglio, i punti di rilevazione sono cos definiti:
4) Ricezione della notify di Rete Logica a seguito di richiesta di send, con esito positivo, di
file+messaggio;
5) Completamento, con esito positivo, della receive di Rete Logica per la ricezione di un
messaggio;
6) Completamento, con esito positivo, della receive di Rete Logica per la ricezione di un
messaggio.

La figura seguente mostra - a partire dalla sequenza di attivit in carico alla Banca Mittente ed esposta al
Capitolo 2.3 del presente documento - gli intervalli significativi per le rilevazioni temporali e la
denominazione ad essi associata.

Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
38/ 59


3a.Predisposizione e
diagnostica file
1.Predisposizione
supporti logici
1.Predisposizione
supporti logici
2.Diagnostica supporti logici
(attuale diagnostica formale)
3b.Costruzione del
messaggio XML (contiene i
riferimenti applicativi al file)
5.Spedizione file+messaggio
6.Ricezione dalla rete di ok di
trasmissione file+messaggio
3c.Diagnostica messaggio
XML
7.Attesa risposta applicativa stato
avanzamento/errori rilevati
4.Verifica coerenza file-
messaggio
8.Attesa risposta applicativa stato
avanzamento/errori rilevati
T4 T5
T4


Figura 10 Intervalli temporali soggetti a SLA Banca Mittente

Per ci che riguarda i flussi di carattere dispositivo inviati dalla Banca Mittente si sono fissati i seguenti
intervalli massimi:
- T5 = T2 (a meno di tolleranze dovute ai tempi di trasporto sulla Rete Logica).

Similmente, per quanto riguarda i flussi informativi, si sono definiti i seguenti intervalli temporali massimi:
- T4 = entro le ore 05:00 (GMT+1) presso il Cliente;
- T4 = T1 (a meno di tolleranze dovute ai tempi di trasporto sulla Rete Logica);
- T5 = T2 (a meno di tolleranze dovute ai tempi di trasporto sulla Rete Logica).

Gli intervalli sopra definiti hanno validit fino alla fine del Periodo di Transizione, in seguito verranno
ricalibrati subendo riduzioni.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
39/ 59



7 Firma digitale

Per le specifiche tecniche da adottare per lutilizzo della Firma digitale si faccia riferimento al documento
tecnico FIRMA-MO-001.

7.1 CONTROLLO DEL MI TTENTE FI SI CO DEI FLUSSI FI RMATI

Limmissione sulla Rete dei flussi firmati consentita ai soli mittenti fisici autorizzati dal CBI (cfr. doc. FIRMA-
MO-001).
In fase di ricezione di un flusso firmato deve pertanto essere effettuato il controllo del mittente fisico,
producendo apposito scarto se il CUC dello stesso non rientra nella lista dei soggetti abilitati allutilizzo della
tipologia di firma rilevata.
Leventuale scarto deve essere effettuato dalla Banca destinataria a livello di intero flusso utilizzando il primo
messaggio di stato avanzamento (messaggio 17). Il body di servizio di tale messaggio deve essere
strutturato cos come illustrato nella figura seguente:

Info file
Tipologia supporti logici
Nome file
(0..n) Info supporto
Stato invio
Stato avanzamento
Codice derrore
Body di servizio: stato
avanzamento
Info su diagnostico
Banca utente
Versione diagnostico utilizzata
Soggetto verificatore
Data e ora diagnostica
Tipo messaggio
ERRR
Blocco assente
1
PF5


Le regole di composizione del primo messaggio di stato avanzamento sono le seguenti:

- Campo Tipo messaggio posto al valore 1 (primo messaggio di stato avanzamento)
- Campo Stato avanzamento (presente nel blocco Stato invio) valorizzato con ERRR
- Campo Codice di errore presente e posto al valore PF5 (supporti logici firmati digitalmente inviati
da un mittente fisico non autorizzato)
- Blocco Info supporto assente


7.2 CONTROLLO DI OMOGENEI T PER APPOSI ZIONE DELLA FI RMA DI GI TALE

Coerentemente a quanto definito nel paragrafo 2.4.1 del presente documento, lapposizione della firma
digitale e la tipologia di firma utilizzata rappresentano criteri di omogeneit per la composizione di tutti i
messaggi di richiesta di servizio.
Per ogni richiesta caratterizzata da pi supporti logici, il riferimento per la verifica di omogeneit
rappresentato dal primo supporto logico: se firmato lo devono essere tutti i successivi con la stessa
tipologia di firma, se non firmato la firma non pu essere apposta su alcun supporto logico seguente.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
40/ 59


Qualora il criterio di omogeneit non venga rispettato lo scarto deve essere effettuato dalla Banca
destinataria a livello di intero flusso utilizzando il primo messaggio di stato avanzamento (messaggio 17) il
cui body di servizio deve essere strutturato cos come illustrato nella figura seguente:

Info file
Tipologia supporti logici
Nome file
(0..n) Info supporto
Codice SIA Azienda di riferimento
ABI Banca di riferimento
Data creazione
Nome supporto
Stato invio
Stato avanzamento
Codice derrore
Stato invio
Stato avanzamento
Codice derrore
Stato invio
Stato avanzamento
Codice derrore
Body di servizio: stato
avanzamento
Info su diagnostico
Banca utente
Versione diagnostico utilizzata
Soggetto verificatore
Data e ora diagnostica
Dettagli errore (0..3)
Tipo messaggio
ERRR
ERRR
PSL5
1
PF5
Blocco assente
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
41/ 59


Si precisa come il blocco Info supporto debba essere valorizzato solo per il primo supporto logico che viola
il criterio di omogeneit dettato dal primo supporto logico contenuto nel file.
Le regole di composizione del primo messaggio di stato avanzamento possono pertanto essere sintetizzate
nel modo seguente:

- Campo Tipo messaggio posto al valore 1 (primo messaggio di stato avanzamento)
- Campo Stato avanzamento (presente nel blocco Stato invio) valorizzato con ERRR
- Campo Codice di errore presente e posto al valore PF5 (supporti logici non omogenei)
- Blocco Info supporto riferito al primo supporto logico non omogeneo valorizzato seguente modo:
- Campo Stato avanzamento (presente nel blocco Stato invio) pari a ERRR
- Campo Codice di errore presente e posto al valore PSL5
- Blocco Dettagli errore assente

7.3 VERI FI CA DELLA FI RMA SUI SINGOLI SUPPORTI LOGI CI

Per ogni supporto logico firmato la Banca destinataria tenuta ad effettuare i due seguenti controlli,
aggiuntivi rispetto ai diagnostica applicata su tutti i flussi:

- verifica che la modalit di apposizione firma dichiarata nel campo Tipo di firma sia ammessa per i
Servizi Porting (cfr. doc. FIRMA-MO-001).
- verifica che la modalit di apposizione firma dichiarata nel campo Tipo di firma sia la stessa utilizzata
nella busta di pertinenza).
- verifica di correttezza di ogni busta di firma. Il campo <Sgnt> codificato in base64 deve rappresentare
una busta leggibile, ovvero conforme alle specifiche del tipo di firma utilizzata
- verifica della firma secondo le modalit previste (cfr. documento FIRMA-MO-001).

Si osserva che non fissata alcuna sequenza predefinita tra controlli di diagnostica ordinari e controlli sulla
firma digitale. I controlli sulla firma possono pertanto essere preposti o posposti a quelli di diagnostica dei
supporti logici.
Qualora almeno uno di tali controlli fallisca, lo scarto del singolo supporto logico deve essere effettuato
utilizzando lapposito codice di errore disponibile nellappendice C del documento CBI-STD-001.

Con riferimento al secondo messaggio di stato avanzamento, le regole di composizione del blocco Info
supporto, in corrispondenza ad ogni supporto per il quale viene rilevato un errore di verifica della firma
digitale possono pertanto essere sintetizzate come segue:

- Campo Stato avanzamento (presente nel blocco Stato invio) valorizzato con ERRR
- Campo Codice di errore presente e posto al valore PSL8
- Una occorrenza del blocco Dettagli errore con i campi valorizzati nel modo seguente:
- Campo Numero disposizione posto al valore 0 (errore generalizzato su tutto il supporto)
- Campo Tipo record pari alla tipologia del supporto riportata nel record di testa (es. PC)
- Campo Posizione inizio posta a 1
- Campo Posizione fine posta a 120
- Campo Codice di errore pari al valore 100 (cfr. doc. CBI-STD-001, Appendice C)

Possono essere presenti eventuali altre occorrenza del blocco Dettagli errore qualora si rilevino anche
errori legati alla diagnostica del supporto logico.

Quanto appena espresso viene illustrato nella figura seguente:


Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
42/ 59


N.B. La valorizzazione indicata da intendersi in corrispondenza ad ogni supporto per il quale viene rilevato
lerrore sulla firma. Possono inoltre essere presenti altre occorrenza del blocco Dettagli errore qualora si
rilevino anche errori legati alla diagnostica del supporto logico.
Info file
Tipologia supporti logici
Nome file
(0..n) Info supporto
Codice SIA Azienda di riferimento
ABI Banca di riferimento
Data creazione
Nome supporto
Stato invio
Stato avanzamento
Codice derrore
Stato invio
Stato avanzamento
Codice derrore
Stato invio
Stato avanzamento
Codice derrore
Body di servizio: stato
avanzamento
Info su diagnostico
Banca utente
Versione diagnostico utilizzata
Soggetto verificatore
Data e ora diagnostica
Dettagli errore
Numero disposizione/rendicontazione
Tipo record
Posizione inizio
Posizione fine
Codice derrore
(0..3)
Tipo messaggio
RCVD
0
Record di testa
1
120
100
ERRR
PSL8
2
Valori riferiti ai
dettagli errore su
firma digitale



Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
43/ 59



8 Allegati

8.1 ALLEGATO A CRI TERI DI IDENTI FICAZI ONE UNI VOCA DI MESSAGGIO E FI LE

I criteri per lidentificazione univoca del file e del relativo messaggio sono quelli descritti nel documento
STPG-MO-001 Nuovi Servizi - Parte Generale.


8.2 ALLEGATO B - POPOLAMENTO DEL DIRECTORY A FI NI DI PORTI NG

Al fine di consentire leffettiva attivazione del servizio Porting, le Banche dovranno completare le procedure
operative e propedeutiche allassegnazione dellIdentificativo Univoco CBI (CUC), unitamente a fornire gli
elenchi relativi ai Codici Azienda (Codice SIA) censite in CBI e delle relative Banche Proponenti.
Il dettaglio di tali procedure (attori coinvolti, attivit, tempistiche) descritto nel documento CBI
Assegnazione CUC attivit propedeutiche, cui si rimanda per approfondimenti.


8.3 ALLEGATO C STRUTTURA DEI MESSAGGI XML DI NVI O FI LE/ STATO DAVANZAMENTO
8.3.1 Considerazioni generali

La messaggistica XML a supporto della funzione di Porting sviluppata in accordo con le linee guida
utilizzate per la costruzione della messaggistica per le nuove funzioni CBI. Sono pertanto previsti i seguenti
blocchi di informazione principali:
- Header di tratta;
- Header E2E di Servizio;
- Body di servizio.

Per i dettagli sulla struttura dellHeader di tratta e dellHeader E2E di Servizio, si faccia riferimento agli Excel
STPG-ST-001 Controlli Header di tratta e STPG-ST-002 Controllo Header E2E e agli Schemi XSD
CBIHdrTrt e CBIHdrSrv, contenuti nella Parte Generale.

Per i dettagli sulla struttura del Body di servizio, si faccia invece riferimento agli Excel STAA-ST-001 Invio
file e STAA-ST-002 stato avanzam e agli Schemi XSD CBIPrtAdvSts e CBIPrtSrvRq, rispettivamente per
il messaggio XML accompagnatorio del file di richiesta e per il messaggio di stato avanzamento (cfr. punti 17
e 20 sequence diagram).

8.3.2 Struttura
8.3.2.1 Header di tratta

Per le specifiche del blocco dinformazioni Header di tratta si faccia riferimento al documento STPG-MO-
001 Nuovi Servizi - Parte Generale.

8.3.2.2 Header di Servizio

Per le specifiche del blocco dinformazioni Header di Servizio si faccia riferimento al documento STPG-MO-
001 Nuovi Servizi - Parte Generale.

Ai fini del Servizio PORTING ATTUALI TRACCIATI, nei blocchi Mittente e Destinatario dellHeader E2E di
Servizio devono essere indicati solo gli Identificativi CBI della Banca Mittente e di quella Destinataria (tag
Identificativo univoco Mittente/Destinatario).
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
44/ 59



8.3.2.3 Body di Servizio
8.3.2.3.1 Struttura del messaggio XML di Richiesta di servizio

La struttura logica del body di servizio del messaggio di Richiesta di servizio (ossia del messaggio XML di
accompagnamento allinvio del file) caratterizzata da quattro blocchi principali:

Blocco Info file: contiene le informazioni identificative del file, incluso il nome file;
Blocco Info diagnostico: contiene le informazioni sul diagnostico utilizzato per la verifica del flusso;
Blocco Info supporto: contiene il dettaglio delle informazioni sui supporti logici contenuti allinterno
del file;
Blocco Firma: se presente contiene le informazioni sulla firma digitale apposta sul singolo supporto
logico.

Header E2E di servizio
Header di tratta
Messaggio XML
Info file
Tipologia supporti logici
Nome file
(1..n) Info supporto
Codice SIA Azienda di riferimento
ABI Banca di riferimento
Data creazione
Nome supporto
Info su diagnostico
Banca utente
Versione diagnostico utilizzata
Soggetto verificatore
Data e ora diagnostica
Body di servizio
Firma supporto
Tipo firma
Piattaforma di riferimento
Riferimento temporale
Firma
(0..10)




Descrizione dello schema XML

a) Info file <FleInfo>
Presenza: [1..1]
Definizione: Blocco obbligatorio contenente le informazioni generali sul file associato al messaggio.
Tipo: FileInformation


Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
45/ 59


Il blocco Info file composto dai seguenti elementi:

a.1. Tipologia flusso
a.2. Nome file

a.1. Tipologia flusso <FlwTyp>
Presenza: [1..1]
Definizione: Descrizione della tipologia di supporti logici inviati cos come classificati negli
attuali standard tecnici CBI (es. PC, RH, etc.)
Tipo: FlowType (Max35Text)

a.2. Nome file <FleNm>
Presenza: [1..1]
Definizione: Contiene lidentificativo univoco del file inviato IUF (fare riferimento al
documento STPG-MO-001 Nuovi Servizi - Parte Generale)
Tipo: FileIdentifier

b) Info su diagnostica <DiagInfo>
Presenza: [1..1]
Definizione: Blocco obbligatorio che contiene le informazioni sul diagnostico e sulla diagnostica
eseguita.
Tipo: DiagnosticFileInformation

Il blocco composto dai seguenti elementi:

b.1. Banca utente
b.2. Versione diagnostico utilizzata
b.3. Soggetto verificatore
b.4. Data diagnostica

b.1. Banca utente <UsrBnk>
Presenza: [0..1]
Definizione: CUC della Banca owner della diagnostica
Tipo: CBIIdentifier

b.2. Versione diagnostico utilizzata <DiagVers>
Presenza: [1..1]
Definizione: Versione del kit di certificazione pubblicato da ACBI per cui il diagnostico ha
effettuato la certificazione
Tipo: Max35Text

b.3. Soggetto verificatore <ChkSbj>
Presenza: [1..1]
Definizione: CUC del soggetto che effettua la diagnostica (es. Banca, STD o GPA)
Tipo: CBIIdentifier

b.4. Data diagnostica <ChkDt>
Presenza: [1..1]
Definizione: Data in cui stata effettuata la diagnostica
Tipo: ISODate


c) Info supporto <SppInfo>
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
46/ 59


Presenza: [1..n]
Definizione: Blocco obbligatorio contenente le informazioni sui supporti logici contenuti nel file inviato.
Tipo: SupportInformation
Il blocco Info supporto composto dai seguenti elementi:

c.1. Codice SIA Azienda di riferimento
c.2. ABI Banca di riferimento
c.3. Data creazione
c.4. Nome supporto
c.5. Firma supporto

c.1. Codice SIA Azienda di riferimento <SIACd>
Presenza: [1..1]
Definizione: Campo che identifica il Codice SIA dellazienda cliente di riferimento mittente
della disposizione nel caso di flussi dispositivi o destinataria nel caso di flussi di esito o
informativi; quello riportato nel Record di testa del supporto logico.
Tipo: SIAIdentifier (Alfanumerico)

c.2. ABI Banca di riferimento <ABICd >
Presenza: [1..1]
Definizione: Codice ABI della Banca di riferimento destinataria del supporto logico nel caso
di flussi dispositivi; mittente nel caso di flussi informativi o di esito; quello riportato nel
Record di testa del supporto logico.
Tipo: ABIIdentifier (Numerico)

c.3. Data creazione <CreDt>
Presenza: [1..1]
Definizione: Data di creazione del supporto logico.
Tipo: ISODate
Note: ottenuto dal corrispondente campo nel record di testa/record di coda attraverso
una conversione di tipo applicativo. Nonostante le specifiche W3C consentano di indicare
anche il Time Zone, si precisa che tale dettaglio non deve essere inserito. Infatti, poich tale
campo viene utilizzato quale chiave di correlazione tra supporti referenziati nelle richieste di
servizio e relativi stati di avanzamento, leventuale presenza del Time Zone potrebbe creare
problemi di gestione del workflow in corrispondenza del cambio di orario (solare
legale).

c.4. Nome supporto <SppNm>
Presenza: [1..1]
Definizione: Nome del supporto logico.
Tipo: Max20Text

c.5. Firma supporto <SgnInfo>
Presenza: [0..10]
Definizione: Blocco facoltativo che contiene le informazioni sulleventuale firma digitale
applicata al supporto.
Il blocco <SgnInfo> composto dai seguenti elementi:

c.5.1. Tipo firma
c.5.2. Piattaforma di riferimento
c.5.4. Riferimento temporale
c.5.5. Firma
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
47/ 59



c.5.1. Tipo firma <SgnTyp>
Presenza: [1..1]
Definizione: Valore codificato che descrive il tipo di firma applicata al supporto.
Pu assumere i seguenti valori definiti nel documento FIRMA MO-001.
Tipo: SignatureType

c.5.2. Piattaforma di riferimento <RefPlt>
Presenza: [1..1]
Definizione: Descrizione della piattaforma utilizzata per la generazione della firma.
Pu assumere i valori definiti nel documento FIRMAMO-001.
Tipo: ReferencePlatform

c.5.3. Riferimento temporale <DtRef>
Presenza: [1..1]
Definizione: Istante temporale in cui sono state completate le verifiche sulla firma e sul
certificato utilizzato per la firma da parte della Banca Proponente (cfr. FIRMA-MO-001).
Tipo: ISODateTime

c.5.4. Firma <Sgnt>
Presenza: [1..1]
Definizione: Tag che contiene la firma (costruita in accordo a quanto specificato dal tag
Tipo firma).
Tipo: P7M.

Nota: In questo tag dovr essere inserita, codificata in Base64, la busta generata dal
processo di firma. Il tipo dato riportato nello schema XML per il tipo di dato P7M
xs:base64Binary .


Controlli

Per il dettaglio su Facoltativit/Obbligatoriet e sui controlli (Formali, Validit etc.) da applicare al messaggio
XML si rimanda al documento Excel STAA-ST-001.


8.3.2.3.2 Struttura del messaggio Stato davanzamento

La struttura logica del body di servizio del messaggio di stato davanzamento caratterizzata da cinque
blocchi principali:
Blocco Info file: contiene le informazioni identificative del file, ed il relativo stato di avanzamento
(o eventuali codici derrore);
Blocco Info diagnostico: contiene le informazioni sul diagnostico utilizzato per la verifica del
messaggio e del contenuto applicativo del file;
Blocco Info supporto: contiene il dettaglio delle informazioni sui supporti logici contenuti allinterno
del file ed i relativi stati di avanzamento (o eventuali codici derrore);
Blocco Stato invio: contiene le informazioni sullo stato di avanzamento e/o errori rilevati;
Blocco Dettagli errore: contiene i dettagli degli errori rilevati sul supporto logico.

Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
48/ 59


Info file
Tipologia supporti logici
Nome file
(0..n)
Info supporto
Codice SIA Azienda di riferimento
ABI Banca di riferimento
Data creazione
Nome supporto
Header E2E di servizio
Header di tratta
Messaggio XML
Stato invio
Stato avanzamento
Codice derrore
Stato invio
Stato avanzamento
Codice derrore
Stato invio
Stato avanzamento
Codice derrore
Body di servizio: stato
avanzamento
Info su diagnostico
Banca utente
Versione diagnostico utilizzata
Soggetto verificatore
Data e ora diagnostica
Dettagli errore
Numero disposizione/rendicontazione
Tipo record
Posizione inizio
Posizione fine
Codice derrore
(0..3)
Tipo messaggio


Descrizione dello schema XML

a) Tipo messaggio <MsgTyp>
Presenza: [1..1]
Definizione: Flag che indica se si tratta del 1 o del 2 messaggio di avanzamento
Tipo: MsgTypFlg1

Pu assumere i seguenti valori

Valore Descrizione
1 1 messaggio davanzamento
2 2 messaggio davanzamento


b) Info file <FleInfo>
Presenza: [1..1]
Definizione: Blocco obbligatorio contenente le informazioni generali sul file cui il messaggio di
avanzamento si riferisce.
Contiene le stesse informazioni del messaggio originario accompagnatorio del file.
Tipo: FileInformation

Il blocco Info file composto dai seguenti elementi:

Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
49/ 59


b.1. Tipologia supporti logici
b.2. Nome file
b.3. Stato invio

b.1. Tipologia supporti logici <FlwTyp>
Presenza: [1..1]
Definizione: Descrizione della tipologia di supporti logici inviati cos come classificati negli
attuali standard tecnici CBI (es. PC, RH, etc.)
Tipo: FlowType

b.2. Nome file <FleNm>
Presenza: [1..1]
Definizione: Contiene lidentificativo univoco del file inviato IUF (fare riferimento al
documento STPG-MO-001 Nuovi Servizi - Parte Generale)
Tipo: FileIdentifier

b.3. Stato invio <SendSts>
Presenza:[1..1]
Definizione: Blocco obbligatorio che contiene le informazioni sullo stato di avanzamento
dellinvio del file.
Tipo: SendingInformation1

Il blocco composto dai seguenti elementi:
b.4.1. Stato avanzamento
b.4.2. Codice derrore

b.4.1. Stato avanzamento <AdvSts>
Presenza: [1..1]
Definizione: Stato di avanzamento dellinvio del file.
Tipo: AdvancingStatusType
Pu assumere i seguenti valori:

Valore Descrizione Dettagli
RCVD Received Il file ed il messaggio XML associato sono
stati ricevuti correttamente
ERRR Errori rilevati Sono stati rilevati errori sul file o sul
messaggio XML associato (Cfr. campo
successivo per i dettagli)
<ulteriori codifiche da valutare>



b.4.2. Codice derrore <FleErrCd>
Presenza: [0..1] (diventa obbligatorio se rilevati errori)
Definizione: Codice errore durante linvio del messaggio XML e del file.
Tipo: FileErrorCode1

Pu assumere i seguenti valori:

Cod.
Err.
Descrizione Dettagli 1 msg
(Cfr.
punto 17
sequenc
2 msg
(Cfr.
punto 20
sequenc
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
50/ 59


e
diagram
)
e
diagram
)
PF1 Errore msg XML Processo di validazione del
messaggio XML non
completato; codice da
utilizzare per errori relativi
a lunghezza o formato dei
campi (tag)
X
PF2 File non trovato Messaggio XML ricevuto
correttamente ma file non
trovato, oppure nome file
errato
X
PF3 File inutilizzabile Messaggio XML ricevuto
correttamente ma file
inutilizzabile (corrotto,
illeggibile, etc.)
X
PF4 Limite massimo
supporti logici
superato
Numero di supporti logici
inclusi nel file e presenti nel
messaggio di richiesta
superiore al limite definito
X
PF5 Supporti logici
non omogenei,
non
corrispondenti,
inutilizzabili o
invio non
autorizzato
Errore sui supporti logici:
non corrispondenti a quelli
indicati nel msg XML, non
omogenei o inutilizzabili
(incompleto, corrotto,
illeggibile, etc.). Supporti
logici firmati digitalmente
inviati da un mittente fisico
non autorizzato
X
.
<ulteriori codifiche da
valutare>


Note: Un supporto logico definito come la sequenza di record che vanno dal record di
testa (compreso) fino al relativo record di coda (compreso). Un supporto logico cos
individuato definito come un supporto logico integro presente nel file.
Il file deve contenere solo supporti logici integri, senza alcun record "estraneo" tra un
supporto logico e l'altro; questo significa che dopo il record di coda di un supporto
logico integro deve essere presente il record di testa del successivo supporto logico
integro oppure la fine del file. Se durante la fase di individuazione di un supporto logico
viene incontrata la fine del file e non il record di coda del supporto logico stesso, il
supporto logico non integro.
Il file si considera integro se inizia con un supporto logico integro (il primo record del
file deve essere il record di testa del primo supporto logico) e termina con un supporto
logico integro (l'ultimo record del file deve essere il record di coda dell'ultimo supporto
logico).


c) Info su diagnostica <DiagInfo>
Presenza: [1..1]
Definizione: Blocco obbligatorio che contiene le informazioni sul diagnostico e sulla diagnostica
eseguita
Tipo: DiagnosticInformation

Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
51/ 59


Il blocco composto dai seguenti elementi:

c.1. Banca utente
c.2. Versione diagnostico utilizzata
c.3. Soggetto verificatore
c.4. Data diagnostica

c.1. Banca utente <UsrBnk>
Presenza: [0..1]
Definizione: CUC della Banca owner della diagnostica
Tipo: CBIIdentifier

c.2. Versione diagnostico utilizzata <DiagVers>
Presenza: [1..1]
Definizione: Versione del kit di certificazione pubblicato da ACBI per cui il diagnostico
ha effettuato la certificazione
Tipo: Max35Text

c.3. Soggetto verificatore <ChkSbj>
Presenza: [1..1]
Definizione: CUC del soggetto che effettua la diagnostica del messaggio e del contenuto
applicativo del file (es. Banca, STD o GPA)
Tipo: CBIIdentifier

c.4. Data diagnostica <ChkDt>
Presenza: [1..1]
Definizione: Data in cui stata effettuata la diagnostica
Tipo: ISODate

d) Info supporto <SppInfo>
Presenza: [0..n]
Definizione: Blocco contenente le informazioni sul singolo supporto logico ottenute a valle del
controllo di congruenza tra file ricevuto e messaggio accompagnatorio o a valle della diagnostica
applicativa dei supporti logici
Tipo: SupportInformation
Note: Il blocco diventa obbligatorio nel caso in cui siano disponibili le informazioni relative ai supporti
logici


Il blocco Info supporto composto dai seguenti elementi:

d.1. Codice SIA Azienda di riferimento
d.2. ABI Banca di riferimento
d.3. Data creazione
d.4. Nome supporto
d.5. Stato invio

d.1. Codice SIA Azienda di riferimento <SIACd>
Presenza: [1..1]
Definizione: Campo che identifica il Codice SIA dellazienda di riferimento; quello
riportato nel Record di testa del supporto logico cui il messaggio di avanzamento si
riferisce.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
52/ 59


Tipo: SIAIdentifier (Alfanumerico)

d.2. ABI Banca di riferimento <ABICd>
Presenza: [1..1]
Definizione: Codice ABI della Banca di riferimento; quello riportato nel Record di testa
del supporto logico cui il messaggio di avanzamento si riferisce.
Tipo: ABIIdentifier (Numeric)

d.3. Data creazione <CreDt>
Presenza: [1..1]
Definizione: Data di creazione del supporto logico cui il messaggio di avanzamento si
riferisce.
Note: Nonostante le specifiche W3C consentano di indicare anche il Time Zone, si precisa
che tale dettaglio non deve essere inserito. Infatti, poich tale campo viene utilizzato quale
chiave di correlazione tra supporti referenziati nelle richieste di servizio e relativi stati di
avanzamento, leventuale presenza del Time Zone potrebbe creare problemi di gestione del
workflow in corrispondenza del cambio di orario (solare legale).
Tipo: ISODate

d.4. Nome supporto <SppNm>
Presenza: [1..1]
Definizione: Nome del supporto logico cui il messaggio di avanzamento si riferisce.
Tipo: Max20Text

d.5. Stato invio <SendSts>
Presenza: [1..1]
Definizione: Blocco obbligatorio che contiene le informazioni sullo stato di avanzamento
del singolo supporto logico cui il messaggio di avanzamento si riferisce.
Tipo: SendingInformation2

Il blocco composto dai seguenti elementi:

d.5.1. Stato avanzamento
d.5.2. Codice derrore
d.5.3. Dettagli errore

d.5.1. Stato avanzamento <AdvSts>
Presenza: [1..1]
Definizione: Stato di avanzamento dellinvio del singolo supporto logico cui il messaggio di
avanzamento si riferisce.
Tipo: AdvancingStatusType

Pu assumere i seguenti valori:


Valore Descrizione Dettagli
ACTC AcceptedTechnica
lValidation
Diagnostica supporto logico ok
ERRR Errori rilevati Sono stati rilevati errori sul supporto logico
(Cfr. campo successivo per i dettagli)
<ulteriori codifiche da valutare>


Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
53/ 59


d.5.2. Codice derrore <LgSpErrCd>
Presenza: [0..1] (diventa obbligatorio se rilevati errori)
Definizione: Codice errore durante linvio del supporto logico.
Tipo: FileErrorCode2

Pu assumere i seguenti valori:


Cod. Err. Descrizione Dettagli 1 msg
(Cfr.
punto
17
sequen
ce
diagra
m)
2 msg
(Cfr.
punto
20
sequen
ce
diagra
m)
PSL1 Supporto non
presente nel
messaggio XML
Supporto logico presente nel
file fisico ma non dichiarato nel
messaggio XML
X
PSL2 Supporto non
presente nel file
Supporto logico dichiarato nel
messaggio XML ma non
presente nel file fisico
associato
X
PSL3 Supporto logico
non omogeneo per
tipologia flusso
Tipo supporto logico non
coerente con il tipo di flusso
X
PSL4 Supporto logico
non omogeneo per
per destinatario
Supporto logico non indirizzato
al destinatario corretto
X
PSL5 Supporto logico
non omogeneo per
applicazione firma
digitale
Supporto logico non omogeneo
per applicazione della firma
digitale
X
PSL6 Supporto logico
inutilizzabile
Supporto logico inutilizzabile
(incompleto, corrotto,
illeggibile, etc.)
X
PSL7 ABI e CUC Banca
Passiva non
coerenti
Codice ABI B. Passiva in Info
supporto e CUC B. Passiva
nellHE2E non coerenti
X
PSL8 Errori su supporto
logico
Errori sul singolo supporto
logico
X
.
<ulteriori codifiche da
valutare>



d.5.3. Dettagli errore <ErrDtl>
Presenza: [0..3] (diventa obbligatorio se rilevati errori applicativi sul singolo supporto
logico)
Definizione: Dettaglio degli errori applicativi e di diagnostica rilevati sul singolo supporto
logico.
Tipo: ErrorDetailsInformation

Il blocco dettagli errore composto dai seguenti elementi:
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
54/ 59



d.5.3.1. Numero disposizione
d.5.3.2. Tipo record
d.5.3.3. Posizione inizio
d.5.3.4. Posizione fine
d.5.3.5. Codice derrore


d.5.3.1. Numero disposizione <NmDsp>
Presenza: [1..1]
Definizione: Progressivo della disposizione/rendicontazione su cui stato rilevato
lerrore
Tipo: NonNegativeIntegerNumber

d.5.3.2. Tipo record <RcTyp>
Presenza: [1..1]
Definizione: Tipologia di record su cui stato rilevato l'errore
Tipo: Max2Text (Cfr. tabella attuali standard tecnici CBI)

d.5.3.3. Posizione inizio <PstStrt>
Presenza: [1..1]
Definizione: Posizione di inizio su cui stato rilevato lerrore
Tipo: PositiveIntegerNumber

d.5.3.4. Posizione fine <PstNeg>
Presenza: [1..1]
Definizione: Posizione di fine su cui stato rilevato lerrore
Tipo: PositiveIntegerNumber

d.5.3.5. Codice derrore <ErrCd>
Presenza: [1..1]
Definizione: Errore rilevato sulla disposizione del supporto logico. Le possibili
codifiche sono state definite sulla base delle attuali segnalazioni di errore scambiate
tra Centri Applicativi (Cfr. Appendice C del documento CBI-STD-001 per i dettagli).
Tipo: ErrorDetailsCode
Pu assumere i seguenti valori:

Cod. Err. Descrizione errore
<Cfr doc. CBI-STD-001> <Cfr doc. CBI-STD-001>
.
<ulteriori codifiche da valutare>


Controlli

Per il dettaglio su Facoltativit/Obbligatoriet e sui controlli (Formali, Validit etc.) da applicare al messaggio
XML si rimanda al documento Excel STAA-ST-002.
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
55/ 59



8.4 ALLEGATO D ESEMPI DI XML

Esempio di messaggio XML (Header di Tratta definito nel namespace HTRT + Header di Servizio definito
nel namespace HE2E+ Body di Servizio definito nel namespace BODY) di accompagnamento file.

<?xml version="1.0" encoding="UTF-8"?>
<!--Sample XML file generated by XML Spy v4.3 U (http://www.xmlspy.com)-->
<CBIPrtSrvRq xmlns="urn:CBI:xsd:CBIPrtSrvRq.001.03" xmlns:BODY="urn:CBI:xsd:CBIBdyPrtSrvRq.001.03"
xmlns:HE2E="urn:CBI:xsd:CBIHdrSrv.001.04" xmlns:HTRT="urn:CBI:xsd:CBIHdrTrt.001.04"
xmlns:SGNT="urn:CBI:xsd:CBISgnInf.001.02" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:CBI:xsd:CBIPrtSrvRq.001.03">
<CBIHdrTrt>
<HTRT:IdCBISndrf>0000012J </HTRT:IdCBISndrf>
<HTRT:IdCBIRcvrf>0000007U</HTRT:IdCBIRcvrf>
<HTRT:SrvNm>PORTING-RH</HTRT:SrvNm>

<HTRT:IdMsgTrt>0000024O0000025S0000024O000000000000000000010000024O123456789</HTRT:I
dMsgTrt>
<HTRT:XMLCrtDt>2001-12-17T09:32:50-05:00</HTRT:XMLCrtDt>
<HTRT:RtrnAddrl>88503NCB01PR</HTRT:RtrnAddrl>
</CBIHdrTrt>
<CBIHdrSrv>
<HE2E:SrvInfo>
<HE2E:SrvNm>PORTING-RH</HE2E:SrvNm>
<HE2E:IdE2EMsg>0000024O0000025S0000024O00000000000000000001</HE2E:IdE2EMsg>
<HE2E:XMLCrtDt>2001-12-17T09:32:50-05:00</HE2E:XMLCrtDt>
</HE2E:SrvInfo>
<HE2E:Sender>
<HE2E:IdCBISend>0000024O</HE2E:IdCBISend>
<HE2E:SendTyp>Banca Passiva</HE2E:SendTyp>
<HE2E:CBIRefrSend>0000012J </HE2E:CBIRefrSend>
</HE2E:Sender>
<HE2E:Receiver>
<HE2E:IdCBIRecv>0000025S</HE2E:IdCBIRecv>
<HE2E:RecvTyp>Banca Proponente</HE2E:RecvTyp>
<HE2E:CBIRefrRecv>0000007U</HE2E:CBIRefrRecv>
</HE2E:Receiver>
<HE2E:DiagInfo>
<HE2E:UsrBnk>0000024O</HE2E:UsrBnk>
<HE2E:DiagVers>CBI_5.2</HE2E:DiagVers>
<HE2E:ChkSbj>0000012J </HE2E:ChkSbj>
<HE2E:ChkDt>2001-12-17T09:32:55-05:00</HE2E:ChkDt>
</HE2E:DiagInfo>
<HE2E:CongrInfo>
<HE2E:SrvBdyNb>0001</HE2E:SrvBdyNb>
</HE2E:CongrInfo>
</CBIHdrSrv>
<CBIBdyPrtSrvRq>
<BODY:FleInfo>
<BODY:FlwTyp>RH</BODY:FlwTyp>
<BODY:FleNm>0000012J 000000000000000000001</BODY:FleNm>
</BODY:FleInfo>
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
56/ 59


<BODY:DiagInfo>
<BODY:UsrBnk>0000024O</BODY:UsrBnk>
<BODY:DiagVers>CBI_5.2</BODY:DiagVers>
<BODY:ChkSbj>0000012J </BODY:ChkSbj>
<BODY:ChkDt>2001-12-17</BODY:ChkDt>
</BODY:DiagInfo>
<BODY:SppInfo>
<BODY:SIASndCd>AAAAA</BODY:SIASndCd>
<BODY:ABICd>05040</BODY:ABICd>
<BODY:CreDt>2001-12-17</BODY:CreDt>
<BODY:SppNm>supporto1</BODY:SppNm>
<BODY:SgnInfo>
<SGNT:SgnTyp>1</SGNT:SgnTyp>
<SGNT:RefPlt>A</SGNT:RefPlt>
<SGNT:DtRef>2001-12-17T09:30:58-05:00</SGNT:DtRef>
<SGNT:Sgnt>String</SGNT:Sgnt>
</BODY:SgnInfo>
</BODY:SppInfo>
<BODY:SppInfo>
<BODY:SIASndCd>AAAAA</BODY:SIASndCd>
<BODY:ABICd>05040</BODY:ABICd>
<BODY:CreDt>2001-12-17</BODY:CreDt>
<BODY:SppNm>supporto2</BODY:SppNm>
</BODY:SppInfo>
</CBIBdyPrtSrvRq>
</CBIPrtSrvRq>




Esempio di messaggio XML (Header di Tratta definito nel namespace HTRT + Header di Servizio definito
nel namespace HE2E+ Body di Servizio definito nel namespace BODY) di conferma ricezione
file/supporto, corrispondente al 1 messaggio di avanzamento (17) previsto dal workflow Porting (Cfr.
Par. 2.2.1.1).

<?xml version="1.0" encoding="UTF-8"?>
<CBIPrtAdvSts xmlns="urn:CBI:xsd:CBIPrtAdvSts.001.03"
xmlns:BODY="urn:CBI:xsd:CBIBdyPrtAdvSts.001.03" xmlns:HE2E="urn:CBI:xsd:CBIHdrSrv.001.04"
xmlns:HTRT="urn:CBI:xsd:CBIHdrTrt.001.04" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:CBI:xsd:CBIPrtAdvSts.001.03">
<CBIHdrTrt>
<HTRT:IdCBISndrf>0000007U</HTRT:IdCBISndrf>
<HTRT:IdCBIRcvrf>0000012J </HTRT:IdCBIRcvrf>
<HTRT:SrvNm>PORTING-RH</HTRT:SrvNm>

<HTRT:IdMsgTrt>0000025S0000024O0000025S000000000000000000020000025S232323234</HTRT:Id
MsgTrt>
<HTRT:XMLCrtDt>2001-12-18T09:32:50-05:00</HTRT:XMLCrtDt>
<HTRT:RtrnAddrl>88503HCB01PR</HTRT:RtrnAddrl>
</CBIHdrTrt>
<CBIHdrSrv>
<HE2E:SrvInfo>
<HE2E:SrvNm>PORTING-RH</HE2E:SrvNm>
<HE2E:IdE2EMsg>0000025S0000024O0000025S00000000000000000002</HE2E:IdE2EMsg>
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
57/ 59


<HE2E:XMLCrtDt>2001-12-18T09:32:55-05:00</HE2E:XMLCrtDt>
</HE2E:SrvInfo>
<HE2E:Sender>
<HE2E:IdCBISend>0000025S</HE2E:IdCBISend>
<HE2E:SendTyp>Banca Proponente</HE2E:SendTyp>
<HE2E:CBIRefrSend>0000007U</HE2E:CBIRefrSend>
</HE2E:Sender>
<HE2E:Receiver>
<HE2E:IdCBIRecv>0000024O</HE2E:IdCBIRecv>
<HE2E:RecvTyp>Banca Passiva</HE2E:RecvTyp>
<HE2E:CBIRefrRecv>0000012J </HE2E:CBIRefrRecv>
</HE2E:Receiver>
<HE2E:DiagInfo>
<HE2E:UsrBnk>0000025S</HE2E:UsrBnk>
<HE2E:DiagVers>CBI_5.2</HE2E:DiagVers>
<HE2E:ChkSbj>0000007U</HE2E:ChkSbj>
<HE2E:ChkDt>2001-12-18T09:32:55-05:00</HE2E:ChkDt>
</HE2E:DiagInfo>
<HE2E:CongrInfo>
<HE2E:SrvBdyNb>0001</HE2E:SrvBdyNb>
</HE2E:CongrInfo>
</CBIHdrSrv>
<CBIBdyPrtAdvSts>
<BODY:MsgTyp>1</BODY:MsgTyp>
<BODY:FleInfo>
<BODY:FlwTyp>RH</BODY:FlwTyp>
<BODY:FleNm>0000012J 000000000000000000001</BODY:FleNm>
<BODY:SendSts>
<BODY:AdvSts>RCVD</BODY:AdvSts>
</BODY:SendSts>
</BODY:FleInfo>
<BODY:DiagInfo>
<BODY:UsrBnk>0000025S</BODY:UsrBnk>
<BODY:DiagVers>CBI_5.2</BODY:DiagVers>
<BODY:ChkSbj>0000007U</BODY:ChkSbj>
<BODY:ChkDt>2001-12-18</BODY:ChkDt>
</BODY:DiagInfo>
</CBIBdyPrtAdvSts>
</CBIPrtAdvSts>


Esempio di messaggio XML (Header di Tratta definito nel namespace HTRT + Header di Servizio definito
nel namespace HE2E+ Body di Servizio definito nel namespace BODY) di conferma ricezione
file/supporto, corrispondente al 2 messaggio di avanzamento (20) previsto dal workflow Porting (Cfr.
Par. 2.2.1.1).


<?xml version="1.0" encoding="UTF-8"?>
<CBIPrtAdvSts xmlns="urn:CBI:xsd:CBIPrtAdvSts.001.03"
xmlns:BODY="urn:CBI:xsd:CBIBdyPrtAdvSts.001.03" xmlns:HE2E="urn:CBI:xsd:CBIHdrSrv.001.04"
xmlns:HTRT="urn:CBI:xsd:CBIHdrTrt.001.04" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:CBI:xsd:CBIPrtAdvSts.001.03">
<CBIHdrTrt>
<HTRT:IdCBISndrf>0000007U</HTRT:IdCBISndrf>
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
58/ 59


<HTRT:IdCBIRcvrf>0000012J </HTRT:IdCBIRcvrf>
<HTRT:SrvNm>PORTING-RH</HTRT:SrvNm>

<HTRT:IdMsgTrt>0000025S0000024O0000025S000000000000000000030000025S345656456</HTRT:Id
MsgTrt>
<HTRT:XMLCrtDt>2001-12-18T17:32:50-05:00</HTRT:XMLCrtDt>
<HTRT:RtrnAddrl>88503HCB01PR</HTRT:RtrnAddrl>
</CBIHdrTrt>
<CBIHdrSrv>
<HE2E:SrvInfo>
<HE2E:SrvNm>PORTING-RH</HE2E:SrvNm>
<HE2E:IdE2EMsg>0000025S0000024O0000025S00000000000000000003</HE2E:IdE2EMsg>
<HE2E:XMLCrtDt>2001-12-18T09:32:50-05:00</HE2E:XMLCrtDt>
</HE2E:SrvInfo>
<HE2E:Sender>
<HE2E:IdCBISend>0000025S</HE2E:IdCBISend>
<HE2E:SendTyp>Banca Proponente</HE2E:SendTyp>
<HE2E:CBIRefrSend>0000007U</HE2E:CBIRefrSend>
</HE2E:Sender>
<HE2E:Receiver>
<HE2E:IdCBIRecv>0000024O</HE2E:IdCBIRecv>
<HE2E:RecvTyp>Banca Passiva</HE2E:RecvTyp>
<HE2E:CBIRefrRecv>0000012J </HE2E:CBIRefrRecv>
</HE2E:Receiver>
<HE2E:DiagInfo>
<HE2E:UsrBnk>0000025S</HE2E:UsrBnk>
<HE2E:DiagVers>CBI_5.2</HE2E:DiagVers>
<HE2E:ChkSbj>0000007U</HE2E:ChkSbj>
<HE2E:ChkDt>2001-12-18T17:32:55-05:00</HE2E:ChkDt>
</HE2E:DiagInfo>
<HE2E:CongrInfo>
<HE2E:SrvBdyNb>0001</HE2E:SrvBdyNb>
</HE2E:CongrInfo>
</CBIHdrSrv>
<CBIBdyPrtAdvSts>
<BODY:MsgTyp>2</BODY:MsgTyp>
<BODY:FleInfo>
<BODY:FlwTyp>RH</BODY:FlwTyp>
<BODY:FleNm>0000012J 000000000000000000001</BODY:FleNm>
<BODY:SendSts>
<BODY:AdvSts>RCVD</BODY:AdvSts>
</BODY:SendSts>
</BODY:FleInfo>
<BODY:DiagInfo>
<BODY:UsrBnk>0000025S</BODY:UsrBnk>
<BODY:DiagVers>CBI_5.2</BODY:DiagVers>
<BODY:ChkSbj>0000007U</BODY:ChkSbj>
<BODY:ChkDt>2001-12-18</BODY:ChkDt>
</BODY:DiagInfo>
<BODY:SppInfo>
<BODY:SIASndCd>AAAAA</BODY:SIASndCd>
<BODY:ABICd>05040</BODY:ABICd>
<BODY:CreDt>2001-12-17</BODY:CreDt>
<BODY:SppNm>supporto1</BODY:SppNm>
Titolo:
Nuova Architettura CBI
Codice
PORTI NG-MO-001
Versione
00.07.09
Tipologia Documento:
Porting degli attuali Servizi CBI nella Nuova
Architettura
Data
09-07-2010
Pagina
59/ 59


<BODY:SendSts>
<BODY:AdvSts>ACTC</BODY:AdvSts>
</BODY:SendSts>
</BODY:SppInfo>
<BODY:SppInfo>
<BODY:SIASndCd>AAAAA</BODY:SIASndCd>
<BODY:ABICd>05040</BODY:ABICd>
<BODY:CreDt>2001-12-17</BODY:CreDt>
<BODY:SppNm>supporto2</BODY:SppNm>
<BODY:SendSts>
<BODY:AdvSts>ERRR</BODY:AdvSts>
<BODY:LgSpErrCd>PSL5</BODY: LgSpErrCd >
<BODY:ErrDtl>
<BODY:NmDsp>4</BODY:NmDsp>
<BODY:RcTyp>61</BODY:RcTyp>
<BODY:PstStrt>53</BODY:PstStrt>
<BODY:PstEnd>57</BODY:PstEnd>
<BODY:ErrCd>012</BODY:ErrCd>
</BODY:ErrDtl>
</BODY:SendSts>
</BODY:SppInfo>
</CBIBdyPrtAdvSts>
</CBIPrtAdvSts>


8.5 ALLEGATO E STRUTTURAZI ONE DEGLI I DENTI FI CATI VI UNIVOCI E QUALI FI CATORI DI TI PO
MESSAGGIO

Con riferimento alle regole di strutturazione degli identificativi univoci di file e messaggi veicolati sulla rete
CBI (cfr. doc. STPG-MO-001 Nuovi Servizi Parte Generale), viene fornita la lista dei qualificatori tipo
messaggio (QTM) da utilizzarsi nellambito del workflow che caratterizza lerogazione dei servizi Porting.

Tipo di messaggio fisico Qualificatore Tipo Messaggio (QTM)
Richiesta di servizio 01
Primo messaggio di stato avanzamento 17
Secondo messaggio di stato avanzamento 20



Fine del Documento