Program SEPA - Buletin Informativ Nr 9_final

PROGRAMUL SEPA

REGIM: Confidenţial Pagina 1 din 27

SEPA (Single Euro

Payment Area) este un proiect european care constă în adoptarea unui set uniform de reguli şi standarde pentru plăţile denominate în euro. Odată cu trecerea la moneda unică, utilizarea acestor

standarde şi reguli va fi absolut necesară derulării activităţii de plăţi interbancare la nivel naţional şi în zona euro.

Băncile comerciale au decis adoptarea acestor standarde şi pentru plăţile în moneda naţională, în anticiparea trecerii la

moneda unică, pornind de la necesitatea utilizării aceluiaşi standard, atât pentru plăţile în euro, cât şi pentru cele în lei, ca o precondiţie a raţionalizării proceselor aferente plăţilor bancare.

PROGRAMUL SEPA

La solicitarea ARB, TRANSFOND a demarat Programul SEPA care are drept obiectiv implementarea unui sistem de compensare conform cerinţelor SEPA EPC, prin transformarea infrastructurii actuale

într-un „Mecanism de Compensare şi Decontare”, capabil să proceseze, pentru

băncile românești, plăți în moneda națională și în moneda euro.

Programul va fi implementat în două etape principale:

1. SEPA-RON (plăți în lei în format SEPA) = adoptarea standardelor SEPA pentru plăți în lei,

2. SEPA-EUR (plăți în euro) = sistemul va procesa simultan plăți în lei și în euro cu decontare în TARGET2.

Cuprins:

Modul de funcționare a aplicației SENT cu capabilități SEPA

Contact: Bucureşti, Bulevardul Ficusului, nr. 1 Tel: 021-201.77.25/ 201.77.14/ 201.77.84

e-mail: [email protected]

Buletinul Informativ Program SEPA:

Buletinul Informativ este destinat exclusiv

participanţilor la sistemul SENT.

Buletinele Informative cuprind informaţii de

natură funcţională şi/sau tehnică apărute în

elaborarea şi implementarea programului

SEPA, având scopul de a ajuta participanţii

în implementarea schimbărilor ocazionate de

adoptarea standardelor SEPA pentru plățile

în lei în cadrul organizaţiilor proprii.

mailto:[email protected]

PROGRAMUL SEPA


Modul de funcționare a aplicației SENT cu capabilități SEPA

Noua aplicație SENT va putea procesa mesajele transmise de băncile participante atât în formatul actual SENT, cât și în format SEPA. Un participant SENT va putea alege ce instrucțiuni și ce format dorește să utilizeze, respectiv:

poate utiliza ambele scheme de debit direct (si cea SEPA si cea actuala), și implicit ambele formate de mesaj

poate utiliza una din schemele de CT (SEPA CT sau cea actuala, deci nu amândouă) poate utiliza mesajele aferente instrumentelor de debit.

Fiecare bancă va stabili instrumentele de plata utilizate si va trimite la Transfond, până la data intrării în producție a noului sistem, formularul de înregistrare a participantului, care va cuprinde și noile instrumente de plată (cele SEPA). Dacă nu aderați la nici o schemă de plată SEPA, nu va trebui să trimiteți un nou formular. Prin înregistrarea în aplicația centrală a unui tip de instructiuni pentru un participant, se determină:

formatul de mesaj în care poate transmite participantul respectiv un anumit tip de instructiune de plată,

modulul de transmitere utilizat.

1. Participanți/Instrumente de plată non-SEPA Dacă ați decis să nu aderați la schema SEPA, impactul modificărilor din aplicația centrală SENT va fi unul minim asupra aplicațiilor dumneavoastră, asa cum s-a cerut (dar nu vă veți bucura de toate facilitățile noii aplicații). Veți putea să transmiteți în continuare batch-uri cu instrucțiuni de plată în formatul SENT proprietar, modulele de preparare (FPM) și transmitere (FTM) a fișierelor fiind aceleași. Există totuși unele modificari făcute pentru a permite conversia mesajelor OP si OP de returnare în mesaje SEPA, atunci când este implicată participarea specială dar și pentru optimizarea procesului de compensare.

1.2. Modulul FPM

Modul de descărcare a modulului de pregătire mesaje (FPM) rămâne neschimbat, ca și structura de directoare de lucru.

Validarea codului BIC al Debtor/Creditor Agent cu caracterele 5-8 din codul IBAN din câmpul Debtor/ Creditor Account nu va mai exista (pentru a permite conversia mesajelor OP sau OP de returnare transmise/recepționate în numele unor participanți indirecți).

Modulul FPM va verifica respectarea modului de completare a OP de returnare (vezi punctul d. Conversie SCT Return -> CT Returnare -> SCT Return).

1.3. Modulul FTM

Modul de descărcare a modulului de transmitere mesaje (FTM) rămâne neschimbat (structura de directoare de lucru de asemenea).

Validarea codului BIC al Debtor/Creditor Agent cu caracterele 5-8 din codul IBAN din câmpul Debtor/ Creditor Account nu va mai exista (pentru a permite conversia mesajelor OP sau OP de returnare transmise/recepționate în numele unor participanți indirecți).

Modulul FTM va verifica respectarea modului de completare a OP de returnare (vezi punctul d. Conversie SCT Return -> CT Returnare -> SCT Return). De asemenea, va verifica codurile IBAN din instrucțiunile aferente schemelor CT și DD (SENT) pe baza standardului ISO.

PROGRAMUL SEPA


1.4. Aplicația Centrală Aplicația centrală va realiza aceleași validări ca și în prezent, generând aceleași notificări. Elementul de meniu ”Start Workstation” prin care se face descărcarea FPM și FTM va fi ușor de identificat în meniul aplicației. Dacă va fi necesar, Transfond va organiza scurte stagii de training pentru utilizarea aplicației (deși credem că utilizatorii vor identifica cu ușurință modificările). Principalele îmbunătățiri/schimbări din cadrul aplicației centrale, din punctul de vedere al unui participant non-SEPA constau în:

introducerea ”cozii de așteptare”: tranzacțiile care nu pot fi compensate din cauza garanțiilor insuficiente (inclusiv cele de direct debit si ID-uri) vor fi plasate în coada de asteptare, cu un nou status, PENDING (în prezent acestea sunt rejectate, cu status REJECT). În noua aplicatie, tranzacțiile din coada de așteptare (inclusiv cele de debitare directa si ID-uri) vor fi compensate imediat ce limita de garantare va permite (în prezent sunt amânate pentru sesiunea urmatoare cu status DELAYED);

extinderea perioadei de transmitere: batch-urile cu instrucțiuni vor putea fi transmise pe toata durata zilei de operare, în ambele moduri, chiar înainte de startul sesiunii, către coada de asteptare;

mecanismul de deblocare a cozilor de asteptare (pentru situatia cand este posibil un netting al plăților din cozile de așteptare ale mai multor participanți direcți);

interfașa grafică (meniul aplicației): va suferi îmbunătățiri (schimbări) care sunt prezentate în acest Buletin Informativ și vor fi detaliate în Manualul Utilizatorului SENT. Sunt eliminate graficele și sunt adăugate noi posibilități de navigare;

batchurile cu OP recepționate de la aplicatia SENT, inițiate de un participant SEPA, vor avea semnătura electronică a aplicației TRANSFOND și nu pe cea a inițiatorului (așa cum se întâmplă în prezent). Acest lucru se datorează faptului ca aplicația extrage semnătura originală, asigură conversia în formatul OP actual și semneaza fișierul în formatul rezultat (a se vedea mai jos la punctul 1.5);

mesajul de OP de returnare (convenția din Documentul Tehnic pentru Participanții SENT) se modifica pentru asigurarea conversiei în mesajul de SEPA CT Return. Dacă participantul nu va respecta aceste noi cerințe, aplicatia va face conversia, dar într-un mesaj de tip CT (și un participant SEPA va primi un mesaj de Credit Transfer distinct, si nu unul de Return, cum s-ar astepta) - a se vedea mai jos la punctul 1.6.

Compensarea și decontarea instrucțiunilor în format SENT proprietar vor avea loc în aceleași condiții ca și în prezent, odată cu compensarea și decontarea mesajelor în format SEPA.

1.5. Facilitatea de conversie pentru Transferul Credit SEPA - OP Pentru a putea menține modul de lucru actual pentru participanții care nu adoptă standardul SEPA, aplicația centrală va converti mesajele OP si OP de returnare a unei plăți în mesaje în format SEPA CT în cazul în care:

banca destinatară utilizeaza mesajele SEPA sau, invers: banca inițiatoare utilizeaza SEPA CT, iar banca destinatară folosește formatul actual de mesaje.

Facilitatea de conversie se poate aplica doar acestor 2 tipuri de mesaje.

PROGRAMUL SEPA


1 Pentru ca acest proces de conversie a OP/SCT să poată să aibă loc, băncile non-SEPA vor trebui să respecte următoarele reguli:

a. Conversie SCT (pacs.008.001.02) -> CT (CoreBulkCreditTransfer) Pentru ca aplicația să poată asigura conversia mesajelor CT și SCT în ambele sensuri, participanții la sistemul SENT trebuie să respecte următoarele convenții:

i. ”Instructing Agent” și ”Instructed Agent”

În mesajul OP (format SENT actual), câmpurile <FrstAgt> si <FnlAgt> vor contine intotdeauna BIC-urile participantilor directi. În cazul în care veți transmite și primi mesaje în numele unui participant indirect (dacă vă decideți să oferiți astfel de servicii altor bănci), atunci este important să știți și următoarele aspecte privind conversia mesajelor în cazul participării indirecte (a se vedea si punctul 2.1 de mai jos):

