FAQ su SEPA

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Approfondimenti
 
 

FAQ su SEPA

Informazioni di carattere generale
 
Area Incassi SDD (SEPA Direct Debit)
 
Area Incassi SEDA (SEPA Electronic Database Alignment)
 
Area Pagamenti SCT (SEPA Credit Transfer)
 
 

Informazioni di Carattere Generale

In questo paragrafo si da risposta alle domande più frequenti di carattere generale, pervenute da Clienti CBI, riguardanti la c.d. SEPA end date con particolare focus sulle attività del Consorzio CBI.

 
1. La SEPA end date del 1° febbraio riguarda sia PSP che USP?

Il Consorzio CBI consiglia di rivolgere il quesito agli uffici competenti ABI ovvero alle proprie banche di riferimento.

 

  Focus sul CBI

 

Dal 1° febbraio 2014 migrano a SEPA le procedure interbancarie relative a: Bonifico al dettaglio (BON), RID Ordinario, RID Veloce.

 

Per quanto riguarda la tratta CBI, operativamente la clientela CBI dal 1° febbraio 2014 ha solo le seguenti possibilità:

 

a)    utilizzare da subito i tracciati CBI SEPA XML (cfr. ultimi manuali pubblicati sul portale consortile nell'area prossime release). Il Consorzio consiglia fortemente tale soluzione, che permette di adeguarsi al Regolamento evitando un duplice impatto sui processi e sui sistemi aziendali. 

 

b)   utilizzare tracciati porting (cfr. ultimi manuali pubblicati sul portale consortile) con lo scopo di impartire disposizioni SEPA, a seguito di accordi di conversione presi con gli istituti di riferimento. Questa possibilità è perseguibile comunque fino al 1° febbraio 2016, data dalla quale anche i clienti dovranno obbligatoriamente adeguarsi al formato XML.

 

In ogni caso, indipendentemente dalla scelta effettuata (porting o XML nativo), si sottolinea l'urgenza di intervenire in chiave di adeguamento dei tracciati, in particolare per ciò che riguarda il mantenimento in operativo dei RID attivi, che dovranno in ogni caso essere trasposti nelle procedure SDD già dal 1° febbraio p.v..

 

Tutta la manualistica necessaria alle aziende in ambito CBI è disponibile nelle apposite sezioni del sito CBI.

 
 
2. Per usufruire dei servizi di conversione verso SEPA sarà sufficiente utilizzare le nuove versioni dei tracciati porting?

Con l'obiettivo di favorire nella fase transitoria, febbraio 2014 - gennaio 2016, i processi di conversione dagli attuali servizi di tipo "PORTING" ai nuovi servizi XML SEPA compliant, il Consorzio CBI ha integrato i manuali delle funzioni Porting (BON, R.I.D. e A.E.A.) con nuove note o dati, questi ultimi nella maggior parte dei casi definiti come facoltativi.

 

L'utilizzo di tali tracciati al fine di impartire disposizioni SEPA deve essere comunque concordato tra la clientela e la banca che offre il servizio di conversione (in ambito competitivo il servizio può essere offerto sia dalle Banche Proponenti sia dalle Banche Passive).

 

Occorre rilevare a tale riguardo che la facoltatività dei nuovi campi inseriti, in particolare nei manuali CBI-RID e CBI-AEA, è stata prevista esclusivamente con la finalità di non interferire in area competitiva sul rapporto Cliente - Banca, tuttavia i dati veicolati da tali campi sono sostanzialmente necessari per le presentazioni denominate in Euro che dovranno essere obbligatoriamente regolate sul canale SEPA (in particolare, quindi, SDD e SEDA).

 

Per tale ragione riveste fondamentale importanza concordare con la propria banca le modalità con cui operare le trascodifiche, prima di inviare flussi Porting destinati ad essere convertiti in disposizioni SEPA.



  • i 15 Paesi della UE che utilizzano l'euro (Italia, Germania, Francia, Spagna, Portogallo, Grecia, Austria, Finlandia, Irlanda, Paesi Bassi, Belgio, Lussemburgo, Slovenia, Cipro e Malta);
  • i 12 Paesi della UE che utilizzano una valuta diversa dall'euro sul territorio nazionale ma effettuano comunque pagamenti in euro (Regno Unito, Svezia, Danimarca, Estonia, Lettonia, Lituania, Polonia, Repubblica Ceca, Slovacchia, Ungheria, Bulgaria, Romania);
  • Altri 4 paesi: Svizzera, Norvegia, Islanda, Liechtenstein.
 
 
