FAQ Webinar SEPA end-date 2016 organizzato dal Consorzio CBI con la
partecipazione di:
-
Servizio Supervisione sui Mercati e sui Sistemi di Pagamento Banca d’Italia
Settore Sistemi e Servizi di Pagamento ABI
Risposte ai quesiti formulati dai partecipanti nel corso dei Webinar del:
-
19 novembre 2015
16 dicembre 2015
19 gennaio 2016
-----------------------------------
1) In che tempi e modalità verrà messo a disposizione l'opuscolo informativo?
Risp.: Al fine di assicurare che tutte le parti coinvolte siano informate e preparate sui cambiamenti da
porre in essere, è stato realizzato nell’ambito del Comitato Pagamenti Italia - CPI un opuscolo informativo
che presenta in dettaglio i diversi aspetti della migrazione allo standard ISO 20022 XML. L’opuscolo è già
disponibile in formato elettronico sul sito delle Banca d’Italia nella sezione dedicata al CPI al seguente
indirizzo:
https://www.bancaditalia.it/media/notizia/le-imprese-e-la-single-euro-payments-area
Le associazioni di categoria (ABI, Consorzio CBI, AITI Confindustria, CSIT e Assinform), che hanno
contribuito alla redazione della brochure, sono state invitate a darne la più ampia diffusione anche con
pubblicazione sul rispettivo sito.
2) I documenti proiettati (pdf, ppt, ecc) saranno resi disponibili per il download?
Risp.: Si, tutto il materiale viene messo a disposizione sul portale CBI (www.cbi-org.eu) all’interno della
pagina dedicata all’evento, in cui è pubblicata anche la presente FAQ.
3) Dove (è possibile) reperire in modo sicuro tutta la documentazione più aggiornata?
Risp.: Al fine avere informazioni aggiornate sugli impegni della seconda fase di migrazione alla SEPA, si
potrà accedere al sito delle Banca d’Italia nella sezione dedicata al Comitato Pagamenti Italia dove si
trovano i resoconti degli incontri del CPI e del materiale informativo (es. opuscolo SEPA su XML).
Ulteriore documentazione utile in merito alla SEPA e al servizio SEDA è inoltre disponibile sul sito
www.sepaitalia.eu
I documenti tecnici del Consorzio CBI sono invece reperibili nell’area riservata ai Non consorziati /
Standard tecnici del sito www.cbi-org.eu. La registrazione è aperta e del tutto gratuita.
1
4) I PSP dei pagatori dovranno dare per scontato che i clienti siano stati informati?
Risp.: Se ci si riferisce alla comunicazione che i Beneficiari devono inviare ai clienti Pagatori, la risposta è
affermativa nel senso che i PSP dei Pagatori devono assumere (e non sono in grado di verificare) che i
Beneficiario dei servizi RID finanziario e RID ad importo prefissato comunichino ai propri clienti pagatori
l’intenzione di avvalersi dei servizi SDD finanziario e SDD ad importo prefissato (o di altra tipologia di
addebito SDD – Core o B2B) con un preavviso di almeno 30 giorni rispetto alla data di attivazione di tali
servizi.
5) L'informativa ai clienti da parte del PSP andrà fatta a prescindere da un'effettiva migrazione?
Risp.: La circolare ABI di Serie Tecnica n. 19 del 2 dicembre 2015 chiarisce che “Ai fini della migrazione dei
RID di nicchia ai servizi SDD finanziario e ad importo prefissato i PSP – ai sensi delle disposizioni di cui al
Titolo VI del D. Lgs. 1° settembre 1993 n. 385 – devono proporre ove necessario alla propria clientela le
modifiche delle condizioni contrattuali connesse con l’esecuzione degli addebiti SDD finanziario e ad
importo prefissato, secondo le caratteristiche della soluzione identificata per la migrazione”. Tale
comunicazione deve essere fatta, ove necessario, nei confronti di tutta la clientela con la quale è in
essere un contratto quadro sul quale è attivo il servizio SEPA Direct Debit Core.”
6) Data di emanazione della delibera ABI avallata dalla Banca d'Italia?
Risp.: In data 2 dicembre 2015 è stata emanata la circolare ABI di Serie Tecnica n. 19 che descrive la
soluzione tecnica attraverso la quale – in coerenza con le indicazioni fornite dal Comitato Pagamenti Italia
– potrà essere effettuata la migrazione dei RID di nicchia (RID finanziario e RID ad importo prefissato) alla
SEPA.
7) Quindi le microimprese possono continuare a usare i formati arricchiti?
Risp.: Per quanto riguarda l’operatività CBI, non vi è alcuna distinzione tra microimprese ed imprese per
cui anche le microimprese utenti, qualora dotate di stazione di lavoro CBI multibanca, dovranno di fatto
adeguarsi ai formati XML (ricorrendo eventualmente a servizi di conversione a monte, ovvero forniti da
software house o Banche Proponenti). In alternativa potranno ricorrere a prodotti proprietari
monobanca, in ambito competitivo. Rammentiamo comunque che gli intermediari finanziari sono già stati
obbligati a migrare alle procedure SEPA XML dal 2014, e che per questo motivo tutte le imprese sono
raccomandate di migrare nativamente ai nuovi formati XML corrispondenti a quelli utilizzati nei rapporti
interbancari al fine sia di evitare perdite eventuali di informazione, sia di cogliere a pieno la migliore
strutturazione informativa garantita dai nuovi tracciati in ottica di processo end-to-end. Inoltre soltanto
l’adozione nativa dei formati XML consente il pieno accesso a tutte le nuove funzionalità SEPA (ad es. si
cita la possibilità di variare i Creditor Id in ambito SEDA).
8) Quando verrà resa disponibile la rendicontazione di c/c secondo gli standard SEPA per permettere di
tracciare il flusso di ritorno dei pagamenti inviati?
Risp.: La funzione di “Rendicontazione XML” è stata già definita dal Consorzio CBI ed è erogabile dagli
Istituti finanziari dal 23/09/2013. È ad oggi una funzione facoltativa, è quindi necessario verificare con il
2
proprio Istituto l’effettiva disponibilità della stessa. Come anticipato durante il webinar, seguirà un
percorso di adozione obbligatoria da parte di Banche Proponenti e Banche Passive (per quest’ultime,
qualora le funzioni XML siano richieste dai clienti), prevedendo – almeno fino al 2017 – il mantenimento
delle funzioni attuali e gestendo pertanto un parallelo delle rendicontazioni GIORNALIERE fino a data da
definire.
9) Dato il chiarimento sul trattamento delle presentazioni su cartaceo/supporto magnetico/mail, chiediamo
che lo stesso venga opportunamente riportato per iscritto e in modo inequivocabile per avere un supporto
nei confronti della clientela.
Risp.: Per quanto attiene ai dubbi relativi a disposizioni di pagamento disposte mediante supporto
magnetico (cd/email) o cartaceo, Banca d’Italia chiarisce che in linea con le previsioni del Reg. 260/2012
l’invio delle disposizioni in formato XML presuppone l’utilizzo di un flusso elettronico strutturato che non
appare compatibile con un supporto cartaceo. Resta ovviamente ferma la possibilità di utilizzare formati
diversi nell’ambito dei servizi di conversione acquisiti da soggetti terzi (siano essi fornitori specializzati o
gli stessi prestatori di servizi di pagamento).
10) Potreste approfondire anche quali sono i vantaggi per le imprese, ossia l'import degli esiti per la
riconciliazione di incassi e pagamenti?
Risp.: I flussi XML prevedono anche un apposito Status Report nel medesimo formato strutturato, che
garantisce la riconciliazione rispetto alle richieste di servizio SCT, SDD e SEDA inoltrate. I vantaggi per le
imprese riguardano in generale la possibilità di estendere i pagamenti / incassi domestici a tutta l’area UE
nel medesimo formato (es.: un bonifico in Euro ad un fornitore in area UE è del tutto assimilabile a quello
fatto ad un fornitore italiano), nonché la funzionalità, l’efficienza dei costi, la flessibilità di manutenzione
ed il trattamento interamente automatizzato dei dati.
11) Per ogni tipologia di vecchio flusso (PC-EF, IR-EF, AL-EF) quali sono le date a partire dalle quali questi flussi
saranno scartati dalla rete CBI?
Risp: Si riportano di seguito le varie scadenze al riguardo previste:
- (PC-EF): la componente di bonifico ordinario del tracciato PC-EF è stata dismessa a partire dal 1°
febbraio 2016, in coerenza con la normativa end-date SEPA, in favore della corrispondente funzione
XML di Sepa Credit Transfer CBI. Pertanto, a partire da tale data non è più possibile inviare disposizioni
di bonifico PC-EF sul canale CBI. La funzione dispositiva “PORTING PC” è utilizzata esclusivamente per
consentire la veicolazione di richieste di emissione assegni, fuori ambito del Regolamento in discorso,
pena scarto diagnostico da parte dei soggetti veicolatori.
- (IR-EF): I tracciati IR-EF sono migrati da tutta la clientela a partire dal 1° febbraio 2016, in coerenza con
il Regolamento 260/2012 e le relative istruzioni applicative di Banca d’Italia, in favore della
corrispondente funzione XML SDD CBI. A differenza della componente bonifico PC-EF non c’è un blocco
operativo sulla rete CBI fino a data che verrà comunicata successivamente in accordo con le decisioni
assunte da ABI riguardo alla chiusura della procedura RID. In sostanza, la quota residuale di RID ancora
in uso potrà essere in via eccezionale veicolata nelle comunicazioni tra banche proponenti e passive
anche dopo la data di febbraio, sebbene richieste di servizio relative a RID “non di nicchia” potranno
essere rifiutate da parte delle banche passive assuntrici.
3
- (AL-EF): La Componente di Allineamento Elettronico Archivi segue le stesse evoluzioni dei tracciati IREF per quanto riguarda le nuove domiciliazioni, in vista della vera e propria dismissione in piena
coerenza con le prossime decisioni di ABI. Quindi a febbraio non c’è stata alcuna depubblicazione, ma
da febbraio eventuali richieste di nuove domiciliazioni AL-EF potrebbero non essere accettate dalle
banche di allineamento, invitando le aziende creditrici a fare ricorso all’AOS SEDA XML appositamente
introdotto dalla comunità finanziaria italiana.
12) Lato diagnostico CBI dal 1° febbraio i flussi di porting RID e AEA dovranno essere scartati o potranno
continuare ad essere veicolati fino a data da destinarsi?
Risp.: La frase riportata nel webinar secondo la quale “dal 1 febbraio 2016 sulla rete CBI non saranno più
accettati Rid e Aea.” rispecchia la scadenza normativa, che è rimasta quella del 1° febbraio, tuttavia non
sono stati introdotti ancora veri e propri blocchi applicativi su RID ed AEA: i RID residui (attualmente
inferiori al 10% del totale degli addebiti diretti sulla rete CBI) potranno continuare a girare tra banche
proponenti e passive, fino a data di chiusura definitiva (=depubblicazione dal Directory CBI lato banche
passive) che sarà stabilita in base anche a decisioni ABI; anche quest’ultima non ha introdotto blocchi a
livello di CA ma solo divieti formali per le banche. Vedasi al riguardo per completezza la precedente
risposta 11.
13) Dal 01.02.2016 i clienti ci devono mandare due file XML separati per bonifici nell'UE e fuori UE (con divisa
non EURO)?
Risp.: Confermiamo che è necessario inviare due distinte separate per i bonifici SEPA ed extra SEPA,
equivalenti nell’ordine ai nuovi bonifico “domestico” ed “estero”. Per i bonifici infra UE/EEA in Euro è di
fatto obbligatorio l’utilizzo dello standard SCT, per i bonifici esteri fuori UE o in divisa è ancora utilizzato il
formato attuale PE-EF (fino a data futura da definirsi comunque oltre il 2017), ovvero in alternativa il
nuovo Bonifico estero XML nel formato ISO20022 pubblicato dal Consorzio CBI.
14) Cosa si intende con la frase "con obbligo a partire dal 1° febbraio 2016, (gli utenti dovranno adottare) il
formato ISO 20022 XML quando dispongono o ricevono bonifici o singoli addebiti diretti trasmessi non
individualmente bensì in forma aggregata."? I flussi in formato CBI sono in regola?
Risp.: Per “bonifici o singoli addebiti diretti trasmessi in forma aggregata” si intende ordini della stessa
tipologia trasmessi dalla azienda in forma di “file”, ovvero mediante un unico supporto informatico /
distinta che raggruppa una o più disposizioni. Il formato del file secondo lo standard CBI è derivato proprio
dallo standard ISO20022 XML e pertanto è pienamente conforme alla norma in discorso.
15) Nel caso in cui a fine gennaio vengano inviate diposizioni d’incasso con i vecchi tracciati CBI, il file di ritorno
degli insoluti sarà con il nuovo o con il vecchio tracciato?
Risp.: Il messaggio di ritorno osserva sempre il medesimo formato della richiesta correlata; a tale
proposito si terrà conto del pregresso anche nello smaltimento dei ritorni entro le 8 settimane (rimborsi),
per cui i ritorni IR-EF verranno dismessi (depubblicati da banche proponenti) solo alcuni mesi dopo la
chiusura tecnica della procedura RID (depubblicazione da banca passiva), restando in vita probabilmente
4
almeno fino a tutto il 2016. Entrambe le date di depubblicazione, lo ribadiamo, sono da definire in
coerenza con pari decisioni ABI.
16) Alcune banche richiedono un formato del file xml che non corrisponde alla struttura dell'ultima versione.
Vorrei quindi sapere se questo è corretto ed a questo punto quale versione utilizzare per la creazione
dell'xml contenente le richieste di incasso.
Risp: Lo standard CBI attualmente in vigore, basato sullo standard CustomerDirectDebitInitiationV02
<pain.008.001.02> ISO20022, corrisponde alla versione 00.01.00, pubblicata sul portale consortile nella
sezione “Standard Tecnici”/“Area Incassi”. Si segnala al riguardo che il numero di versione è rimasto
invariato al fine di limitare gli impatti tecnici dell’aggiornamento. La versione in vigore è quella che fa fede
per tutte le interazioni tra gli utenti.
17) Gli standard CBI sono già definitivi ed aggiornati alla data del 1/2/2016?
Risp.: Sì, la funzione di Bonifico XML CBI entrata in vigore il 1° febbraio 2016 è pubblicata nella sezione
Standard/Area Pagamenti del portale consortile www.cbi-org.eu.
18) Quale data stabilisce lo spartiacque per i RID c.d. di nicchia?
a) la data invio flusso?
b) la data di regolamento?
Risp.: Nella circolare ABI di Serie Tecnica n. 19 del 2 dicembre 2015 è chiarito che:

con decorrenza dal 1° febbraio 2016 i Beneficiari opportunamente censiti nell’anagrafica CRI000
possono avvalersi dei servizi SDD finanziari e ad importo prefissato e quindi possono inviare richieste
d’incasso SDD finanziario e ad importo prefissato caratterizzate con detti codici dedicati.

dal 1° febbraio 2016 i PSP non devono utilizzare la procedura nazionale RID per l’esecuzione di
operazioni di addebito RID finanziario e RID ad importo prefissato. Più precisamente a partire dalla
data applicativa del 1° febbraio 2016 non devono essere scambiati messaggi 401 “Richiesta d’incasso
RID” nella procedura Incassi Commerciali Interbancari, con la conseguenza che la data ultima di
regolamento di un addebito diretto RID finanziario e RID ad importo prefissato è il 10 febbraio;

a partire dalla data applicativa del 1° febbraio 2016 i PSP (nel ruolo di PSP del Pagatore e nel ruolo di
PSP d’Allineamento) non possono gestire tramite la procedura Allineamento Elettronico Archivi – RID
(AEA-RID) nuove richieste di autorizzazione all’addebito di RID finanziari e ad importo prefissato
(causali 90210 e 90211). La procedura AEA-RID è rimasta aperta per gestire la comunicazione di
eventuali variazioni o richieste di cancellazione di deleghe RID di nicchia per un periodo limitato di
tempo successivo alla predetta scadenza del 1° febbraio 2016 con l’obiettivo di consentire
l’aggiornamento di informazioni relative a deleghe RID che, in virtù del ciclo di incasso previsto,
potrebbero migrare agli Schemi SEPA in un momento successivo. Il messaggio di variazione ad
iniziativa del PSP del Pagatore risulta peraltro utile, come già evidenziato, per segnalare ai Beneficiari
l’IBAN corretto di addebito.
5
19) Nelle slides proponevate la versione 7.0 delle guidelines per SCT. Dovremmo invece essere attivati alla
versione 8.0. Confermate?
Risp.: Corretto, tuttavia la versione 8.0 delle Implementation Guidelines EPC è entrata in vigore il 22
novembre 2015, dopo il primo webinar, senza impatti sulle rispettive versioni CBI.
20) Nei file xsd scaricati non trovo CBIHdrTrt.001.07 e CBIHdrSrv.001.07. Dove potrei reperirli?
Risp.: Gli xsd CBIHdrTrt.001.07 e CBIHdrSrv.001.07 sono presenti nella documentazione generale che
riguarda trasversalmente tutti i servizi CBI e che è disponibile per il download nella sezione “Standard
tecnici” del portale consortile (http://www.cbi-org.eu/Engine/RAServePG.php/P/250210010307, Aspetti
generali relativi ai Nuovi Servizi CBI).
21) Con riferimento alla Circolare ABI ST n. 19 ed in particolare al par. IV riguardante le comunicazioni ai
Pagatori chiedo se ABI ha predisposto un prototipo di comunicazione da inviare, da parte delle banche ai
Pagatori come previsto dal DLGS 385/1993 titolo VI.
Risp: No, ABI non ha predisposto un prototipo di comunicazione che ogni PSP deve effettuare ai sensi di
quanto previsto l da Titolo VI del D. Lgs. 1° settembre 1993 n. 385 in materia di modifiche delle condizioni
contrattuali.
22) Dove trovo la lista dei codici relativi alla motivazione dello status? (Tracciato degli esiti SDD)
Risp: I codici ISO (che vengono inseriti nel campo <Rsn>/<Cd>) sono pubblicati sul portale ISO20022,
all’indirizzo http://www.iso20022.org/external_code_list.page (foglio “StatusReason”). Nel campo
<Rsn>/<Prtry> la banca passiva può eventualmente inserire codici proprietari condivisi preventivamente
con il cliente.
23) E gli F24? Il riferimento è ai pagamenti con tracciato CBI.
Risp.: Il modello F24 ed i tracciati corrispondenti sono definiti sulla base di accordi specifici con l’Agenzia
delle Entrate e rispecchiano i requisiti normativi imposti dal Fisco italiano. Ciò detto non è ancora allo
studio una trasposizione XML di tale standard.
24) Come saranno gestiti i flussi RNI inviati in gennaio ma con termine di lavorazione in febbraio?
a) i flussi inviati RNI riceveranno solo risposte RNI?
b) i flussi inviati RNI possono ricevere risposte RNI e SEPA?
c) i flussi inviati RNI riceveranno solo risposte SEPA?
Risp.: Gli esiti di disposizioni di addebito diretto gestite mediante procedura RID sono gestiti in via
esclusiva tramite la medesima procedura RID.
6
25) 92% degli SDD (rilevati sulla rete CBI), ma in termini di clienti? I primi 10 creditori (multiutility) fanno
volumi altissimi e non ci danno un'idea dei clienti in termini assoluti che devono ancora migrare.
Risp.:
Risp.: Nell’ambito del Comitato Pagamenti Italia (CPI) è stato costituito uno specifico sottogruppo
incaricato di monitorare l’adozione dei formati XML da parte delle imprese per i pagamenti SEPA. E’ stata
quindi avviata a marzo 2015 una rilevazione bimestrale sull’adozione da parte delle imprese dei formati
XML per l’invio degli ordini di pagamento aggregati, sulla base dello schema di rilevazione concordato
all’interno del sottogruppo CPI. Alla rilevazione contribuisce un campione rappresentativo di operatori:
fornitori tecnologici, banche aderenti al Comitato e strutture tecniche CBI. I risultati delle risposte ricevute
alla data di dicembre 2015 indicano che la quota delle imprese che hanno trasmesso almeno un file SCT
in forma aggregata nel formato XML si attesta a circa il 44%; l’analogo dato per gli SDD in forma aggregata
è pari a circa il 62%. Nell’ambito del totale delle disposizioni di bonifico predisposte dalle imprese, circa il
38% è in formato XML; mentre per le disposizioni di addebito diretto tale quota è pari all’84%. Tali dati
evidenziano un ritmo di migrazione ancora insoddisfacente.
26) Anche nell'sdd ad importo fisso l'importo non è un importo massimo ma un importo preciso che
determina lo storno di addebiti anche in caso di importo inferiore nell’sdd rispetto a quello autorizzato?
Risp: Corretto. Le caratteristiche del SDD ad importo prefissato rimangono quelle del RID ad importo
prefissato e cioè che l’importo autorizzato dal Pagatore (importo prefissato e non importo massimo) è
l’unico addebitabile sul conto per quella specifica autorizzazione.
27) Non ho colto con quali modalità sarà specificato l'importo del mandato con importo prefissato, dato che
non saranno modificati i tracciati SEDA
Risp.: Nel caso di migrazione allo schema SDD ad importo prefissato di vecchie deleghe RID il PSP del
Pagatore effettua la conversione da delega RID a mandato SDD ad importo prefissato a ricezione della
prima disposizione SDD che risulti valorizzata nel rispetto delle regole convenzionali previste per la
continuità delle deleghe. Nella disposizione il Beneficiario avrà cura di indicare l’importo prefissato che
caratterizzata la delega RID sottoscritta dal pagatore (viceversa, e cioè se l’importo indicato nella
disposizione SDD ad importo prefissato è diverso da quello che caratterizzava la delega IRD ad importo
prefissato la disposizione viene rifiutata dal PSP.
Nel caso di nuovi mandati SDD, l’importo prefissato è indicato nel mandato sottoscritto dal pagatore e:
a) se il beneficiario non aderisce al servizio SEDA o aderisce al modulo “base” del servizio SEDA,
l’importo prefissato indicato sul mandato è comunicato dal Beneficiario nella prima disposizione SDD
ad importo prefissato (e poi registrato dal PSP del Pagatore che effettua successivi controlli di
coerenza);
b) se il beneficiario aderisce al modulo avanzato del servizio SEDA il PSP del Pagatore potrà anche
registrare l’informazione nei propri archivi ma i tracciati SEDA al momento non trasportano questa
informazione con la conseguenza che il processo è il medesimo descritto alla lettera a).
7
28) Se una società, che ha già un creditor identifier ed emette sdd core, volesse procedere all'emissione di
SDD ad importo fisso dovrebbe richiedere quindi un nuovo creditor identifier diverso da quello
tradizionale?
Risp.: E’ corretto. I codici Creditor Identifier utilizzabili per l’incasso di SDD finanziari e SDD ad importo
prefissato sono codici utilizzabili in via esclusiva per questa tipologia di varianti SDD con la conseguenza
che se un’azienda deve incassare sia mediante SDD Core o B2B sia tramite SDD finanziario o ad importo
prefissato, dovrà utilizzare codici Creditor Identifier diversi.
29) Dove si metterà l'importo prefissato nel mandato?
Risp.: Nella circolare ABI di Serie Tecnica n. 19 del 2 dicembre 2015 sono presenti indicazioni su come
integrare il mandato SEPA Direct Debit Core nel caso di autorizzazioni relative ad operazioni SDD
finanziario o ad importo prefissato. Tra queste indicazioni è previsto, nel caso di SDD ad importo
prefissato, che sia indicato l’importo addebitabile.
Si chiarisce inoltre che nel caso di migrazione allo schema SDD ad importo prefissato di vecchie deleghe
RID il PSP del Pagatore effettua la conversione da delega RID a mandato SDD ad importo prefissato a
ricezione della prima disposizione SDD che risulti valorizzata nel rispetto delle regole convenzionali
previste per la continuità delle deleghe. Nella disposizione il Beneficiario avrà cura di indicare l’importo
prefissato che caratterizzata la delega RID sottoscritta dal pagatore (viceversa, e cioè se l’importo indicato
nella disposizione SDD ad importo prefissato è diverso da quello che caratterizzava la delega IRD ad
importo prefissato la disposizione viene rifiutata dal PSP.
Nel caso di nuovi mandati SDD, l’importo prefissato è indicato nel mandato sottoscritto dal pagatore e:
a) se il beneficiario non aderisce al servizio SEDA o aderisce al modulo “base” del servizio SEDA, l’importo
prefissato indicato sul mandato è comunicato dal Beneficiario nella prima disposizione SDD ad importo
prefissato (e poi registrato dal PSP del Pagatore che effettua successivi controlli di coerenza);
b) se il beneficiario aderisce al modulo avanzato del servizio SEDA il PSP del Pagatore potrà anche
registrare l’informazione nei propri archivi ma i tracciati SEDA al momento non trasportano questa
informazione con la conseguenza che il processo è il medesimo descritto alla lettera a).
30) Ci risulta che ieri si è tenuta una riunione CBI con le principali banche consorziate durante la quale è
emersa l'esigenza di mantenere aperta la circolazione dei RID arricchiti anche post end-date. Potete
confermare?
Risp: Per quanto riguarda la veicolazione dei RID “arricchiti”, le Banche Passive potranno decidere se
accettarne la circolazione, fino a data da definire, oppure rifiutarne l’esecuzione già dal 1° febbraio p.v...
31) Altra domanda tecnica sull'esportazione SDD XML: esiste qualche validatore per i file generati che possiate
raccomandare?
Risp.: No, il Consorzio non fornisce indicazioni in tal senso, tali strumenti sono di competenza dei singoli
Consorziati / Prestatori Servizi di Pagamento. Per agevolare la clientela nella strutturazione dei file xml è
disponibile, nella sezione "Standard" del portale consortile, il manuale di guida per gli utenti (STUS-MO001).
8
32) Un'impresa beneficiaria che ha in essere mandati di addebito SDD Core e/o B2B con i suoi clienti (anche
consumatori finali privati), è tenuta a comunicare loro il passaggio allo standard XML? con quali modalità
e in che tempi?
Risp: A fronte dell’obbligo di utilizzare il formato ISO 20022 XML le imprese (beneficiarie di SDD) non sono
tenute a darne comunicazione ai loro clienti pagatori.
33) Lo schema “SDD Core” non prevede in nessun caso la facoltà di rimborso per il debitore di una transazione
SEPA DD autorizzata?
Risp.: Si conferma che lo schema SEPA Direct Debit Core prevede in capo al pagatore la possibilità di
chiedere il rimborso di operazioni autorizzate entro 8 settimane successive alla data di addebito. Ciò
tuttavia, nelle more della definizione di uno schema paneuropeo ad hoc che– al ricorrere di certe
condizioni – escluda il diritto di rimborso delle operazioni autorizzate, su indicazione del Comitato
Pagamenti Italia sono state definite le due nuove varianti di servizio dello Schema SDD Core (SDD
finanziario e SDD ad importo prefissato) di cui alla circolare ABI di Serie Tecnica n. 19 del 2 dicembre 2015.
Per queste due varianti del servizio SDD Core è previsto che - al ricorrere di specifiche condizioni e in
presenza di un accordo tra le parti interessate, non sia applicata la disciplina del diritto di rimborso per
operazioni autorizzate, esercitabile dal pagatore entro 8 settimane dal loro addebito.
34) SDD: Tag tipo sequenza, obbligatorio? controlli sul contenuto?
Risp.: Se il dubbio attiene alla valorizzazione del tipo sequenza della disposizione SDD (elemento 2.15 +++
Sequence Type che accoglie l’attributo AT-21 “The transaction type”) inviata per effettuare la migrazione
di una delega RID di nicchia ai servizi SDD finanziario e SDD ad importo prefissato allora si chiarisce che il
tipo sequenza dovrebbe essere valorizzato con “first” sebbene i PSP dei Pagatori debbano predisporsi per
gestire anche i valori “Recurrent” o “Last”. Si evidenzia peraltro che nella versione 9.0 dello Scheme
Rulebook SDD Core, che entrerà in vigore il 20 novembre 2016, viene introdotta una semplificazione
prevedendo come opzionale il tipo sequenza “first”. Si ricorda inoltre che con decorrenza dal 6 aprile 2015
sono stati equiparati in ambito nazionale i tipi sequenza “first” e “recurrent” con la conseguenza che i PSP
non stornano eventuali disposizioni SDD per non corretta valorizzazione del tipo sequenza da parte del
Beneficiario.
35) La eventuale conversione delle disposizioni presentate dopo il 01/02/2016 è assimilabile all'attuale
SEDA?
Risp.: Il servizio SEDA è un servizio opzionale aggiuntivo degli schemi di addebito diretto Sepa che consiste
nello scambio preventivo fra l’azienda creditrice e la Banca del debitore, attraverso la Banca di
Allineamento, di flussi elettronici relativi alle informazioni contenute nei mandati SDD.
Pur essendo tecnicamente possibile convertire flussi AL-EF “arricchiti” in flussi SEDA, a partire da una
prossima data i flussi AL-EF per le nuove domiciliazioni saranno scartati dalla rete CBI, per cui si invitano
le aziende aderenti alla procedura SEDA a pianificare sin da subito la migrazione ai formati SEDA XML
9
nativi per coglierne appieno il valore addizionale (solo per citare un esempio, mediante le conversioni non
è possibile accedere alle funzioni di variazione del dato Creditor Identifier).
36) Per quanto riguarda il tracciato delle disposizioni d’incasso SDD, come bisogna gestire il caso in cui
l’ordinante abbia due conti correnti? Nel tracciato xml devono esserci due blocchi <PmtInf> (uno per ogni
conto corrente)? Oppure devono esserci due blocchi <CBIEnvelSDDReqLogMsg> e quindi nel blocco
<PhyMsgInf> bisogna specificare 2 nel tag <NbOfLogMsg>?
Risp.: Nel caso in cui l’ordinante abbia due o più conti correnti di incasso è necessario inserire due o più
blocchi <PmtInf>.
37) Per richiedere il CID per una azienda che non intende avvalersi di SEDA si usa il messaggio A10 tipo
procedura ALL, corretto?
Risp.: Si conferma che la richiesta di censimento nell’anagrafica CRI000 di un codice Creditor Identifier
dedicato all’incasso di addebiti SDD finanziario o SDD ad importo prefissato viene effettuata tramite la
procedura RAC (messaggio A10). All’interno del medesimo messaggio si può specificare se il codice
Creditor Identifier dedicato vuole aderire o meno al servizio SEDA.
38) Per quanto riguarda gli esiti degli SDD, se viene inviato il flusso xml, il flusso di ritorno degli esiti è solo
xml, oppure può essere convertito nell'attuale formato txt?
Risp.: Vedasi al riguardo risposta 15.
39) In cosa consiste il servizio SEDA?
Risp.: Il servizio SEDA è un servizio opzionale aggiuntivo degli schemi di addebito diretto paneuropei (SEPA
Direct Debit Core e SEPA Direct Debit Business to Business) definito dalla comunità bancaria italiana in
risposta alle esigenze manifestate dalle imprese e dalle relative rappresentanze che consente di
mantenere, nel contesto SEPA, le funzionalità offerte dalla procedura di Allineamento Elettronico Archivi
RID. Per ulteriori informazioni in merito al servizio SEDA si rinvia alla documentazione disponibile sul sito
www.sepaitalia.eu (sezione Area AOS e sottosezione AOS SEDA).
40) Bisogna fare un censimento codice SIA con messaggio A01 e poi una variazione con msg A10 CRI per i tipi
servizio finanziario ed importo fisso?
Risp.: Le aziende che decidono di avvalersi dei servizi SDD finanziario e SDD ad importo prefissato che
sono già censite nell’archivio RAC azienda con uno specifico codice SIA possono chiedere il censimento
nell’anagrafica CRI000 dei codici Creditor Identifier dedicati ai servizi SDD finanziario e ad importo
prefissando inviando solo il messaggio A10 della procedura RAC ALLIN. Se invece l’azienda non è censita
nell’archivio RAC aziende, prima del censimento in CRI000 dei codici dedicati alle citate variante del
servizio SDD, deve inviare una richiesta di censimento tramite messaggio A01 della procedura RAC AZI.
10
41) Esiste un tool per validare file sct xml?
Risp.: Il Consorzio CBI definisce le regole tecniche ed i kit di diagnostica per i soggetti veicolatori del
circuito, tuttavia non offre servizi applicativi di diagnostica centralizzati. Tali funzionalità sono riservate
alla sfera competitiva degli Istituti Finanziari consorziati.
42) Ciò che guida la creazione del bonifico SEPA in xml è il paese del fornitore o il paese degli appoggi bancari
del fornitore?
Risp.: Ciò che guida la creazione del bonifico è la banca di destinazione (unitamente alla divisa),
contenuta nel codice IBAN (dato univoco di identificazione del beneficiario ai sensi della PSD).
A titolo esemplificativo:
 Se il fornitore ha sede legale in US, Paese della Banca di destinazione GB o FR (IBAN relativo) e viene