pe direcția CT->SCT, aplicația centrală va completa în mesajul SEPA CT (obținut în urma conversiei),

mai exact în câmpurile <InstgAgt> si <InstdAgt>, valorile din câmpurile <FrstAgt> si <FnlAgt> din

mesajul CT, iar in câmpurile <DbtrAgt> si <CdtrAgt> se vor completa codurile BIC convertite din

codurile IBAN corespunzătoare din mesajul CT (acesta întrucât în cazul participarii indirecte, mesajul

SENT CT actual nu are prevăzut un câmp special pentru Debtor Agent/Creditor Agent).

pe direcția SCT-> CT, în câmpul <FrstAgt> din mesajul CT se va completa participantul direct din

<InstgAgt>, dar codul BIC care va fi completat în câmpul <FnlAgt> va trebui căutat în baza de date pe

baza tabelei de rutare (administrată la nivel central de TRANSFOND) care conține codul BIC al

participantului direct al <CdtrAgt> (participantul direct). Daca într-un mesaj OP primit de la sistem,

nu exista concordanța între BIC banca debitoare și IBAN client debitor, atunci ar trebui să știți că e

vorba de o plată a unui client al unui subparticipant al băncii care are BIC-ul din câmpul <First

Agent>.

ii. Convenție privind câmpurile de sume din “CoreBulkCreditTransfer”(mesajul

de OP actual) la conversia CT> SCT

În prezent, mesajul “CoreBulkCreditTransfer” contine 2 câmpuri dedicate completării sumei: <IntrBkSttlmAmt> și <InstdAmt>, pentru compensare și decontare utilizându-se (de către sistem) numai câmpul <IntrBkSttlmAmt>. Deoarece în mesajul SCT (pacs.008.001.02) pentru completarea sumei se utilizează obligatoriu doar câmpul <IntrBkSttlmAmt>, pentru asigurarea conversiei, în cele două câmpuri din mesajul actual “CoreBulkCreditTransfer” va fi completată aceeași sumă (așa cum se întâmplă și în prezent), iar la conversia CT-SCT va fi preluată întotdeauna suma/valoarea completată în câmpul <IntrBkSttlmAmt>, suma din <InstdAmt> fiind ignorată (dacă diferă). Această abordare este impusă de standardele SEPA, care solicită ca suma de plată dintr-un ordin de transfer să nu fie diminuată (să nu se altereze suma de transfer cu eventuale comisioane, acestea fiind percepute distinct de ordinul de transfer).

1Aceasta va fi o situație de tranziție, temporară, până la data la care ARB va decide abandonarea schemei actuale de DD și înlocuirea

acesteia cu schemele SEPA.

În privința Debitării Directe, NU EXISTĂ CONVERSIE.

Dacă ați aderat la schema de plată SDD, veți putea realiza plăți interbancare SDD numai cu alte

bănci care au adoptat la rândul lor acest standard. Dacă folosiți în continuare doar DD actual,

veti putea face plăți cu DD numai cu alte bănci care mai folosesc formatul actual de mesaje DD1.

PROGRAMUL SEPA


iii. Lungimea câmpurilor pentru referințele de pachet sau instrucțiune de plată

Standardul SEPA permite utilizarea unor referințe de pachet (mesaj) și de instrucțiune cu o

lungime de maximum 35 de caractere, față de lungimea de 16 caractere pentru referințele din mesajul

actual (CoreBulkCreditTransfer). Această diferență ar putea crea probleme la conversie (apărând

probabilitatea trunchierii referințelor la conversia în format “CoreBulkCreditTransfer”, dacă inițiatorul

mesajului în format SEPA CT folosește mai mult de 16 caractere pentru unul/mai multe tag-uri

”referință”).

Pentru asigurarea conversiei (atât pentru mesajele de Credit Transfer, cât și pentru cele de returnare), ca

soluție intermediară, pe o perioadă determinată, participanții care vor folosi mesaje SEPA vor utiliza

referințe de maxim 16 caractere. În cazul în care acest lucru nu va fi posibil, aplicația va trunchia

informația la 16 caractere.

b. Conversia SCT -> CT ->SCT

Tabel mapare informații În tabelul de mai jos este prezentat modul în care va fi asigurată preluarea informațiilor din câmpurile mesajelor CT și SCT pentru asigurarea conversiei.

ID2 SCT tag CT tag

ID01T <GrpHdr><MsgId> <GrpHdr><GrpId> ID02D <GrpHdr><CreDtTm> <GrpHdr><CreDt> ID03N <GrpHdr><NbOfTxs> <GrpHdr><IndvItmTtlNb> ID04N <GrpHdr><TtlIntrBkSttlmAmt> <GrpHdr><TtlSttlmAmt> ID05D <GrpHdr><IntrBkSttlmDt> <GrpHdr><IntrBkValDt>

ID08BIC <GrpHdr><InstgAgt><FinInstnId><BIC> Bank-to-SENT

<CdtTrf><FrstAgt><BIC>

ID29BIC <GrpHdr><InstdAgt><FinInstnId><BIC> - SENT-to-Bank

<CdtTrf><FnlAgt><BIC>

ID10T <CdtTrfTxInf><PmtId><TxId> <CdtTrf><PmtInstr><InstrRef> ID11BIC <CdtTrfTxInf>< InstgAgt>< FinInstnId><BIC>

- SENT-to-Bank <CdtTrf><FrstAgt><BIC>

ID12N <CdtTrfTxInf><IntrBkSttlmAmt>

<CdtTrf><PmtInstr> <SttlmInstr> <IntrBkSttlmAmt> + <CdtTrf><PmtTx><InstdAmt> se va trece aceeasi suma (Bank-to-SENT sau SENT-to-Bank)

ID13T <CdtTrfTxInf><ChrgBr> <CdtTrf><PmtTx><ChrgBr> ID14T <CdtTrfTxInf><Dbtr><Nm> <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>

<NmAndAdr><Nm> ID15T <CdtTrfTxInf><Dbtr><PstlAdr><Ctry> <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>

<NmAndAdr><LngPstlAdrChc><Ustrd> ID16T <CdtTrfTxInf><Dbtr><PstlAdr><AdrLine> <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>

<NmAndAdr><LngPstlAdrChc><Ustrd> ID17T <CdtTrfTxInf><Dbtr><PstlAdr><AdrLine> <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>

<NmAndAdr><LngPstlAdrChc><Ustrd> ID18N <CdtTrfTxInf><Dbtr><Id><PrvtId><Othr><Id> <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>

<Id><ROURC> ID19IBAN <CdtTrfTxInf><DbtrAcct><Id><IBAN> <CdtTrf><PmtTx><DbtrAcct><Id><IBAN>

2 Această indexare este utilizată exclusiv în scopurile prezentului document.

PROGRAMUL SEPA


ID2 SCT tag CT tag

ID20BIC <CdtTrfTxInf><DbtrAgt><FinInstnId><BIC> sau indirect BIC din ID19IBAN


ID21BIC <CdtTrfTxInf><CdtrAgt> <FinInstnId><BIC> sau indirect BIC din ID27IBAN

<CdtTrf><FnlAgt><BIC>

ID22T <CdtTrfTxInf><Cdtr><Nm> <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr> <NmAndAdr><Nm>

ID23T <CdtTrfTxInf><Cdtr><PstlAdr><Ctry> <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr> <NmAndAdr><LngPstlAdrChc><Ustrd>

ID24T <CdtTrfTxInf><Cdtr><PstlAdr><AdrLine> <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr> <NmAndAdr><LngPstlAdrChc><Ustrd>

ID25T <CdtTrfTxInf><Cdtr><PstlAdr><AdrLine> <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr> <NmAndAdr><LngPstlAdrChc><Ustrd>

ID26N <CdtTrfTxInf><Cdtr><Id><PrvtId><Othr><Id> <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr> <Id><ROURC>

ID27IBAN <CdtTrfTxInf><CdtrAcct><Id><IBAN> <CdtTrf><PmtTx><CdtrAcct><Id><IBAN> ID28T <CdtTrfTxInf><RmtInf><Ustrd> <CdtTrf><PmtTx><RmtInf>

Exemplu conversie: CT de la Banca la SENT si SCT de la SENT la banca (după conversie)

CT: Bank-to-SENT SCT: SENT-to-bank (convertit)

<?xml version = "1.0" encoding = "UTF-8"?> <CoreBlkLrgRmtCdtTrf xmlns="urn:swift:xsd:CoreBlkLrgRmtCdtTrf" > <GrpHdr> <GrpId>ID01T</GrpId> <IndvItmTtlNb>ID03N</IndvItmTtlNb> <TtlSttlmAmt Ccy = "RON">ID04N</TtlSttlmAmt> <IntrBkValDt>ID05D</IntrBkValDt> <CreDt>ID02D</CreDt> </GrpHdr> <CdtTrf> <PmtInstr> <InstrRef>ID10T</InstrRef> <SttlmInstr> <IntrBkSttlmAmt Ccy = "RON">ID12N</IntrBkSttlmAmt> </SttlmInstr> </PmtInstr> <FrstAgt> <BIC>ID20BIC</BIC> </FrstAgt> <FnlAgt> <BIC>ID21BIC</BIC> </FnlAgt> <PmtTx> <InstdAmt Ccy = "RON">ID12N</InstdAmt> <ChrgBr>ID13T</ChrgBr> <DbtrAcct> <Id> <IBAN>ID19IBAN</IBAN> </Id> </DbtrAcct>