3. ll codice BIC sarà obbligatorio anche post end date?

Sarà obbligatorio post end-date solo per le operazioni CBI cross-border, e solo fino al febbraio 2016. Il Consorzio CBI consiglia di approfondire il quesito presso gli uffici competenti ABI ovvero presso le proprie banche di riferimento.

 
 
4. Nel caso di utilizzo dei tracciati Porting per impartire disposizioni SEPA, i flussi di ritorno in che formato saranno prodotti?

I principi guida indicati dal Consorzio prevedono il rispetto del workflow. Se il cliente utilizza i tracciati a record fissi dovrà ricevere esiti e ritorni corrispondenti nel formato a record fissi.

 

Ciò non toglie che, in base a scelte ricadenti in ambito competitivo, venga trasmesso al cliente dalla banca proponente sia il formato xml che porting. Naturalmente questo potrà avvenire solo nel caso in cui sia la Banca Proponente a operare servizi di conversione per la clientela in questione.

 

Per tale ragione il Consorzio CBI consiglia di rivolgere il quesito alle proprie banche di riferimento.

 
 
5. Il Consorzio CBI offre servizi di validazione dei tracciati porting e xml?

Il Consorzio non può al momento rendere disponibile una funzione centralizzata di controllo dei file o di simulazione degli scambi, in quanto tali funzioni sono di competenza dei singoli Consorziati / Prestatori Servizi di Pagamento.

 

Tuttavia per agevolare la clientela nella strutturazione dei file xml è disponibile, nella sezione "Standard" del portale consortile, il manuale di guida per gli utenti (STUS-MO-001).

 
 
6. Gli standard xml SCT e SDD CBI sono ISO compliant?

Gli standard dei nuovi servizi CBI nascono dal Customer-to-Bank ISO20022 e sono variamente declinati in funzione delle specificità di ciascun servizio. A titolo esemplificativo e non esaustivo, le specifiche CBI del bonifico XML SEPA (versione 00.04.00) si basano sul messaggio ISO20022 pain.001.001.03 e sono compliant al Rulebook SEPA. Il messaggio pain.001.001.03 non è stato utilizzato integralmente, essendo strutturato in maniera tale da poter essere applicabile ad una pletora molto estesa di casistiche e di soggetti.

 

Ne consegue che, al fine di implementare le regole di comunità, il tracciato SEPA Credit Transfer CBI preso ad esempio è un sottoinsieme del succitato messaggio ISO e raccoglie i requisiti necessari alla corretta esecuzione di un bonifico in Italia, come ad esempio la presenza obbligatoria dell'ABI della banca di addebito contenuto nel campo "MmbId" che è invece facoltativo nel tracciato ISO.

 

Gli Standard CBI sono quindi ISO compliant.

 
 
7. Il Consorzio CBI mette a disposizione linee guida di conversione verso formati esteri ISO compliant?

Linee guida di questo tipo non possono essere di competenza del Consorzio CBI.

 
 
8. Nei nuovi standard xml CBI viene richiesto il codice CUC, si tratta di un dato necessario per il regolamento su canale SEPA?


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 e non al regolamento sul canale SEPA.

 

Il mittente 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.


 
 
9. In riferimento ai messaggi da predisporre di clienti va essere sviluppato il messaggio logico o l'intero messaggio fisico?

L'utente CBI deve sviluppare il messaggio logico. Tale messaggio logico, per essere veicolato sulla rete CBI, deve essere corredato di due header la cui struttura è presente nei manuali delle funzioni CBI. Tali header pertanto sono di unica competenza delle banche (Cfr. per ulteriori approfondimenti il documento STUS-MO-001 pubblicato sul sito web consortile www.cbi-org.eu , area generale Standard Tecnici).

 
 