pagato in EUR, si effettuerà un bonifico SEPA  intra UE, EUR è domestico
 Se il fornitore ha sede legale in GB, Paese della Banca di destinazione US (IBAN o altro numero di
conto, es. ABA) e viene pagato in EUR, si effettuerà un bonifico estero EXTRA SEPA  extra UE,
EUR è estero
 Se il fornitore ha Banca di destinazione anche intra UE ma deve essere pagato in divisa, si effettuerà
un bonifico estero EXTRA SEPA  intra UE (extra UE), non EUR è estero.
43) Assegni e bonifici per cassa previsti nel precedente tracciato CBI che trattamento avranno in relazione al
tracciato XML SEPA?
Risp.: I bonifici per cassa, effettuati direttamente con versamento di contanti allo sportello bancario per
coloro che non hanno un conto corrente, sono soggetti all’obbligo di migrazione. Per quanto riguarda la
componente assegni del tracciato PORTING PC-EF, questa rimarrà operativa non essendo soggetta
all’obbligo di migrazione; i clienti potranno decidere di utilizzare la componente XML previa verifica con
la propria banca di riferimento.
44) E’ previsto che i clienti possano ricevere l'inoltro del flusso .xml dei bonifici ricevuti dalla propria banca?
(intesi come esiti in formato .xml)
Risp.: La funzione di Bonifico XML CBI prevede la possibilità per il mittente del pagamento di richiedere
alla propria banca l’invio di due tipologie di esiti: un esito all’ordinante, che viene inviato al mittente
stesso, ed un esito al beneficiario che può essere inviato al creditore del bonifico o ad una terza parte non
coinvolta nel pagamento (in genere per specifiche esigenze normative, es. Monitoraggio Grandi Opere).
Entrambi gli esiti vengono inviati in corrispondenza dell’addebito in conto corrente, secondo il formato
Status Report ISO XML declinato dal Consorzio CBI.
45) In caso di Bonifico a Fornitore Extra UE non area SEPA cosa useremo? il vecchio tracciato CBI BON in
formato ASCII (di testo a record fissi)?
Risp.: Come detto durante il webinar, dal 1° febbraio 2016 è possibile disporre bonifici facenti riferimento
all’operatività extra-SEPA (Paesi destinatari non ricompresi geograficamente in area SEPA e/o operazioni
11
in divisa diversa da Euro) attraverso il tracciato Porting PE-EF (utilizzabile ancora almeno fino al febbraio
2017, da confermare) ovvero mediante la nuova funzione di Bonifico Estero XML, che sostituirà in futuro
il tracciato PE-EF attualmente in uso.
46) Prevedete modifiche alla SEDA per gestire l'importo del mandato rilasciato presso il PSP (nel caso di SDD
a importo prefissato)?
Risp.: No, al momento non sono previste modifiche dei tracciati SEDA per lo scambio dell’informazione
relativa all’importo prefissato del mandato, tra PSP del Pagatore e Beneficiario. Si valuterà se apportare
questa modifica in futuro (attualmente non è pianificato un intervento di questo tipo).
47) SDD Finanziario e SDD ad importo prefissato introducono variazioni tecniche al flusso xml da utilizzare o
utilizzano lo schema xml CBIBdySDDReq.00.01.00?
Risp.: Non sono al riguardo previste modifiche dei tracciati XML CBI. Gli SDD Finanziari e ad importo
prefissato utilizzano il medesimo schema xml degli altri SDD in quanto l’identificazione da parte delle
banche domiciliatarie avviene sulla base delle regole convenzionali definite da ABI circa la valorizzazione
ad hoc del Creditor Identifier, in modo del tutto trasparente per i flussi CBI.
48) Tra le informazioni gestite c'è anche il 'Codice CUC'. Si tratta di codifica ulteriore rispetto al mittente SIA?
Risp.: Il codice CUC è il Codice Univoco CBI che consente di identificare univocamente tutti i soggetti
facenti parte della community CBI (clienti, banche, nodi di accesso alla rete). Esso differisce dal codice SIA
ma è legato a quest'ultimo secondo una corrispondenza biunivoca presente nel Directory CBI, che
rappresenta l'anagrafica centrale di riferimento utilizzata anche per l'indirizzamento dei messaggi sulla
rete CBI. Il codice CUC è utile quindi all'identificazione del solo mittente dei flussi e non a quella del Debtor
(Ordinante, titolare del c/c di presentazione) che compare nel regolamento dei fondi, o di altri soggetti.
Il Mittente (azienda) CBI, abituato a valorizzare il codice SIA, è sicuramente già associato al suo CUC
(presente nella contrattualistica di riferimento cliente-banca), che rappresenta formalmente un codice
alfanumerico di lunghezza pari ad 8 caratteri e viene attribuito automaticamente dalle banche proponenti
alla firma del contratto CBI.
49) Ci sono indicazioni / suggerimenti per i casi di pagamento in ambito di appalti pubblici, cioè nei casi in cui
è richiesto di evidenziare nel pagamento i codici CIG e CUP. In particolare, ci sono suggerimenti per essere
certi che tali codici non vengano "persi" nei vari passaggi del flusso di pagamento?
Risp.: La domanda non è chiara. Se essa si riferisce alle modalità attraverso le quali possono essere
tracciati i codici CIG e CUP all’interno di una disposizione SEPA Direct Debit, allora si chiarisce che non
risultano ad ABI ulteriori indicazioni oltre quella contenuta nella determinazione dell’AVCP n. del
18/11/2010, in cui si dice che “..il servizio di pagamento RID (rapporti interbancari diretti) attualmente
non consente di rispettare il requisito della piena tracciabilità……” e che “………il SEPA Direct Debit
……….reca un campo libero facoltativo nel quale potrebbero essere presumibilmente ospitati i codici in
parola. Questo strumento non è ancora diffuso: ove divenisse di ampio utilizzo si potrà valutare la sua
concreta adeguatezza a rispettare il requisito della piena tracciabilità”.
12
In assenza di ulteriori chiarimenti da parte dell’Autorità competente (oggi Anac – Autorità Nazionale
AntiCorruzione) i citati codici CIG e CUP potrebbero essere inseriti, alla stregua di quanto previsto per il
SEPA Credit Transfer, nel campo Remittance Information (non strutturato).
50) Dove possiamo trovare una tabella contenente tutti i BIC con partiva iva e codice fiscale delle Banche che
emetteranno fatture SEDA in modo da poter caricare le anagrafiche a fronte delle Fatture IVA SEDA?
Risp.: Sul sito www.sepaitalia.eu” nella sezione AREA AOS/AOS SEDA è disponibile la “Tabella dei
Prestatori di Servizi di Pagamento-PSP aderenti al servizio SEDA”. Questa tabella viene aggiornata su base
mensile. Il 13 novembre 2015 la “Tabella” in validità è stata aggiornata con le informazioni relative al
codice fiscale e al codice IVA di ciascun PSP. Più in generale la versione pubblicata il 13 novembre contiene
tutti i dati necessarie alle aziende per censire i PSP nel proprio “archivio fornitori”. Diversi PSP non hanno
ancora fornito il proprio C.F. e la propria partita IVA e quindi in questi giorni saranno pubblicate versioni
aggiornate della “Tabella”.
51) Per quanto riguarda la necessità di recuperare il BIC dalle coordinate IBAN fornite dal cliente, se la Banca
ha nel proprio Home Banking il campo BIC facoltativo (nella schermata di inserimento del Bonifico), questo
campo può rimanere facoltativo o deve essere completamente eliminato?
Risp.: II vincolo normativo scattato dal 1° febbraio 2016 riguarda l’obbligo dei PSP di non chiedere agli
utilizzatori dei servizi di pagamento il codice BIC e nulla è detto in merito all’eliminazione o meno di questo
campo nelle interfacce banca-cliente. Non sappiamo se e in che modo i PSP adatteranno l’home banking
in relazione alla modifica regolamentare intervenuta a febbraio 2016. Segnaliamo, per completezza, che
le Implementation Guidelines dello schema SEPA Credit Transfer valide per la tratta cliente-banca che
rimaste valide anche dopo il 1° febbraio 2016 mantengono questo campo come facoltativo e che, al pari,
anche le linee guida per la definizione dei Mandati SEPA manterranno la possibilità di valorizzare il codice
BIC del PSP del Pagatore come facoltativo (il codice BIC è d’altronde richiesto obbligatoriamente anche
dopo il 1° febbraio 2016 per le operazioni non-EU/non-EEA).
52) Siamo nel progetto di monitoraggio MGO (Monitoraggio Grandi Opere EX DELIBERA CIPE 15/2015), è già
possibile sapere in quale campo del messaggio XML dovremo inserire la causale MDO?
Risp.: Il campo del bonifico nel quale inserire la stringa chiave, che contiene anche la causale MGO, è
“Remittance Information/Unstructured” (Informazioni di riconciliazione non strutturate). Per ulteriori
approfondimenti relativi all’utilizzo della funzione ai fini del Monitoraggio finanziario è possibile scaricare
l’apposito Vademecum per le aziende pubblicato sul portale CBI nella sezione dedicata al Monitoraggio
finanziario (cfr. infra).
http://www.cbiorg.eu/Engine/RAServeFile.php/f/Documenti/Monitoraggio%20Finanziario/Soluzione%2
0CBI%20per%20monitoraggio%20finanziario%20-%20v.00.03.00%20Vademecum%20azienda.pdf
53) Gestione del tipo sequenza e sua obbligatorietà (FIRST e RECURRENT), come avvengono?
Risp.: Si veda al riguardo la risposta a domanda n. 34.
13
54) In caso di presentazione cartaceo o su supporto magnetico, come viene identificato il momento di
ricezione ai fini della conversione in XML?
Risp.: il momento di ricezione dipende dagli applicativi/procedure interne in essere tra impresa e PSP; in
tale ottica è opportuno che ci sia adeguata trasparenza nei rapporti tra le parti.
55) Riscontriamo che non tutti gli home banking messi a disposizione delle imprese, siano già aggiornati e
pronti a ricevere solo il formato XML ISO.
Risp.: II Consorzio CBI non ha diretto presidio su tutti i prodotti di home banking delle banche italiane,
tuttavia preghiamo di segnalare eventuali casi di sorta a chi di dovere (Ufficio Servizi e Sistemi di
Pagamento ABI, Consorzio CBI) per poter avviare le opportune indagini presso il PSP interessato.
56) Riguardo al codice CUC, qualche home banking, nel caso di contratto "multiutenza”, esige un codice CUC
diverso dal caso "monoutenza".
Risp.: Il codice CUC è assegnato dalla Banca Proponente all’attivazione di un contratto multibanca
nell’ipotesi che il cliente operi nell’ambito del circuito CBI. Qualora il cliente richieda di operare in
monobanca o nell’ambito di un circuito chiuso offerto da un gruppo bancario potrà naturalmente
utilizzare gli standard xml CBI inserendo nel campo destinato al CUC (mittente logico della distinta) un
CUC fittizio, il codice SIA (eventualmente con tre zeri in testa) o altro codice da concordare in ogni caso
con la propria banca di riferimento. Nel caso di operatività limitata così descritta non è assolutamente
necessario, ed anzi è sconsigliato, che la Banca Proponente censisca il cliente sul Directory CBI, a meno di
casi particolari (es. registrazione per i soli servizi end-to-end di gestione documentale).
57) Nel caso in cui una banca si avvalga di un centro servizi per la lavorazione delle presentazioni/distinte
inviate dal cliente tramite dischetto/file, occorre che i tracciati siano già XML oppure possono essere
convertiti dal centro servizi?
Risp.: La fattispecie richiamata (banca che si avvale di un centro servizi per la ricezione degli ordini di
pagamento) sembra riconducibile al caso di prestazione di servizi di conversione da parte dello stesso
PSP (tramite soggetto terzo); tale attività può essere svolta dal PSP in regime di competizione con altri
soggetti anche non finanziari, separatamente dall’offerta del servizio di pagamento. Resta ferma in ogni
caso l’esigenza che, anche in tale circostanza, la conversione avvenga prima dell’autorizzazione del flusso
dispositivo, ovvero prima del “momento di ricezione” dell’ordine di pagamento.
58) Volevo avere la conferma che NON è necessario migrare a SEPA le RIBA, ma che queste continueranno
ad essere operative come ora.
Risp.: Come indicato nell’allegato al Provvedimento della Banca d’Italia del febbraio 2013 recante
istruzioni applicative al Regolamento UE 260/2012, le RI.BA (insieme a MAV e RAV e bollettini bancari e
14
postali) non sono soggetti all’obbligo di migrazione ex art 5 e 6 del Regolamento e continueranno a
essere operative. In considerazione dell’opportunità di perseguire la maggiore uniformità possibile con
gli schemi SEPA, il citato Provvedimento (art. 9) prevede l’avvio di un processo di razionalizzazione dei
servizi di incasso e pagamento attualmente “fuori ambito” SEPA.
59) Il codice CUC identifica l'Ordinante (il titolare del c/c di accredito) oppure identifica la banca proponente
(colei che si occupa dell'invio del tracciato delle disposizioni d'incasso SDD)?
Risp.: Il codice CUC (Codice Univoco CBI) identifica tutti i soggetti registrati nella anagrafica generale del
Servizio CBI: banche, clienti, soggetti veicolatori, terze parti. Nelle presentazioni XML è
obbligatoriamente richiesto per il solo soggetto Mittente dei flussi (che può differire dall’Ordinante)
essendo in relazione biunivoca con il relativo codice SIA contrattualizzato dalla Banca Proponente.
60) Nel caso in cui l'ordinante sia titolare di 2 c/c di accredito (uno postale e uno bancario), il codice CUC è
uno solo (ovvero identifica l'ordinante), oppure in questo caso sono due (uno che identifica la banca e
l'altro che identifica la posta)?
Risp.: Si veda risposta precedente: il CUC (assimilabile al codice SIA) è un codice unico per ciascuna
postazione Mittente dei flussi, ed è valido sia nei confronti della Banca Proponente che lo censisce in
CBI (una ed una sola per ogni CUC) che verso tutte le altre banche “passive” presso cui il cliente detiene
rapporti di conto, oggetto di movimentazione tramite il Servizio CBI.
61) Esiste una piattaforma ufficiale di test per permetterci a fronte di un invio SDD in standard ISO XML,
ottenere un flusso di ritorno congruente e formalmente valido?
Risp.: Tale facility è da ricercare esclusivamente in ambito competitivo, presso i singoli PSP consorziati;
il Consorzio CBI definisce le regole tecniche/normative e supporta le richieste di assistenza interpretativa
ma non fornisce alcuna soluzione diagnostica e/o tool centralizzati.
62) La versione definitiva dei tracciati degli esiti SDD è la 00.01.00? Le banche sono obbligate a restituire il
tracciato con l'ultima versione oppure possono restituire tracciati con versioni più vecchie
Risp.: Nell’ambito del circuito CBI, con riferimento agli esiti SDD, possono essere veicolati solo file XML
aggiornati all’ultima versione ovvero la 00.01.00. Pertanto è obbligatorio per le banche adeguarsi a tale
formato.
63) Il codice 00.04.00 è l'unico standard? Alcuni Istituti richiedono che in testata del file ci siano riferimenti
solo a 001.001.03 o 04. Alcuni inoltre richiedono ancora obbligatoriamente BIC e tag che non sono
previsti nello 00.04.00. Come ci si deve comportare di fronte a questa situazione?
Risp.: La versione attualmente in vigore del bonifico XML SEPA, pubblicata in data 20/11/2015, è la
00.04.00 e si basa sul messaggio ISO20022 pain.001.001.03. Le banche, nell’ambito della comunità CBI
(rete multibanca), devono adeguarsi ai suddetti standard di payment initiation.
15
64) Il tracciato degli esiti SDD, dopo quanto tempo viene reso disponibile?
Risp.: Gli esiti SDD corrispondono agli Status Report negativi “di merito” (messaggi 6, 8), veicolati in caso
di rifiuto, storno e/o insoluto. Per questo motivo, le tempistiche di ritorno dipendono dalle scadenze
associate al pagamento e sono variabili.
65) Ad ogni invio di disposizioni di incasso SDD corrisponde sempre un solo tracciato di ritorno degli esiti
oppure gli esiti relativi alla stessa distinta, possono essere restituiti in tranche diverse?
Risp.: Per i motivi di cui sopra possono essere restituiti in tranche diverse, mantenendo sempre i
riferimenti della distinta originaria al fine di garantire la riconciliazione tra esiti e disposizioni.
66) Esiste un limite massimo di importo nelle disposizioni di incasso SDD?
Risp.: Non esiste alcun limite di importo, fatta eccezione per il limite teorico da schema di Eur
999999999.99 (1 miliardo di Euro).
67) Dove posso trovare CBISgnInf.001.04.xsd? Non riesco a trovarlo nei documenti tecnici su http://www.cbiorg.eu/. A cosa serve?
Risp.: Lo schema CBISgnInf.001.04.xsd, contenente la firma digitale secondo le specifiche CBI, è presente
nella documentazione di parte generale. L’archivio è pubblicato sul sito consortile CBI al seguente
indirizzo
(“Aspetti
generali
relativi
ai
Nuovi
Servizi
CBI”):
http://www.cbiorg.eu/Engine/RAServePG.php/P/255010010312.
68) Ci sarà il passaggio in xml del tracciato RH giornaliero ?
Risp.: Il tracciato xml corrispondente agli attuali RH è già pubblicato sul sito web del Consorzio CBI (sotto
la denominazione di Rendicontazione XML Giornaliera), ma non vi è alla data alcun obbligo di utilizzo né
di erogazione da parte delle banche. Seguirà dal 2017 in poi un percorso di graduale adozione
obbligatoria da parte dalle banche consorziate (su richiesta della clientela), al fine di poter in futuro
dismettere le attuali funzioni RH ed EC, introducendo come novità una funzione XML Intraday
(Infragiornaliera).
69) Ho un problema con un SDD. La banca assuntrice accetta il file e lo invia nel flusso bancario per l’incasso,
ma la banca del cliente/debitore non paga perché essendo sia la banca che il debitore spagnoli non
accettano il file in quanto mancante dell’indicazione della città del beneficiario straniero (straniero per
loro in quanto Italiano) <TwnNm> 2.6.2.7 Città, facente parte del nodo <Cdtr> Creditor. Vorrei sapere se
è un comportamento considerato “prassi normale” o forse un possibile errore della banca straniera.
Risp.: ogni Paese europeo potrebbe avere differenti norme antiriciclaggio o di contrasto all’illegalità. In
questo caso sembra che le banche spagnole non accettino SDD privi della indicazione della città del
creditore. La regola attuale delle linee guida EPC prevede che la Banca assuntrice debba veicolare la città
16
del beneficiario solo se ricevuta dal cliente. Non è obbligata quindi a valorizzare tale informazione nel
flusso SDD interbancario sulla base dei dati presenti nei propri archivi.
Pertanto la soluzione potrebbe essere quella di suggerire al cliente che incassa tramite SDD su banche
spagnole di indicare sempre la città del beneficiario nel blocco Postal Address (dato presente
facoltativamente nello standard CBI e quindi utilizzabile a tale scopo).
70) Gli ultimi tracciati Sepa SDD sono Incassi SEPA Direct Debit 22-10-2014?
Risp.: La versione attualmente in vigore dei tracciati SDD è la 00.01.00 pubblicata il 15/07/2015.
-------------------------End --------------------------------
19/02/2016
17