<?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02"> <FIToFICstmrCdtTrf> <GrpHdr> <MsgId>ID01T</MsgId> <CreDtTm>ID02D</CreDtTm> <NbOfTxs>ID03N</NbOfTxs> <TtlIntrBkSttlmAmt Ccy="RON">ID04N</TtlIntrBkSttlmAmt> <IntrBkSttlmDt>ID05D</IntrBkSttlmDt> <SttlmInf> <SttlmMtd>CLRG</SttlmMtd> <ClrSys> <Prtry>SENT</Prtry> </ClrSys> </SttlmInf> <InstdAgt> <FinInstnId> <BIC> ID21BIC </BIC> </FinInstnId> </InstdAgt> </GrpHdr> <CdtTrfTxInf> <PmtId> <EndToEndId>NOTPROVIDED</EndToEndId> <TxId>ID10T</TxId> </PmtId> <PmtTpInf> <SvcLvl> <Cd>SEPA</Cd> </SvcLvl>

PROGRAMUL SEPA


CT: Bank-to-SENT SCT: SENT-to-bank (convertit) <CdtrAcct> <Id> <IBAN>ID27IBAN</IBAN> </Id> </CdtrAcct> <Dbtr> <NFI> <IdAndNmAdr> <Id> <ROURC>ID18N</ROURC> </Id> <NmAndAdr> <Nm>ID14T</Nm> <LngPstlAdrChc> <Ustrd>ID15T+ID16T+ID17T</Ustrd> </LngPstlAdrChc> </NmAndAdr> </IdAndNmAdr> </NFI> </Dbtr> <Cdtr> <NFI> <IdAndNmAdr> <Id> <ROURC>ID26N</ROURC> </Id> <NmAndAdr> <Nm>ID22T</Nm> <LngPstlAdrChc> <Ustrd>ID23T+ID24T+ID25T</Ustrd> </LngPstlAdrChc> </NmAndAdr> </IdAndNmAdr> </NFI> </Cdtr> <RmtInf> <Ustrd>ID28T</Ustrd> </RmtInf> </PmtTx> </CdtTrf> </CoreBlkLrgRmtCdtTrf>

</PmtTpInf> <IntrBkSttlmAmt Ccy="RON">ID12N</IntrBkSttlmAmt> <ChrgBr>ID13T</ChrgBr> < InstgAgt > <FinInstnId> <BIC> ID20BIC</BIC> </FinInstnId> </ InstgAgt > <Dbtr> <Nm>ID14T</Nm> <PstlAdr> <Ctry>ID15T</Ctry> <AdrLine>ID16T</AdrLine> <AdrLine>ID17T</AdrLine> </PstlAdr> <Id> <PrvtId> <Othr> <Id>ID18N</Id> <SchmeNm> <Prtry>ROURC</Prtry> </SchmeNm> </Othr> </PrvtId> </Id> </Dbtr> <DbtrAcct> <Id> <IBAN>ID19IBAN</IBAN> </Id> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>ID20BIC sau indirect din IBAN</BIC> </FinInstnId> </DbtrAgt> <CdtrAgt> <FinInstnId> <BIC>ID21BIC sau indirect din IBAN</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>ID22T</Nm> <PstlAdr> <Ctry>ID23T</Ctry> <AdrLine>ID24T</AdrLine> <AdrLine>ID25T</AdrLine> </PstlAdr> <Id> <PrvtId> <Othr> <Id>ID26N</Id> <SchmeNm>

PROGRAMUL SEPA


CT: Bank-to-SENT SCT: SENT-to-bank (convertit) <Prtry>ROURC</Prtry> </SchmeNm> </Othr> </PrvtId> </Id> </Cdtr> <CdtrAcct> <Id> <IBAN>ID27IBAN</IBAN> </Id> </CdtrAcct> <RmtInf> <Ustrd>ID28T</Ustrd> </RmtInf> </CdtTrfTxInf> </FIToFICstmrCdtTrf> </Document>

Exemplu conversie: SCT de la banca la SENT și CT de la SENT la banca (după conversie)

SCT: Bank-to-SENT CT: SENT-to-bank (convertit)

<?xml version="1.0" encoding="utf-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02"> <FIToFICstmrCdtTrf> <GrpHdr> <MsgId>ID01T</MsgId> <CreDtTm>ID02D</CreDtTm> <NbOfTxs>ID03N</NbOfTxs> <TtlIntrBkSttlmAmt Ccy="RON">ID04N</TtlIntrBkSttlmAmt> <IntrBkSttlmDt>ID05D</IntrBkSttlmDt> <SttlmInf> <SttlmMtd>CLRG</SttlmMtd> <ClrSys> <Prtry>SENT</Prtry> </ClrSys> </SttlmInf> <InstgAgt> <FinInstnId> <BIC>ID08BIC</BIC> </FinInstnId> </InstgAgt> </GrpHdr> <CdtTrfTxInf> <PmtId> <EndToEndId>NOTPROVIDED</EndToEndId> <TxId>ID10T</TxId> </PmtId> <PmtTpInf> <SvcLvl> <Cd>SEPA</Cd>

<?xml version = "1.0" encoding = "UTF-8"?> <CoreBlkLrgRmtCdtTrf xmlns="urn:swift:xsd:CoreBlkLrgRmtCdtTrf" > <GrpHdr> <GrpId>ID01T</GrpId> <IndvItmTtlNb>ID03N</IndvItmTtlNb> <TtlSttlmAmt Ccy = "RON">ID04N</TtlSttlmAmt> <IntrBkValDt>ID05D</IntrBkValDt> <CreDt>ID02D</CreDt> </GrpHdr> <CdtTrf> <PmtInstr> <InstrRef>ID10T</InstrRef> <SttlmInstr> <IntrBkSttlmAmt Ccy = "RON">ID12N</IntrBkSttlmAmt> </SttlmInstr> </PmtInstr> <FrstAgt> <BIC> ID08BIC </BIC> </FrstAgt> <FnlAgt> <BIC>ID21BIC sau se cauta in routing table BICul directului</BIC> </FnlAgt> <PmtTx> <InstdAmt Ccy = "RON">ID12N</InstdAmt> <ChrgBr>ID13T</ChrgBr> <DbtrAcct> <Id> <IBAN>ID19IBAN</IBAN>

PROGRAMUL SEPA


SCT: Bank-to-SENT CT: SENT-to-bank (convertit) </SvcLvl> </PmtTpInf> <IntrBkSttlmAmt Ccy="RON">ID12N</IntrBkSttlmAmt> <ChrgBr>ID13T</ChrgBr> <Dbtr> <Nm>ID14T</Nm> <PstlAdr> <Ctry>ID15T</Ctry> <AdrLine>ID16T</AdrLine> <AdrLine>ID17T</AdrLine> </PstlAdr> <Id> <PrvtId> <Othr> <Id>ID18N</Id> <SchmeNm> <Prtry>ROURC</Prtry> </SchmeNm> </Othr> </PrvtId> </Id> </Dbtr> <DbtrAcct> <Id> <IBAN>ID19IBAN</IBAN> </Id> </DbtrAcct> <DbtrAgt> <FinInstnId> <BIC>ID20BIC</BIC> </FinInstnId> </DbtrAgt> <CdtrAgt> <FinInstnId> <BIC>ID21BIC</BIC> </FinInstnId> </CdtrAgt> <Cdtr> <Nm>ID22T</Nm> <PstlAdr> <Ctry>ID23T</Ctry> <AdrLine>ID24T</AdrLine> <AdrLine>ID25T</AdrLine> </PstlAdr> <Id> <PrvtId> <Othr> <Id>ID26N</Id> <SchmeNm> <Prtry>ROURC</Prtry> </SchmeNm> </Othr>

</Id> </DbtrAcct> <CdtrAcct> <Id> <IBAN>ID27IBAN</IBAN> </Id> </CdtrAcct> <Dbtr> <NFI> <IdAndNmAdr> <Id> <ROURC>ID18N</ROURC> </Id> <NmAndAdr> <Nm>ID14T</Nm> <LngPstlAdrChc> <Ustrd>ID15T+ID16T+ID17T</Ustrd> </LngPstlAdrChc> </NmAndAdr> </IdAndNmAdr> </NFI> </Dbtr> <Cdtr> <NFI> <IdAndNmAdr> <Id> <ROURC>ID26N</ROURC> </Id> <NmAndAdr> <Nm>ID22T</Nm> <LngPstlAdrChc> <Ustrd>ID23T+ID24T+ID25T</Ustrd> </LngPstlAdrChc> </NmAndAdr> </IdAndNmAdr> </NFI> </Cdtr> <RmtInf> <Ustrd>ID28T</Ustrd> </RmtInf> </PmtTx> </CdtTrf> </CoreBlkLrgRmtCdtTrf>

PROGRAMUL SEPA


SCT: Bank-to-SENT CT: SENT-to-bank (convertit) </PrvtId> </Id> </Cdtr> <CdtrAcct> <Id> <IBAN>ID27IBAN</IBAN> </Id> </CdtrAcct> <RmtInf> <Ustrd>ID28T</Ustrd> </RmtInf> </CdtTrfTxInf> </FIToFICstmrCdtTrf> </Document>

c. Conversia mesajelor CT/SCT în relația cu Trezoreria Statului În mesajele SCT-RON adresate Trezoreriei Statului, tagurile Debtor Identification și Creditor Identification sunt obligatorii.

În prezent, în relația cu Trezoreria Statului, se utilizează câmpul “Remittance Information” (max. 350 de caractere) pentru transmiterea unor informații specifice. Deoarece tag-ul echivalent (“Remittance Information”) din standardului SEPA CT include doar maximum 140 de caractere, pentru a putea realiza conversia câmpul “Remittance Information” din mesajele SCT se va completa astfel:

Info necesar curente in OP conform Normelor Nr

caractere (max)

Preluare in mesaj SEPA (pacs 008) In tag dedicat

(distinct) In Remittance Info

/ROC/Cod ANAF 28 - Da Nr OP alocat de PF/PJ 35 Da - /RFB/Data emitere OP/Data plata OP 22 - Da