10. È possibile strutturare file xml con più Group Header?

Il Group Header è sempre unico per distinta generata dall'azienda. Sulla rete CBI la banca destinataria (c.d. "Banca Passiva", es. Debtor Agent del SCT e Creditor Agent del SDD) è sempre unica, per ragioni strutturali. Nel caso del SDD, sono previsti anche blocchi di accrediti (Payment Information) multipli, per gestire diverse scadenze nella stessa distinta e non invece per poter variare Istituto Ordinante, che resta sempre univoco per distinta.

                 

Tuttavia in ambito competitivo i clienti potranno verificare con la banca proponente la possibilità di generare un unico file xml con più distinte, quindi Group Header.

 

Per tale ragione il Consorzio CBI consiglia di rivolgere il quesito alle proprie banche di riferimento.

 
 
11. Sono definite regole di comunità nella definizione dei namespace dei file xml CBI?

In merito alla generazione da parte della clientela dei file xml da importare sui front-end di corporate banking, si raccomanda di non utilizzare definizioni personalizzate dei namespace ovvero di utilizzare solo le definizioni CBI di default.

 

A titolo puramente esemplificativo si propongono due casi accettabili di presentazioni xml da parte della clientela, relative alla sola funzione SCT, con namespace correttamente compilati:

Nessuna definizione personalizzata di namespace (opzione consigliata)
Nessuna definizione personalizzata di namespace (opzione consigliata)
 
 
Definizione di namespace secondo naming convention CBI (PMRQ nel caso SCT)
Definizione di namespace secondo naming convention CBI (PMRQ nel caso SCT)
 

Si noti in ultimo che la definizione dei namespace lato cliente non vincola in alcun modo al mantenimento degli stessi, né la Banca Proponente (fatta eccezione per i flussi importati oggetto di preventiva apposizione di firma digitale) per i flussi in seguito inviati su tratta CBI, né la Banca Passiva per i flussi di ritorno (esiti).

 
 
12. Come deve essere utilizzato il blocco FwdgAgt dei file xml SCT CBI?

Il blocco FwdgAgt viene utilizzato (ed è obbligatorio) esclusivamente nel caso di richieste provenienti da Market Place, poiché in tal caso i flussi di ritorno devono essere restituiti non alla Banca Proponente associata al cliente, bensì alla Banca c.d. Gateway operante nel marketplace, affinché questa possa renderli disponibili sul medesimo portale anziché sulla stazione di Corporate Banking del Cliente. Quest'ultimo ovviamente riceverà tale operazione in e/c di addebito, comunque, tramite i flussi di rendicontazione.

                          

Pertanto la Banca Gateway è un caso diverso dalla normale operatività della Banca Proponente, ed è l'unico caso in cui la Banca "mittente" deve essere riportata nei flussi di bonifico, del tutto specularmente a quanto già in uso con i bonifici attuali PC-EF.
 
 
13. Le comunicazioni valutarie relative all'operatività su San Marino, a seguito dell'ingresso in area SEPA, restano obbligatorie?

In caso di IBAN radicato su San Marino le comunicazioni valutarie (CVS) sono obbligatorie solo fino al 30 marzo 2014


Dal 31 marzo 2014 entrerà in vigore la facoltatività dei campi relativi alle comunicazioni valutarie (CVS) per tutte le funzioni cross-border interessate (cfr. manuali in vigore dal 31 marzo 2014). 

Rammentiamo anche come il dato BIC di controparte per le operazioni SCT/SDD verso San Marino non sarà più richiesto da pari data, sulla base delle decisioni assunte da ABI riguardo alla derivazione da IBAN SM (come per IT).



 
 
14. I flussi CBI xml ammettono caratteri speciali come "&" ad esempio nel tag relativo alla ragione sociale?

Nella tratta Customer to Bank, a livello di standard CBI, sono garantiti in coerenza con le Linee guida EPC tutti i caratteri del set latino di base.