/Info ref continutul economic al operatiunii 90 - Da

d. Conversie SCT Return -> CT Returnare -> SCT Return

Actualizare convenție pentru OP de returnare

În Documentul Tehnic pentru participanții SENT în Sectiunea K.2 este prezentat modul în care se completează un CT (OP) de returnare a sumei în cazul în care OP-ul recepționat nu poate fi procesat de banca beneficiarului.

În cazul în care mesajele de returnare nu respectă această convenție, acestea: fie vor fi rejectate de aplicația centrală, fie vor fi convertite în mesaje SCT și nu SCT Return.

Pentru asigurarea conversiei în formatul SCT Return, informațiile din mesajele CT de returnare actuale vor fi actualizate după cum urmează:

în tag-ul “Debtor Account” se va completa codul IBAN al contului creditor din mesajul inițial primit de la banca inițiatoare a OP-ului care se returnează (în loc de codul IBAN ”fake” al băncii care inițiază returnarea, care se utilizează în prezent)

PROGRAMUL SEPA


va fi utilizat un set comun de coduri de returnare (prevăzute în documentația EPC,) indiferent de formatul de mesaj utilizat.

Câmpul “Remittance Information” din mesajele SVPO de returnare va fi mapat după cum urmează:

Info necesare in OP (curent)

Nr caractere

Preluare in mesaj SEPA (pacs 004) in urma conversiei

In tag dedicat (distinct) In tag Remittance Info

RETN/Indicii mesaj 35 - Da

Cod SEPA Return 4 Da -

MREF/Ref Instructiune 5+16 Da -

Original Message ID 16 Da -

Originator ID (BIC) 8 Da -

Tabel de mapare informații

Pentru a putea fi convertit în mesaj SCT Return, mesajul OP de returnare trebuie să conțină informațiile necesare (informații marcate cu culoare roșie)

ID SCT Return Return CT

ID01T <GrpHdr><MsgId> <GrpHdr><GrpId> ID02D <GrpHdr><CreDtTm> <GrpHdr><CreDt> ID03N <GrpHdr><NbOfTxs> <GrpHdr><IndvItmTtlNb> ID04N <GrpHdr><TtlIntrBkSttlmAmt> <GrpHdr><TtlSttlmAmt> ID05D <GrpHdr><IntrBkSttlmDt> <GrpHdr><IntrBkValDt> ID06BIC <GrpHdr><InstgAgt><FinInstnId><BIC> <InstgAgt><BIC> ID07T <OrgnlGrpInf><OrgnlMsgId> -- se completeaza in RmtInf -- ID08T <TxInf><RtrId> <CdtTrf> <PmtInstr> <InstrRef> ID09T <TxInf><OrgnlTxId> <CdtTrf> <PmtTx> <OrgtrRef>

ID10N

<TxInf><OrgnlIntrBkSttlmAmt> + <TxInf><RtrdIntrBkSttlmAmt> Aceste doua sume trebuie sa fie identice

<CdtTrf> <PmtTx> <InstdAmt> + <CdtTrf> <PmtInstr> <SttlmInstr> <IntrBkSttlmAmt>

ID12BIC <TxInf><RtrRsnInf><Orgtr><Id><OrgId><BICOrBEI>

-- se completeaza în RmtInf --

ID13T <TxInf><RtrRsnInf><Rsn><Cd> -- se completeaza în RmtInf --

ID14D <TxInf><OrgnlTxRef><IntrBkSttlmDt> <CdtTrf> <PmtInstr> <InstrRef> <SttlmInstr>

<IntrBkValDt> ID15T <TxInf><OrgnlTxRef><RmtInf> < CdtTrf> <PmtTx> <RmtInf>

ID16T <TxInf><OrgnlTxRef><Dbtr><Nm> <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>

<NmAndAdr><Nm>

ID17T <TxInf><OrgnlTxRef><Dbtr><PstlAdr><Ctry> <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>

<NmAndAdr><LngPstlAdrChc><Ustrd>

ID18T <TxInf><OrgnlTxRef><Dbtr><PstlAdr><AdrLine>

<CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr> <NmAndAdr><LngPstlAdrChc><Ustrd>

ID19T <TxInf><OrgnlTxRef><Dbtr><PstlAdr><AdrLine>

<CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr> <NmAndAdr><LngPstlAdrChc><Ustrd>

ID20N <TxInf><OrgnlTxRef><Dbtr><Id><PrvtId><Othr><Id>

<CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr> <Id><ROURC>

ID21IBAN <TxInf><OrgnlTxRef><DbtrAcct><Id><IBAN> <CdtTrf><PmtTx><DbtrAcct><Id><IBAN>

ID22BIC <TxInf><OrgnlTxRef> <DbtrAgt><FinInstnId><BIC>


ID23BIC <TxInf><OrgnlTxRef><CdtrAgt><FinInstnId> <CdtTrf><FnlAgt><BIC>

PROGRAMUL SEPA


ID SCT Return Return CT <BIC>

ID24T <TxInf><OrgnlTxRef><Cdtr><Nm> <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr>

<NmAndAdr><Nm>

ID25T <TxInf><OrgnlTxRef><Cdtr><PstlAdr><Ctry> <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr>

<NmAndAdr><LngPstlAdrChc><Ustrd>

ID26T <TxInf><OrgnlTxRef><Cdtr><PstlAdr><AdrLine>

<CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr> <NmAndAdr><LngPstlAdrChc><Ustrd>

ID27T <TxInf><OrgnlTxRef><Cdtr><PstlAdr><AdrLine>

<CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr> <NmAndAdr><LngPstlAdrChc><Ustrd>

ID28N <TxInf><OrgnlTxRef><Cdtr><Id><PrvtId><Othr><Id>

<CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr> <Id><ROURC>

ID29IBAN <TxInf><OrgnlTxRef><CdtrAcct><Id><IBAN> <CdtTrf><PmtTx><CdtrAcct><Id><IBAN>

2. Participanți SEPA

Aceste bănci au aderat cel puțin la una dintre schemele SEPA (SCT sau SDD). Pregătirea pachetelor cu instrucțiuni SEPA se va face în cadrul aplicațiilor interne ale băncilor.

2.1. Participanți indirecți Noua aplicație SENT va putea procesa și mesajele transmise în numele unor participanți indirecți, menținând un tabel de rutare, administrat la nivel central. În cadrul noii aplicații SENT SEPA va fi posibilă și procesarea instrucțiunilor băncilor care

nu sunt conectate la aplicația centrală (participanti indirecti). În cazul în care o bancă nu dorește să se conecteze direct la sistemul SENT al TRANSFOND, ci prin intermediul unei alte bănci, aceasta va putea apela la serviciile oferite de băncile participant-direct care vor putea transmite pachete cu instrucțiuni de plată în format SEPA, în numele participanților lor indirecți, în vederea compensării și decontării. Similar, un participant direct va putea primi mesaje de plată destinate participantului său indirect. Băncile participante indirect pot sau nu să aibă cont de decontare în ReGIS, decontarea putând avea loc și pe contul de decontare al băncii participante direct. Participantul indirect trebuie însă să fie înregistrat în sistemul SENT ca atare (altfel sistemul nu recunoaste destinatarul sau initiatorul și va rejecta batchurile inițiate în numele acestora sau adresate lor).

2.2. Constituirea garanțiilor Modul de constituire a garanțiilor va avea loc ca și în prezent. Suplimentar, noua aplicație va permite participanților direcți să seteze limite debitoare multilaterale maxime (grad de utilizare a garanțiilor) pentru fiecare dintre participanții lor indirecți, limite care pot fi modificate pe durata sesiunilor de compensare.

PROGRAMUL SEPA


2.3. Transmiterea batch-urilor & modulele de transmitere

FTM Gateway

Tipuri de instrucțiuni

SVPO SVPO de returnare DD RDD CEC RCEC BO RBO CAM RCAM

SEPA CT (pacs.008) SEPA CT Return (pacs.004) SEPA CT Recall (camt.056) SEPA CT Positive Answer to a Recall (pacs.004) SEPA CT Negative Answer to a Recall (camt.029) SEPA DD Collection (pacs.003) SEPA DD Return (pacs.004) SEPA DD Reject (pacs.002) SEPA DD Refund (pacs.004) SEPA DD Reversal (pacs.007)

Modul de funcționare a FTM și regulile de transmitere rămân nemodificate, cu excepția faptului că aplicația centrală va accepta batch-uri pe toată durata zilei de operare, fără să respingă batch-urile pentru care nu există suficiente garanții disponibile sau tranzacţiile care nu pot fi compensate deoarece nu este perioada de compensare. Noua aplicație va permite de asemenea transmiterea mesajelor în modul manual, cu aprobare din interfața aplicației centrale. Pentru detalii privind regulile de utilizare și modul de completare a mesajelor SEPA vă rugăm să consultați:

ISO20022 (www.iso20022.org)

EPC115-06 SCT Interbank Implementation Guidelines v 5.0

EPC125-05 SCT Interbank Rulebook v 5.0

EPC016-06 SDD Core Interbank Rulebook v 5.0

EPC114-06 SDD Core Interbank Implementation Guidelines v 5.0

EPC222-07 SDD B2B Rulebook v 3.0

EPC301-07 SDD B2B Interbank Implementation Guidelines v 3.0

Documentul Tehnic pentru Participanții SENT

schemele .xsd aferente noilor formate de mesaje SEPA pentru plăți în lei.

Sistemul procesează doar instrucțiuni în format bulk .xml, conform formatelor definite prin Documentul Tehnic pentru Participanți. Sistemul procesează pachete de instrucțiuni în format SEPA sortate/ nesortate pe participantul direct/indirect destinatar.

Sistemul procesează doar pachete care:

conțin același tip de instrucțiuni. De exemplu, un pachet nu va putea include mesaje OP și mesaje OP de returnare, dar va putea include mai multe instructiuni pacs.004, de ex. SCT Positive Answer și SCT Return sau SDD Return si SDD Refund. În cazul schemei SDD, instrucțiunile dintr-un batch trebuie să fie sortate în funcție de schema SDD de care aparține debitorul (Core sau B2B).

conțin instrucțiuni cu aceeași dată a decontării și denominate în aceeași monedă

respectă intervalele de transmitere specifice fiecărui tip de instrucţiune, în funcţie de value date.

http://www.iso20022.org/

PROGRAMUL SEPA


Modulul FTM Modulul FTM va putea fi utilizat în continuare pentru transmiterea pachetelor cu instrumente de debit sau, în cazul în care o bancă adoptă doar o singură schemă de plată (doar SCT sau doar SDD), aceasta va putea transmite mesajele aferente celeilalte scheme în continuare cu FTM. Modificările FTM sunt menționate în secțiunea 1.3 de mai sus.

Modulul Gateway Batch-urile cu instrucțiuni în format SEPA vor putea fi transmise doar cu noul modul, numit

Gateway. Ca și modulul FTM, Gateway va putea fi descărcat de pe aplicația centrală în 3 moduri (în funcție de profilul băncii setat în aplicația centrală):

Modul Manual

(default)

În acest mod batchurile cu instrucțiuni în format SEPA se încarcă în Gateway (prin simpla lor copiere în directorul de intrare) pentru a fi trimise la sistemul central. Ele pot să fie semnate (formatul acceptat este .p7m) sau nu, în ultimul caz Gateway semnând automat batchurile cu un certificat simplu.

Semnătura electronică este validată în cazul fișierelor care sunt încărcate gata semnate și al mesajelor recepționate de la sistemul central.

În modul manual, Gateway poate fi configurat să nu trimită automat fișierele pe care le încarcă din directorul de intrare. În această situație, fiecare mesaj se poate trimite individual, dând click dreapta pe mesaj și apoi alegând „Send” din meniul afișat.

Modul STPSign

În acest mod mesajele XML semnate de aplicatia STP a băncii inițiatoare sunt preluate prin MQ. Mesajele venite de la sistemul central sunt transmise fără a fi modificate, de asemenea prin MQ, la aplicația STP.

În acest mod se face validarea de semnătură electronică pentru mesajele primite din ambele direcții.

Modul GatewaySign

În acest mod, Gateway primeste mesajele XML nesemnate de la aplicatia STP a băncii, le semnează și le trimite la sistemul central. Mesajelor venite de la sistemul central li se extrage semnătura și sunt trimise nesemnate la aplicatia STP.

In oricare din aceste trei moduri nu se verifica valabilitatea certificatului cu care sunt semnate mesajele pe care le primeste Gateway de la sistemul central (dar aplicatia centrală face aceste verificări, deci nu veți primi mesaje nesemnate sau semnate cu certificate invalide).

Atât certificatul digital folosit de Gateway pentru semnare, cât si keystore-ul în care se stocheaza el, folosesc aceleași convenții ca și certificatul digital folosit de FTM pentru semnare și keystore-ul corespunzător, în care se păstreaza acest certificat. Keystore-ul folosit de Gateway se găsește în directorul care mai contine și directoarele „in”, „inputarchive” și „out”.

Directoare de lucru Gateway

Modulul Gateway salvează mesajele de plată în directoare pe stațiile de lucru ale participanților direcți după cum urmează:

„in”: directorul este folosit doar in modul manual. Orice mesaj copiat în acest director va fi citit automat de Gateway și procesat (trimis la SENT central).

„inputarchive/<data>”: directorul este folosit în toate cele trei moduri de operare Gateway. Mesajele primite de Gateway prin MQ de la aplicatia STP a băncii sau citite din directorul „in” sunt procesate și apoi salvate în acest director.

„out/<data>”: directorul este folosit în toate cele trei moduri de operare Gateway. Mesajele primite de Gateway de la sistemul SENT central sunt salvate în acest director.

„out/<data>/recalls”: directorul este folosit în toate cele trei moduri de operare Gateway. Mesajele Recall primite de Gateway de la aplicația centrală sunt salvate în acest director.

PROGRAMUL SEPA


În cazul în care nu mai este posibilă salvarea pachetelor pe disc din lipsa spațiului disponibil:

în cazul în care a fost lansat în mod STP, modulul Gateway generează un mesaj de notificare „Lipsă spaţiu pe disc”, care este transmis către coada de MQ, spre a fi preluat de aplicaţia STP.

nu se mai recepţionează mesaje de la SENT Central sau aplicaţia STP (sunt oprite automat serverele prin care comunică cu acestea)

afişează într-o casetă de dialog un mesaj care descrie situaţia apărută

când utilizatorul închide această casetă de dialog, Gateway se oprește. Utilizatorul trebuie sa repornească modulul Gateway manual, după ce a corectat problema apărută (ex. a mărit spaţiul liber în directorul de lucru), astfel încât Gateway să-şi poată desfăşura activitatea.

Reconciliere Gateway

Modulul Gateway asigură reconcilierea mesajelor:

transmise către sistemul central și recepționate de aplicația centrală

transmise de aplicația centrală și recepționate de participant

la momentul de Cut-off prin verificarea situaţiei proprii cu cea trimisă de sistemul central în mesaje .xml de reconciliere (număr de instrucțiuni/pachete și valoare) similar modului de lucru actual FTM.

Validări efectuate de modulul Gateway

Modulul Gateway execută următoarele validari:

în modul manual (daca fișierele au fost deja semnate manual) și în modul STP_Sign: validarea semnăturilor electronice aplicate de participanți mesajelor cu instrucțiuni de plată.

nu se pot transmite instrucțiuni ID, DD sau CT cu modulul Gateway (Gateway rejectează aceste mesajele).

mesajele care nu respectă cerința de dimensiune sunt rejectate.

Erorile identificate sunt afișate în meniul/interfața modulului.

2.4. Perioade de transmitere

Sistemul recepționează mesajele transmise de participanți pe tot parcursul zilei, indiferent de modul de lucru (manual, STP), de la momentul Start of Day la Cut-off (pentru ID până la Cut-Off transmitere ID). ID se pot trimite/primi doar in cadrul ferestrei ID.

Perioada de așteptare pentru SDD începe din momentul recepționării de către banca destinatară și până în T-1 la Cut-Off sau T, înainte de compensare. În ambele cazuri, aplicația centrală va genera Raportul DD/SDD/ID în T-1, la Cut-Off.

Se poate transmite un mesaj de SDD Reject pentru un SDD a cărui compensare a eșuat, inclusiv pentru cazul în care acesta are statusul PENDING (se află în coada de așteptare).

PROGRAMUL SEPA


Orarul aplicației

Moment Eveniment Start-of –day/ Inceput fereastră ID

Sistemul recepţioneaza orice fel de mesaje (DI doar in ferestre) dupa acest moment.

Setare garanții & limite de expunere participanti (dacă este cazul)

Setarea, de către operatorul TRANSDFOND (la cererea participanților direcți) sau de către Participantii Direcți înșiși, a limitelor maxime bilaterale în relația cu alți participanti direcți SENT pe conturile tehnice ale participantilor.

În cazul în care se setează (de către participanți/TRANSFOND) o limită bilaterală în relația cu un singur participant, limitele bilaterale în relația cu ceilalți participanți rămân nemodificate.

De asemenea, participanții își pot seta o limită debitoare multilaterală maximă (implicit se copiază valoarea garanțiilor constituite, dar apoi se poate schimba).

Interogare garanţii (ReGIS si SaFIR)

Sistemul calculeaza plafonul de garantare pe baza datelor primite de la sistemele ReGIS si SaFIR

Început proces de compensare sesiunea 1

Sistemul compensează plăţile recepţionate până în acel moment, inclusiv instrumentele de debit, conform scadenţei şi limitei de garantare. Începe calcularea în timp real a poziţiilor nete multilaterale ale participanţilor.

Sfârşit proces de compensare

Procesul de compensare este oprit şi toate mesajele primite după acest moment sunt amânate pentru sesiunea următoare (batch-urile aferente au status ACCEPTED sau PARTIAL). Tranzactiile in status PENDING sunt amânate de asemenea pentru sesiunea urmatoare. Se calculează NSI.

Transmitere instrucţiune de decontare pe bază netă

Sistemul transmite NSI la ReGIS si receptioneaza raspunsul de decontare NSI la ReGIS.

Sfârşit de sesiune 1 Se generează rapoarte de sfârșit de sesiune. Sesiunea 2, 3 Interogare garantii

.....

Sfârșit fereastră ID/Cut-off ID

Nu se mai pot transmite fișiere ID

Cut-off transmitere RID

Nu mai pot fi transmise mesaje RID.

Cut-off Sistemul nu mai primeşte mesaje (non-ID si non-RID) după acest moment.

End-of-day Se generează şi se transmit rapoartele de sfârşit de zi şi participanții direcți nu vor mai avea acces la unele opţiuni de meniu.

PROGRAMUL SEPA


2.5. Validarea batch-urilor transmise de participanții direcți de către aplicația centrală

Aplicația centrală va aplica batch-urilor cu instrucțiuni SEPA aproximativ aceleași validări ca cele pe care le aplică mesajelor non-SEPA. Excepție: nu se va mai verifica dacă instrucțiunile sunt sortate în funcție de destinatar (întrucât sistemul poate face sortarea) sau dacă sesiunea de compensare este deschisă (sistemul aceptând fișiere chiar între sesiuni și gestionându-le în cozi de așteptare atât timp cît mai există o șansă ca ele să fie procesate). În cazul în care erorile detectate sunt doar la nivel de instrucțiune, aplicația centrală va rejecta doar instrucțiunile invalidate, refăcând batch-ul și semnându-l cu semnătura sistemului SENT.