Consigliamo a tale riguardo di consultare il manuale "Criteri e regole generali" dei nuovi servizi STPG-MO-001, pubblicato sul portale del Consorzio CBI, all'interno del quale (cfr. par. 11.9, "Caratteri ammessi") è prevista la seguente regola, in perfetto accordo a quanto definito nelle Linee Guida ufficiali dell'EPC:

"L'utilizzo di caratteri aggiuntivi concede alla banca ricevente il diritto di rifiutare il messaggio ricevuto ovvero di convertire tali caratteri secondo quanto presente nel documento EPC217-08 SEPA Conversion Table".


In sostanza, anziché prevedere una limitazione stretta al set di caratteri latini di base, è stata introdotta una regola di maggiore flessibilità che però è legata agli accordi multilaterali, trattandosi di uno schema paneuropeo. Il consiglio generale è quello ivi riportato, ovvero di attenersi per il momento al set latino di base (ovvero convertire all'origine secondo la citata Conversion Table), poiché in caso contrario esiste comunque un diritto di scarto e quindi la possibilità che una banca/PSP ovvero una piattaforma di clearing (CSM) rifiuti l'operazione di pagamento, perlomeno fino a quando non verrà pienamente armonizzato l'utilizzo di caratteri aggiuntivi di comune uso commerciale quali "&" oppure "@" od altri, caratteri che oggi il CBI di norma ammette ma non può garantirne ovviamente la copertura su tutte le molteplici tratte finanziarie e quindi end-to-end al di fuori della propria sfera di azione. Il consiglio di attenersi per il momento ai soli caratteri minimi vale anche in considerazione del fatto che - proprio per le ragioni sopra descritte - l'inserimento di caratteri fuori del set minimo potrebbe comportare risistemazioni manuali e quindi ritardi o impedimenti ad eseguire. 

L'obiettivo finale è comunque quello di estendere il set di caratteri di base SEPA quanto prima possibile, a condizione però che lo stesso venga accettato anche dai CSM di riferimento (es. EBA), ed ove possibile da EPC. Seguiranno gli aggiornamenti del caso.

 
 
15. I manuali Porting ammettono un set di caratteri maggiore rispetto a quelli xml. Cosa accade in caso di conversione verso gli schemi SEPA?

Il set di caratteri PORTING è diverso e più esteso di quello dei Nuovi servizi XML SEPA compliant, che recepiscono UTF-8 (Latino di base). Nel caso di eventuali conversioni (es.: $, @) si raccomanda di trascodificare i caratteri incompatibili secondo il documento EPC217-08 SEPA Conversion Table.


Ad ogni modo si consiglia a tale riguardo di contattare la banca che effettua servizio di conversione.


 
 
16. Il codice CUC non ammette caratteri minuscoli. Ma tale criterio più comportare lo scarto dell'intero flusso?

Analogamente a ciò che accade per i flussi porting attuali, in  cui i codici SIA scritti in minuscolo vengono normalmente scartati, consigliamo di evitare l'inserimento di codici CUC contenenti caratteri alfabetici in minuscolo poiché il dato è case sensitive in lettura, quindi il carattere minuscolo risulta in genere interpretato come un diverso carattere e potrebbe determinare scarti da parte dei soggetti veicolatori CBI.

 

Area Incassi SDD (SEPA Direct Debit)

In questo paragrafo si da risposta alle domande più frequenti, pervenute da Clienti CBI, in relazione alla funzione xml SDD e alla funzione RID a record fissi, con la quale è possibile per i clienti disporre SDD fino al 1° febbraio 2016.

 
1. Come sarà garantita la continuità delle deleghe RID in essere?

Il Consorzio CBI consiglia di rivolgere il quesito agli uffici competenti ABI ovvero alle proprie banche di riferimento.

 
 
2. In caso di presentazioni RID già effettuate con scadenza superiore a 31 gennaio 2014, come sarà garantita la continuità delle deleghe RID in essere?

Il Consorzio CBI consiglia di rivolgere il quesito agli uffici competenti ABI ovvero alle proprie banche di riferimento.

 
 
3. Come farà la clientela a indicare alla propria banca la volontà di convertire in disposizione SDD un flusso Porting?

Innanzitutto sono necessari accordi cliente-banca. Dal punto di vista operativo dovrà utilizzare il record 17, in tutte le disposizioni della distinta.

 

Occorre sottolineare che non è possibile generare tracciati con disposizioni miste, alcune con record 17 e altre senza.
 
 
4. Nel caso di migrazione di deleghe RID a mandati SDD, potrebbe complicato in alcuni casi reperire la data di sottoscrizione mandato. Come bisogna comportarsi in tali casi per valorizzare correttamente il relativo campo del tracciato CBI?

Il Consorzio CBI consiglia di rivolgere il quesito alle proprie banche di riferimento.

 
 
5. Sarà possibile utilizzare il servizio SDD senza aderire a SEDA?


Il Consorzio CBI consiglia di rivolgere il quesito agli uffici competenti ABI ovvero alle proprie banche di riferimento.


 
 
6. Qual è il significato dei valori ammessi nel campo sequence type? In caso di conversione, il relativo campo del tracciato porting può non essere valorizzato?

Il Consorzio CBI consiglia di rivolgere il quesito agli uffici competenti ABI ovvero alle proprie banche di riferimento.

 
 
7. In caso di conversione, il campo creditor identifier del tracciato porting può non essere valorizzato?


Il Consorzio CBI consiglia di rivolgere il quesito alle proprie banche di riferimento.


 
 
8. In caso di conversione, se il tipo record 17 del tracciato RID è presente senza IBAN valorizzato, il flusso è accettato ai fini della transcodifica verso SDD?


Il record 17 è indicatore di presentazioni da regolare su canale SEPA a prescindere dalla valorizzazione dei campi al suo interno, che sarà concordata nell'ambito degli accordi tra i clienti e le Banche che offriranno servizi di conversione su base competitiva.

 

L'IBAN, come tutti i dati integrativi SEPA, è facoltativo ma la nota sulla sua valorizzazione vale come forte raccomandazione perché lo schema SEPA - per l'appunto - lo richiede. Gli accordi bilaterali di cui sopra lo dovrebbero confermare, dovendo disciplinare in generale l'eventuale servizio di conversione offerto.

 

Per tale ragione il Consorzio CBI consiglia comunque di rivolgere il quesito alle proprie banche di riferimento.


 
 
9. In caso di conversione, sarà possibile utilizzare la funzione richiami RID?

I richiami RID, non trovando equivalenza nello schema SDD, sono stati esclusi dalle conversioni, e quindi non sono applicabili ai flussi SDD, caratterizzati per l'appunto dal record 17.

 

Il Consorzio CBI consiglia comunque di rivolgere il quesito alle proprie banche di riferimento.
 
 
10. In caso di conversione, come sarà indicato l'identificativo del mandato non essendoci un campo corrispettivo nel tracciato porting?

Gli utenti che non passeranno da subito a xml avranno a disposizione gli attuali RID (e AEA); su entrambi non è stato inserito il nuovo identificativo che occupa fino ad un massimo di 35 caratteri potenziali ma è stata lasciata, per continuità, esclusivamente la attuale c.d. tripletta (pos. 92-113 record 10 tracciato RID, che è l'unico ID - di 22 caratteri - che i creditori gestiscono se non hanno già operato la migrazione). La c.d. tripletta sarà poi "trasferita" nel campo Mandate Id della presentazione SDD, come da regole ABI, che essendo di 35 lo contiene senza problemi.



Il Consorzio CBI consiglia comunque di rivolgere il quesito alle proprie banche di riferimento.

 
 
11. Nel caso di disposizioni di pagamento a persone giuridiche, il tracciato CBI XML SEPA compliant permette di gestire il caso, senza valorizzarne il codice fiscale?

Nel tracciato BON PC-EF, il codice fiscale del "creditore persona giuridica" è un dato facoltativo e valorizzabile nel caso specifico. Anche nel caso di utilizzo del formato xml CBI SEPA Credit Transfer, la casistica di bonifici a persone giuridiche è ugualmente gestibile.

 

Infatti, con riferimento al manuale STIP-MO-001, il tag 2.12.8.3 contiene l'identificativo della controparte - compreso eventualmente quello fiscale - ed è facoltativo.

 
 
12. Con riferimento ai RID finanziari e a importo fisso che non migrano a SEPA fino al 2016, sarà comunque possibile utilizzare da subito il tracciato CBI xml SEPA compliant?

Siamo anzitutto a confermare che un'impresa creditrice che incassa RID finanziari o RID ad importo prefissato ha la possibilità di incassare tali addebiti mediante la procedura nazionale RID fino al 1° febbraio 2016 (in quanto prodotti "di nicchia") come pure, alternativamente, di incassare gli stessi tramite lo Schema SEPA Direct Debit (Core o B2B).

 

Ciò premesso si precisa che laddove la scelta del creditore fosse quella di:

 

·         continuare ad utilizzare il servizio RID (finanziario/ad importo fisso), la presentazione dei flussi d'incasso potrà avvenire utilizzando i canonici flussi CBI-RID non arricchiti, più in generale nulla cambia rispetto alla gestione attuale;

 

·         gestire le autorizzazioni all'addebito riferite a tali RID finanziari/ad importo fisso tramite SEPA Direct Debit, la presentazione dei flussi d'incasso potrà avvenire utilizzando apposito file CBI riferito al servizio SDD nel formato XML o, alternativamente, i file IR-EF (e cioè i tracciati arricchiti che consentono di presentare SDD in formato non XML).

Con riferimento a tale ipotesi siamo peraltro a precisare che a seguito dell'invio di un SEPA DD riferito all'autorizzazione all'addebito del RID finanziario/importo prefissato, i PSP realizzeranno il processo di migrazione automatico di tali autorizzazioni da RID a SEPA e quindi gli addebiti dovranno da quel momento in poi essere gestiti unicamente a valere dello schema SEPA DD (in altri termini non si può immaginare che a valere della medesima autorizzazione l'azienda creditrice possa inviare a volte dei RID e a volte dei SEPA Direct Debit). Deve intendersi che in relazione alla migrazione di un'autorizzazione RID finanziario/ad importo prefissato agli Schemi SEPA DD, tali addebiti verranno gestiti in coerenza con le regole dello Schema SDD (quindi, ad esempio, i termini per l'esercizio della richiesta di rimborso da parte del pagatore indipendentemente dai termini sottoscritti nell'autorizzazione RID diventerebbero 8 settimane nel caso di SDD Core e non possibilità di rimborso nel caso di SDD B2B).

 

Da ultimo, con specifico riferimento alla possibilità per un'azienda di presentare con un unico file CBI sia richieste di addebito diretto RID (finanziario o ad importo prefissato) sia richieste di addebito SDD, siamo a precisare che tale ipotesi non è prevista trattandosi di file distinti per struttura ed informazioni (uno per presentazioni RID, uno per presentazioni SDD in formato XML ed uno per presentazioni SDD in formato non XML).

 

Per ogni ulteriore approfondimento riguardo ad entrambi i punti sopra menzionati, si prega di fare riferimento alla propria banca e/o alla disciplina di ABI in materia.
 

Area Incassi SEDA (SEPA Electronica Database Alignment)

In questo paragrafo si da risposta alle domande più frequenti, pervenute da Clienti CBI, in relazione alla funzione xml AOS SEDA e alla funzione AEA a record fissi, con la quale è possibile per i clienti trasmettere messaggi di allineamento SEDA.

1. Tra i dati aggiunti nel tracciato AEA è presente anche il "tipo mandato", quali sono i valori ammessi e qual è il loro significato?

Il campo indicato è da utilizzare solo in caso di richiesta allineamento SEDA. Individua la tipologia di mandato e, qualora presente, deve  assumere uno dei seguenti valori:

 

·         CORSEDPM;

·         CORSEDEM;

·         COR1SEDPM;

·         COR1SEDEM;

·         B2BSEDPM;

·         B2BSEDEM.

 

Tale attributo indica la modalità di acquisizione (supporto cartaceo o supporto elettronico) del mandato SDD oggetto di allineamento:

 

·         CORSEDPM: mandato core cartaceo;

·         CORSEDEM: mandato core elettronico;

·         COR1SEDPM: mandato core1 cartaceo;

·         COR1SEDEM: mandato core1 elettronico;

·         B2BSEDPM: mandato B2B cartaceo;

·         B2BSEDEM: mandato B2B elettronico.

 

Si precisa che le codifiche relative a "Core1" sono assimilabili alla codifica "Core".
 
 
2. L'utilizzo del record XX nel tracciato AEA sarà obbligatorio a partire dal 1° febbraio 2014?

L'uso del tipo record XX è legato unicamente all'utilizzo dei servizi di conversione verso e da SEDA. Tale servizio è subordinato all'adesione agli schemi SEDA.

 

La funzione AEA non verrà dismessa dopo il 1° febbraio 2014 e potrà essere utilizzata, senza il record XX, per l'allineamento elettronico archivi riferito mandati RID di nicchia.

 
 
3. Come farà la clientela a indicare alla propria banca la volontà di convertire in messaggi SEDA un flusso Porting?

Innanzitutto sono necessari accordi cliente-banca. Dal punto di vista operativo dovrà utilizzare il record XX, in tutte le disposizioni della distinta, per indicare disposizioni SEDA.

 

Occorre sottolineare che non è possibile generare tracciati con disposizioni miste, alcune con record XX e altre senza.

 
 

Area Pagamenti SCT (SEPA CreditTransfer)

In questo paragrafo si da risposta alle domande più frequenti di carattere generale, pervenute da Clienti CBI, in relazione alla funzione xml SCT e alla funzione BON a record fissi, con la quale è possibile per i clienti disporre SCT fino al 1° febbraio 2016.

1. Utilizzando il tracciato porting per disporre SCT, sarà possibile utilizzare tutte le tradizionali causali bancarie?

Il Consorzio CBI consiglia di rivolgere il quesito alle proprie banche di riferimento.

 
 
2. Il tracciato porting PC-EF potrà essere utilizzato anche per disporre SCT in euro verso paesi esteri dell'area SEPA?

Il Consorzio CBI consiglia di rivolgere il quesito alle proprie banche di riferimento.

 
 
3. Negli "Identificativi di una disposizione di pagamento", sono presenti i tag "Identificativo univoco assegnato all'istruzione dal Mittente nei confronti della sua Banca" e "Identificativo URI assegnato dal Mittente": qual è la differenza tra i 2 tag?

l'Instruction Id è quello assegnato dalla azienda al singolo bonifico accluso nella distinta. Equivale all'attuale "progressivo all'interno della distinta" del CBI-BON-001, ed è di livello inferiore rispetto al Message Id (= nome supporto degli attuali flussi).

 

Al contrario dell'attuale identificativo corrispondente nel BON, l'Instruction Id ha una forma libera e non deve necessariamente essere strutturato come numero progressivo, a seconda dei criteri definiti dalla applicazione ERP dell'utente.

 

L'end-to-end Identification è invece utilizzato ai fini di riconciliazione, e viene inserito dal Mittente allo scopo di agevolare i processi di riconciliazione dal lato del beneficiario. Rappresenta l'Unique Remittance Identifier (URI) e può essere rappresentato da una chiave univoca e/o numero di fattura o altro documento commerciale.

 

Il Consorzio CBI consiglia comunque di rivolgere il quesito alle proprie banche di riferimento.

 
 
4. In una distinta SCT è ancora obbligatoria la comunicazione CVS?

E' tuttora obbligatoria sui flussi CBI cross-border, tuttavia verrà a breve rivista. Il Consorzio CBI consiglia di approfondire tale tematica con le proprie banche di riferimento.

 
 
5. Sarà possibile gestire "data esecuzione" e "data valuta" con SCT?


Il tracciato SCT non gestisce la data valuta. Lo standard ISO e la norma europea hanno eliminato da tempo il concetto di data valuta prefissata dal cliente, in quanto assimilata alla data di regolamento.

Il Consorzio CBI consiglia comunque di rivolgere il quesito alle proprie banche di riferimento.


 
 
6. Sarà possibile gestire "data esecuzione" diverse con un unico file SCT?

Ogni distinta può contenere una unica data di esecuzione, per motivi di sintassi strutturali. La possibilità di aggregare due diverse distinte logiche in un unico file fisico deve essere verificata con la propria banca di riferimento.

 

Per tale ragione il Consorzio CBI consiglia di rivolgere il quesito alle proprie banche di riferimento.

 
 
7. In caso di conversione, dal 1° febbraio sarà obbligatorio indicare l'IBAN in disposizioni SCT impartite con tracciato PC-EF?


Dal 1° febbraio p.v. sarà ammesso solo l'IBAN in tutti i casi di disposizione di bonifico (eccetto quindi per le richieste di emissione assegni).

 

Il Consorzio CBI consiglia comunque di rivolgere il quesito alle proprie banche di riferimento.


 
 
8. Il tag RgltryRptg (2.12.13) relativo alle Causali valutarie è obbligatorio solo nel caso di pagamenti verso soggetti diversi da IT?

L'interpretazione di facoltatività dei "Details" del blocco Regulatory Reporting (2.12.13) è corretta, tuttavia la banca ricevente potrebbe in limitati casi effettuare un ulteriore controllo "sostanziale", pertanto non disciplinato dal Consorzio CBI, riguardo al quale il Consorzio stesso non può entrare nel merito.

 

Per tale ragione il Consorzio CBI consiglia comunque di rivolgere il quesito alle proprie banche di riferimento.

 

Peraltro dal 31 marzo p.v. il blocco Regulatory Reporting verrà reso del tutto facoltativo per tutte le funzioni cross-border interessate (SCT, SDD, Bonifico estero PE-EF) in quanto la sottostante disciplina è in via di soppressione con la finalità di assecondare il processo di armonizzazione complessivamente in corso a livello europeo.
 
 
9. Nel tracciato xml SCT come saranno veicolare le causali di esito ovvero bonifico eseguito, non eseguito e stornato (68000)?

In sostanza nello Status Report SCT - a livello di singola transazione - è presente "ACSC", che equivale ad eseguito, o "RJCT", che equivale a rifiutato, e quest'ultimo è accompagnato dalle varie causali ISO. Lo storno (ovvero riaccredito a seguito dell'addebito) non ha una causale unica in SCT nativo , perché i codici che indicano uno storno possono essere ricondotti a diverse "status reason", come ad esempio:


AC03
InvalidCreditorAccountNumber
AC06
BlockedAccount
AC07
ClosedCreditorAccountNumber
 
 
 
10. In ambito SCT, il CUC è un dato obbligatorio?

Il codice CUC è obbligatorio per operare nel circuito multibanca CBI (si trova nel campo Initiating Party = Mittente dei flussi, prima occorrenza).


Peraltro in ambito competitivo (es. monobanca) gli Istituti potrebbero facilitare i clienti non dotati di CUC gestendo in modo diverso tale campo. Per ulteriori approfondimenti è necessario in tal senso chiedere lumi alla propria Banca / PSP di riferimento.

 
 
11. Il tracciato CBI SCT è conforme al tracciato ISO XML CustomerCreditTransferInitiationV03?
Al quesito si fornisce risposta anche nella parte di area generale di queste FAQ. In merito al tracciato SCT CBI in vigore alla data (31 Marzo 2014) il CBI prende a riferimento proprio lo standard CustomerCreditTransferInitiationV03 pubblicato da ISO20022 (di seguito, ISO, cfr. www.iso20022.org). Le versioni ISO utilizzate sono sempre riportate nelle apposite tabelle revisione di tutti i nuovi servizi (file excel dei campi).
L'unico tag "non ISO" utilizzato obbligatoriamente nel CBI - su precisa volontà delle stesse banche consorziate - è il c.d. "tag root", che non faceva parte inizialmente della documentazione ISO e che peraltro risulta di agevole gestione, considerato che in ambito competitivo i PSP possono offrire servizi di facilitazione per gli utenti, convertendo il tag root ISO (destinato ad una pletora di applicazioni) in quello previsto dal SCT CBI.
 
 
 
 
 
 

Consorzio CBI

R.E.A.  N. 1205568 - C.F. e n. Reg. Imp. di Roma 97249640588 - Partita IVA  08992631005