Suplimentar, însă, aplicația centrală va aplica un nou set validări acestor tipuri de instrucțiuni, specifice SEPA.

Tip mesaj Reguli de utilizare Validări efectuate de aplicația centrală

SCT-pacs. 008.001.02

Este vorba de mesajul de ordin de plată de mică valoare în format electronic. Trebuie să respecte aceleași reguli de transmitere ca în prezent. Sistemul va putea fi setat astfel încât să accepte instrucțiuni cu o dată viitoare a decontării (în cazul în care se va solicita acest lucru; de exemplu când o bancă nu lucrează în o anumită zi, dar dorește să transmită instructiunile înainte).

Referințele alocate instrucțiunilor în format SEPA CT de către participanții SENT trebuie să fie unice.

Aplicația centrală va mai valida și respectarea parametrilor de sistem privind perioadele de transmitere

SCT RETURN – pacs. 004.001.02

Dacă dvs, în calitate de bancă beneficiară a unui SCT, din diverse motive, nu puteți credita contul beneficiarului unei instrucțiuni de SCT primite, trebuie să generați și să transmiteți băncii plătitorului un mesaj de RETURN pentru acea instrucțiune, înapoind astfel fondurile Mesajele SCT Return trebuie

transmise în termen maxim de 3 zile de la data decontării SCT inițial.

Aplicația centrală validează respectarea parametrilor de sistem privind termenul de transmitere.

Informațiile din mesajul SCT RETURN trebuie să corespundă informațiilor din instrucțiunea/ pachetul SCT-RON decontat anterior (care face obiectul returnării), respectiv:

OriginalMessageIdentification OriginalMessageNameIdentification OriginalInstructionIdentification

(optional) OriginalEndToEndIdentification

(optional) OriginalTransactionIdentification OriginalInterbankSettlementAmount

De asemenea, codul de motivare RETURN trebuie să fie un cod valid pentru acest tip de instrucțiuni.

SCT RECALL – camt. 056.001.01

Acest mesaj este o solicitare privind anularea unui SCT transmis sau returnarea unor fonduri care au fost decontate printr-un SCT

Dacă ați constatat că ati transmis în mod eronat o instrucțiune SCT către o altă bancă puteți transmite

Aplicația centrală validează respectarea parametrilor de sistem privind termenul de transmitere (10 zile de la decontarea instrucțiunii pentru care se doreste RECALL ).

Informațiile din mesajul Recall trebuie să corespundă informațiilor din instrucțiunea/ pachetul SCT-RON care face obiectul

PROGRAMUL SEPA



un mesaj de RECALL pentru a solicita băncii beneficiare un răspuns privind returnarea sumei plătite eronat.

O instrucțiune de acest tip poate ajunge la sistem:

înainte de compensarea SCT care face obiectul solicitării (instrucțiunea SCT nu a fost încă compensată de sistemul SENT)

după compensare/decontarea SCT care face obiectul solicitării.

În cazul în care obiectul solicitării RECALL este un SCT care a fost deja decontat, banca debitoare din SCT inițial trebuie să transmită

aceasta solicitare în termen de maxim

10 zile de la decontarea SCT inițial.

mesajului Recall: OriginalMessageIdentification OriginalMessageNameIdentification OriginalInstructionIdentification


(optional) OriginalTransactionIdentification OriginalInterbankSettlementAmount OriginalInterbankSettlementDate

Daca Mesajul Recall este transmis înainte de compensarea instrucțiunii SCT inițiale (SCT se află într-o tranzactie cu status READY, PENDING sau TRANSFER), aplicația centrală recalculează valoarea batchului din care face parte SCT care face obiectul mesajului Recall, anulând instructiunea SCT respectivă.

Dacă mesajul RECALL este transmis după compensarea instrucțiunii inițiale, sistemul verifică dacă participantul destinatar al instrucțiunii RECALL poate recepționa (conform setărilor din profil) mesaje SEPA Recall:

dacă banca destinatară este un participant care utilizează SCT, sistemul transmite instrucțiunea Recall participantului destinatar

dacă banca destinatară este un participant care nu utilizeaza SCT, sistemul rejectează instrucțiunea Recall (deci nu puteți trimite un RECALL decat tot catre un participant SEPA).

Codul de motivare RECALL trebuie să fie un cod valid pentru acest tip de instrucțiuni.

Positive Answer to a Recall - pacs 004.001.02

Dacă la primirea unui mesaj de RECALL, sunteți de acord să returnați banii bancii initiatoare a RECALL-ului (recomandabil), trimiteti acest mesaj de răspuns pozitiv în termen de 10 zile de la data la care ați recepționat mesajul Recall respectiv de la aplicația centrală.

Prin acest mesaj (echivalent al unui un mesaj de tip transfer credit) dvs acceptati să înapoiați băncii plătitoare suma solicitată prin mesajul Recall.

La primirea lui, aplicația va debita poziția dvs netă și o va credita pe cea a bancii inițiatoare a mesajului Recall.

Aplicația centrală verifică dacă mesajul de răspuns pozitiv a fost transmis în termenul permis.

Informațiile din mesajul Interbank Positive Answer to Recall trebuia să corespundă informațiilor din instrucțiunea SCT-RON care face obiectul mesajului Recall la care se răspunde.




Codul de motivare Positive Answer to a RECALL trebuie să fie completat/un cod valid.

PROGRAMUL SEPA



Negative Answer to a Recall – camt. 029.001.03

Dacă, dimpotrivă, nu doriți să returnați suma instructiunii de SCT primite și solicitate înapoi prin RECALL (în principiu, nerecomandabil ) puteți raspunde printr-un astfel de mesaj, în termen de 10 zile de la data la care a fost recepționat mesajul de Recall de la aplicația centrală (oricum, e de preferat să răspundeti prin Negative Answer decat sa nu raspundeti deloc!).

Oricum, este un mesaj de tip ”non-value” și reprezintă refuzul băncii de a înapoia suma care i-a fost solicitată prin mesajul Recall; nu are efect asupra decontarii.

Situația se rezolvă în afara sistemului (este și in afara schemei SEPA) de către cele doua bănci și clienții lor.

Aplicația centrală verifică dacă mesajul de răspuns pozitiv a fost transmis în termenul permis.

Informațiile din mesajul Negative Answer to Recall trebuia să corespundă informațiilor din instrucțiunea SCT-RON care face obiectul mesajului Recall la care se răspunde.



(optional) OriginalTransactionIdentification

Codul de motivare Negative Answer to a RECALL trebuie să fie completat/un cod valid.

SDD – pacs. 003.001.02

Este vorba de instrucțiunea de debitare directă propriu zisă (mesajul debit).

Termenele de inițiere a instrucțiunilor de debitare directă diferă în funcție de schema SDD.

Schema SDD Core3

Prima instrucțiune dintr-o serie recurentă de instrucțiuni sau o unică instrucțiune (one-off) aferentă unui mandat trebuie transmisă în termenul (T-14) – (T-5) unde T=data decontării.

Instrucțiunea subsecventă dintr-o serie de instrucțiuni trebuie transmisă în termenul (T-14) – (T-2) unde T=data decontării.

Schema SDD B2B4

Prima instrucțiune dintr-o serie recurentă de instrucțiuni sau o unică instrucțiune (one-off) aferentă unui mandat trebuie transmisă în termenul (T-14) – (T-5) unde T=data decontării.

O instrucțiune subsecventă dintr-o serie de instrucțiuni trebuie transmisă în termenul (T-14) – (T-1) unde T=data decontării.

Aplicația centrală verifică dacă instrucțiunea SDD a fost transmisă în termenul permis.

Referințele alocate instrucțiunilor în format SEPA DD de către participanții SENT trebuie să fie unice

Sistemul validează fiecare instrucțiuni de DD dintr-un pachet cu Registrul de mandate, dacă acest servciu va fi solicitat. În acest caz, sistemul va verifică dacă:

referința unică a mandatului indicată în instrucțiunea SDD aparține unui mandat valid din Registru

codul IBAN debitor din instrucțiunea SDD este identic cu cel din mandat

codul de identificare creditor din instrucțiunea SDD este identic cu cel din mandat

data semnarii mandatului este anterioară (sau egală) datei curente

perioada precizată pentru valabilitatea mandatului nu a expirat (start date, end date)

încadrarea în limitele de sumă (suma fixă sau suma minimă/maximă)

frecventa aplicarii mandatului: one-off, zilnic, lunar, trimestrial, anual.

3 În cadrul schemei Core se procesează mesajele SDD în care debitorii sunt persoane fizice. 4 În cadrul schemei B2B se procesează mesajele SDD în care debitorii sunt persoane juridice.

PROGRAMUL SEPA



SDD Return – pacs. 004.001.02

Acest mesaj este inițiat după decontarea SDD de Banca Debitoare (câmpul “Return Originator” este completat cu un cod BIC) dintr-o instrucțiune SDD decontată și reprezintă o solicitare de rambursare a fondurilor aferente instrucțiunii SDD decontate. Se inițiază dacă banca debitorului nu poate debita contul debitorului, dar instructiunea a fost deja decontată (să zicem că, de exemplu banca a ”uitat ” să refuze la timp ) Este un mesaj de debit cu decontare în aceeași zi (similar debitului direct dar fără perioada de asteptare). Schema SDDCore Instrucțiunile SDD Return trebuie inițiate în termenul T- T+5, T =data decontarii Schema SDD B2B Instrucțiunile SDD Return trebuie inițiate în termenul T- T+2, T =data decontarii

Aplicația centrală verifică dacă instrucțiunea SDD Return este inițiată în termenul permis.

Informațiile din mesajul SDD Return trebuie să corespundă informațiilor din instrucțiunea SDD-RON care face obiectul mesajului SDD RETURN:




Codul de motivare RETURN trebuie să fie completat/un cod valid (deci nu se face la întâmplare, trebuie să existe motive serioase și reale ).

SDD REFUND – pacs. 004.001.02

Acest mesaj este inițiat după decontare, de către însuși clientul Debitor (și ca atare câmpul “Return Originator” este completat cu un nume și nu cu un BIC) dintr-o instrucțiune SDD decontată și reprezintă o solicitare de rambursare a fondurilor aferente instrucțiunii SDD decontate.

Este un mesaj de debit cu decontare în aceeași zi (se compensează similar unui SDD, dar chiar in momentul primirii/validării cu limita de colateral).

Acest tip de mesaj poate fi inițiat doar pe schema SDD Core5.

Instrucțiunile de SDD Refund trebuie inițiate (primite la sistem) în termen de:

maxim 8 săptămâni+2 zile de la data decontării SDD inițial – orice tip de SDD

maxim 13 luni de la data decontării SDD inițial – în cazul decontării

Aplicația centrală verifică dacă instrucțiunea SDD Refund este inițiată în termenul permis.

Informațiile din mesajul SDD Refund trebuie să corespundă informațiilor din instrucțiunea SDD-RON care face obiectul mesajului SDD REFUND.




5 Deoarece în cadrul schemei B2B validarea instrucțiunilor SDD cu mandatul este obligatorie pentru băncile debitoare, în cadrul schemei

B2B debitorilor nu li se permite solicitarea rambursării fondurilor plătite printr-un SDD.

PROGRAMUL SEPA



neautorizate de către debitor a unei instrucțiuni SDD

SDD Reject pacs. 002.001.03– transmis de banca debitoare

Acesta este un mesaj inițiat înainte de decontare de Banca Debitoare dintr-o instrucțiune SDD și reprezintă refuzul acesteia sau al clientului acesteia de a plăti instrucțiunea SDD (similar refuzului de DD actual, doar că se numește Reject în cadrul SEPA).

Instrucțiunile SDD Reject trebuie inițiate de băncile debitoare până în T (data decontării SDD), înainte să fie compensată instrucțiunea/ batchul SDD care se dorește refuzat.

Aplicația centrală verifică dacă instrucțiunea SDD Reject este inițiată în termenul permis.

Informațiile din mesajul SDD Reject trebuie să corespundă informațiilor din instrucțiunea SDD-RON care face obiectul mesajului SDD REJECT.



(optional) OriginalTransactionIdentification

Codul de REJECT este un cod valid.

SDD Reversal pacs. 07.001.02

Dacă în calitate de bancă Creditoare ați încasat printr-un SDD o sumă de la o altă bancă și ați realizat, ulterior decontării, că nu ar fi trebuit să se întâmple așa ceva, veți putea îndrepta situația printr-un SDD Reversal: mesaj de returnare a unor fonduri încasate în prealabil printr-un SDD.

Instrucțiunile SDD Reversal trebuie inițiate de Banca Creditoare în termen maxim de 2 zile de la data decontării instrucțiunii SDD.

Respectarea parametrilor de sistem privind perioadele de transmitere (Date≤T+2)

Informațiile din mesajul SDD Reversal corespund informațiilor din instrucțiunea SDD-RON care face obiectul mesajului SDD REVERESAL:




Codul de REVERSAL este un cod valid.

2.6. Compensarea batch-urilor de către aplicația centrală SEPA

2.6.1. Sortarea batchurilor de clearing

Aplicația centrală sortează fiecare batch transmis de participanții direcți în batch-uri de clearing.Un batch de clearing are :

același participant direct expeditor (Instructing Agent)

același participant direct destinatar (Instructed Agent)

aceeași dată a decontării

aceleași tipuri de instrucțiuni

aceeasi moneda (deocamdată va fi o singură moneda, dar din 2012 sistemul va procesa și plăți în euro)

Dacă participantul direct destinatar este un participant care utilizeaza mesaje în format SEPA, sistemul efectuează sortarea în funcție de participanții indirecți ai participantului direct astfel:

un batch de clearing pentru instrucțiunile în care Instructed Agent este același cu Creditor Agent (SCT-RON) sau Debtor Agent (SDD-RON)

PROGRAMUL SEPA


câte un batch de clearing pentru fiecare participant indirect (Creditor Agent sau Debtor Agent) destinatar.

2.6.2. Alocarea de referințe Sistemul atribuie referințe proprii unice mesajelor SEPA rezultate din sortare:

Message ID (header)

Instruction ID (item)

Participantul initiator poate regăsi o instructiune transmisa atât dupa referințele initiale cât si dupa cele alocate de sistem.

2.6.3. Procesul de compensare

Compensarea se face pe conturile tehnice ale participanților direcți (Instructing Agent şi Instructed Agent) care se actualizeaza cu fiecare tranzacție care le afectează.

Tranzacţiile corespunzătoare batch-urilor de clearing sunt compensate pe durata perioadelor de compensare aferente fiecărei sesiuni.

La testarea pentru compensare a unei tranzacții, sistemul verifica încadrarea valorii tranzacției (clearing batch) în:

limita de garantare aferentă participantului direct respectiv:

limita debitoare maximă bilaterală în relația cu:

participantul direct SENT aflat în poziție creditoare în mesaj participanul indirect propriu pentru care se procesează mesajul (limita debitoare multilaterală a participantului indirect).

limita multilaterală.

2.6.4. Priorităţi. Coada de așteptare

Noua aplicație SENT permite setarea priorității compensării pe tipuri de instrucțiuni.

Sistemul va respecta urmatoarea ordine de compensare:

1. pachetele cu instrucțiuni ID/DD/SDD-RON, prin inițierea automată a mecanismului de gridlock la începutul primei sesiuni din ziua de operare sesiune, daca toti participantii in pozitie debitoare pentru ID/DD/SDD au setat colateral la nivelul cerut in raportul de ID/SDD/DD din T-1.

In mod implicit instrucțiunilede DD/SDD/ID scadente în ziua de decontare actuală au prioritate la compensare si sunt compensate înaintea celor OP/SCT, respectand regulile actuale pentru DD/ID. În caz contrar, sunt puse in coada de asteptare în tranzacții cu status PENDING

Ulterior, ID/DD/SDD din coada de asteptare sunt compensate înaintea tranzactiilor cu instrucțiuniSCT/CT, atunci cand limita de garantare permite (implicit in ordinea recepționarii sau a ordinii din coada de asteptare)

2. daca nu mai sunt SDD/ID/DD în coada de asteptare, se compenseaza, conform FIFO

CT

SCT-RON

SCT-RON/SDD-RON RETURN

Positive Answer to a Recall

SDD Refund/Reversal

În cazul în care nu există suficiente fonduri disponibile care să permită compensarea unei tranzacții, aceasta este plasată într-o coadă de așteptare cu status PENDING6.

6 Acest lucru este valabil pentru toate batchurile de clearing, cu instrucțiuni SEPA sau non-SEPA.

PROGRAMUL SEPA


Dacă doresc, participanții pot schimba prioritatea tranzacţiilor de clearing în coada de asteptare. Prioritatile sunt de la 1 la 100, 1 fiind prioritatea maxima.

2.6.5. Starea tranzactiilor

Pe parcursul unei zile de operare tranzactiile au unul din urmatoarele statusuri:

ENTER

CLEARING(Limit check)

CLEARED

FUTURE READY PENDING TRANSFER

CANCELED

ENTER - stare iniţială pentru fiecare tranzacţie nouă. În funcţie de value date şi de momentul transmiterii, tranzacţia este trecută în starea FUTURE, READY sau CLEARED.

FUTURE - starea tranzacţiilor până în ziua în care value date coincide cu data curentă.

READY- starea tranzacţiilor care nu pot fi compensate deoarece nu este deschisă nicio sesiune de compensare. La Start-of-day, tranzacţiile în starea FUTURE pentru care value date coincide cu data curentă devin READY.

PENDING - starea tranzacţiilor (indiferent de tip: SDD, DD, ID, CT, SCT) care nu pot fi compensate din cauza limitei de garantare sau a celorlalte limite stabilite (bilaterale, multilaterale). Ele pot fi compensate oricând există fonduri suficiente sau se încadrează în limitele stabilite şi au prioritatea cea mai mare. Procesul de verificare cu limita de garantare sau cu limitele debitoare are loc atunci când participantul primește încasări sau este inițiat un proces de gridlock. La sfârşitul procesului de compensare, tranzacţiile au starea COMPLETE, CANCELED sau TRANSFER.

TRANSFER - starea tranzacţiilor care nu au fost compensate pe parcursul unei sesiuni de compensare, dar urmează a se relua procesul lor de compensare în următoarea perioadă de compensare7.

COMPLETE - stare finală pentru tranzacţiile compensate și decontate.

CANCELED - stare finală pentru tranzacţiile care nu au putut fi compensate până la sfârşitul perioadei cât pot fi transferate.

2.6.6. Gridlock resolution mechanism Sistemul asigură o optimizare a procesului de clearing, prin simularea unui netting la momente prestabilite. Sistemul caută tranzacții în cozile tuturor participanților care, dacă ar fi compensate simultan, s-ar respecta condiâia de garantare (de exemplu: dacă A are limita de colateral ”0” și B tot ”0”, și există în sistem în coada de așteptare a lui A o tranzacție de valoarea 100 RON de la A către B și în coada

7 Acest status este alocat tranzacțiilor care nu au putut fi compensate nici în ultima sesiune de compensare dintr-o zi

de operare, dar a căror compensare poate fi amânată/transferată pe ziua de operare următoare. Acest lucru este posibil doar prin activarea unui parametru la nivelul aplicatiei centrale, prin care se definește numărul de zile pentru care compensarea unui anumit tip de instrucțiune poate fi “transferată”. În cazul în care acest parametru are valoarea n, de ex, și nu s-a reușit compensarea unor instrucțiuni “transferabile” nici în T+n, aplicația centrală va rejecta instrucțiunile respective la Start-of-Day în T+n+1.

PROGRAMUL SEPA


lui B o tranzacție de 100 RON de la B către A, sistemul le compensează pe amândouă, întrucât nu modifică poziția netă a niciunui participant; în prezent, ambele tranzacții sunt rejectate încă de la primire).

2.6.7. Procesarea la sfârşitul sesiunii de compensare

Modul de finalizare a ciclului de compensare este nemodificat.

După momentul Clearing Cut-Off:

sistemul oprește compensarea și stabilește pozițiile nete multilaterale finale ale participanților direcți (pe baza tranzacțiilor compensate până la acel moment)

sistemul generează rapoartele privind pozițiile nete multilaterale ale participanților direcți

participanții își pot vizualiza pozițiile nete în meniul interfeței grafice a aplicației SENT.

La sfârșitul ultimei sesiuni de compensare (End-of-Clearing) dintr-o zi de operare, sistemul rejectează tranzacțiile care nu au putut fi compensate (status CANCELED).

2.7. Decontare in ReGIS

Modul de generare și transmitere a instrucțiunilor NSI este nemodificat.

Modul în care are loc decontarea este nemodificat.

Dupa decontare, conturile tehnice ale tuturor participanților au valoarea zero.

2.8. Conversia mesajelor

După decontare, sistemul efectuează următoarele conversii de mesaje:

mesaj SVPO curent (CoreBulkCreditTransfer) -> mesaj SCT-RON (pacs.008.002.01)

mesaj SCT-RON (pacs.008.002.01) – mesaj SVPO curent (CoreBulkCreditTransfer)

mesaj SVPO de returnare curent (CoreBulkCreditTransfer) – mesaj SEPA RETURN (pacs.004.001.02)

mesaj SEPA RETURN (pacs.004.001.02) - mesaj SVPO de returnare curent CoreBulkCreditTransfer

Pentru mai multe detalii privind maparea câmpurilor, vă rugăm consultați secțiunea 1.5 Facilitatea de conversie.

În cazul în care atât participantul inițiator, cât și participantul destinatar utilizează standardul de format SENT actual (SVPO), sistemul nu afectează mesajul de SVPO și îl trimite ca atare participantului destinatar (ca în prezent).

2.9. Semnarea batchurilor de către aplicația centrală

Sistemul semnează electronic cu semnătură electronică simplă mesajele pe care le transmite participanților direcți in urmatoarele cazuri:

fisierele care trebuie transmise participanților destinatari în format SEPA indiferent de formatul in care au fost primite.

fișiere CT (SVPO)/CT Returnare care au fost convertite din formatul SCT/SCT Returnare (participantul destinatar nu foloseste formatul SEPA).

2.10. Transmiterea batchurilor catre participanții destinatari Sistemul transmite participanților destinatari batchurile cu instrucțiuni astfel:

după decontare: CT, SCT, Return SCT, Positive Answer, SDD Return, SDD Refund, SDD Reversal (la primirea confirmării de la ReGIS).

după aprobare și validare: SDD, DD, ID, RDD, RID, SCT Recall, SDD Reject, Negative Answer to Recall.

PROGRAMUL SEPA


Instrucțiunile în format SEPA adresate unor participanți indirecți vor fi transmise participanților direcți aferenți sortate în funcție de participantul indirect destinatar.

2.11. Notificari

Sistemul va transmite notificări participanților referitoare la starea mesajelor primite.

Pentru mesajele transmise prin FTM, sistemul va genera aceleași notificari ca în prezent (ACK, NAK).

2.11.1. Notificări status mesaje – Payment Status Report (PSR) și alerte generate de aplicația centrală

Pentru mesajele în format SEPA, sistemul generează mesaje de notificare în format SEPA PSR (pacs.002.001.03) dupa cum urmeaza:

Imediat dupa validarea unui pachet recepționat pe central:

dacă pachetul împreuna cu toate instructiunile sale sunt valide

în notificare statusul pachetului va fi “ACCEPTED”. Nu vor apărea referiri la instrucțiunile pachetului în aceasta notificare.

imediat după compensare, se generează o notificare PSR în care statusul batch-ului este „ACCEPTED” și statusurile instrucțiunilor compensate sunt „CLEARED”

daca au fost identificare erori la nivel de pachet, în notificare statusul pachetului va fi “REJECT” și vor fi menționate toate instructiunile, cu status “REJECT”.

daca au fost identificate erori doar la nivel de instructiune:

în notificare statusul pachetului va fi „PARTIAL”, și vor fi mentionate doar instructiunile invalide cu status “REJECT”.

imediat dupa ce se compenseaza tranzacțiile care includ restul instrucțiunilor valide, se generează o notificare cu status pachet „PARTIAL” și statusurile instructiunilor compensate „CLEARED”.

La sfârșitul sesiunii de compensare se transmite câte o notificare pentru fiecare pachet nesortat (pachet din care s-au creat tranzactii pentru acea sesiune), cu status pachet “PARTIAL”, statusurile instructiunilor decontate „SETTLED” si statusurile instructiunilor eliminate din procesare (de exemplu prin mesaje SEPA „R”) „REJECT”. Nu sunt notificate statusurile instructiunilor corespunzatoare tranzactiilor transferate pe urmatoarea sesiune.

2.11.2. Alerte

Sistemul generează alerte către utilizatorii sistemului, vizibile de către aceștia în orice moment (în ecranul aplicaţiei, numai pentru utilizatorii conectaţi la aplicaţie), indiferent de ecranul în care se află sau momentul din orar.

Eveniment Tip alerta

Mesaj .xml Mesaj e-mail Alerta în interfața aplicației

Lipsă spațiu pe disc

Modificare orar curent Modificare calendar

Modificare detalii/status participant

PROGRAMUL SEPA


2.12. Rapoarte

Noul sistem generează rapoarte care includ informații referitoare la toate tipurile de mesaje procesate de participanții la sistem (direcți și indirecți).

Pentru participanții indirecți care utilizeaza mesaje SEPAsistemul generează rapoarte distincte, cu excepția următoarelor rapoarte:

”Raport poziţii nete calculate SENT”,

“Decontare SENT”,

„Sfârşit de sesiune”,

“SDD/DI/DD pentru participanţi”.

Aceste patru rapoarte sunt generate numai pentru participanții direcți și cuprind date privind activitatea participantului direct și a participanților săi indirecți.

Pentru participanții indirecți ai participanților direcți care nu utilizeaza mesaje SEPA, sistemul nu generează rapoarte.

La sfârșitul fiecărei sesiuni de compensare, dar și la sfârșitul zilei, sistemul generează rapoarte referitoare la toate operațiile procesate într-o sesiune de compensare/zi de operare în relație cu fiecare/toți participanții.

La solicitarea utilizatorilor, sistemul poate genera și rapoarte parțiale (intraday reports).

Rapoartele vor putea fi generate în format PDF, XLS și HTML. Sistemul va permite utilizatorilor descărcarea rapoartelor în format PDF, semnate de sistem.

Denumire raport Modul de generare

Momentul generării Raportul se

trimite pe Lotus?

Constituire garanţii Automat

După primirea de către sistem a garanțiilor constituite de participanți în sistemele ReGIS și SaFIR

Da

Poziţie participant Automat După transmiterea IDN către ReGIS. Nu Raport poziţii nete calculate SENT

Automat După transmiterea IDN către ReGIS Da

Decontare SENT Automat După transmiterea IDN către ReGIS Nu Sfârşit de sesiune

Automat La sfârșitul fiecărei sesiuni de compensare

Da

Raport activitate participant (File Activity Report)

La cerere În orice moment, pe parcursul zilei Da

Raport instrucțiuni care depășesc limita minimă (Large Payments Report)

La cerere În orice moment, pe parcursul zilei Nu

Duplicate

Automat După Momentul limită de transmitere a refuzurilor DD/SDD/ID

Nu

SDD/ID/DD pentru Participant

Automat După Momentul limită de transmitere a refuzurilor DD/SDD/ID

Da

PROGRAMUL SEPA


Denumire raport Modul de generare

Momentul generării Raportul se

trimite pe Lotus?

Raport instrucțiuni nedecontate

La cerere

Nu

2.13. Facilități de monitorizare online pentru participant

Participanții au acces la informații privind propria activitate în aplicația centrală, respectiv:

Plafonul de garantare și structura lui

Limita de colateral

Limitele pentru subparticipanţi (valori iniţiale şi valori actuale/disponibile)

Poziția netă multilaterală/bilaterală

Total debit/total credit (activitate, extras de cont)

Starea sistemului

Detalii participant/utilizatori proprii/profile

Calendar/orar sistem

Detalii privind propriile pachete/instrucțiuni transmise și recepționate (pentru care se află în calitatea de sender sau receiver)

În calitate de inițiator, participantul poate vizualiza pachetele în formatul original

În calitate de destinatar, participantul poate vizualiza pachetele în formatul recepționat.

Modul de căutare/vizualizare a pachetelor/instrucțiunilor DD/ID rămâne nemodificat, inclusiv pentru imagini ID.

Program SEPA - Buletin Informativ Nr 9_final

Documents

Transcript of Program SEPA - Buletin Informativ Nr 9_final