PROGRAMUL SEPA
SEPA (Single Euro
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.
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: sepa@transfond.ro
REGIM: Confidenţial
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.
Pagina 1 din 27
 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.

REGIM: Confidenţial Pagina 2 din 27

 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.

REGIM: Confidenţial Pagina 3 din 27

 PROGRAMUL 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 DD 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).

1
Aceasta 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.

REGIM: Confidenţial Pagina 4 din 27

 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.
2
ID 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> <CdtTrf><FrstAgt><BIC>
Bank-to-SENT
ID29BIC <GrpHdr><InstdAgt><FinInstnId><BIC> - <CdtTrf><FnlAgt><BIC>
SENT-to-Bank
ID10T <CdtTrfTxInf><PmtId><TxId> <CdtTrf><PmtInstr><InstrRef>
ID11BIC <CdtTrfTxInf>< InstgAgt>< FinInstnId><BIC> <CdtTrf><FrstAgt><BIC>
- SENT-to-Bank
<CdtTrf><PmtInstr> <SttlmInstr>
<IntrBkSttlmAmt>
+
ID12N <CdtTrfTxInf><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.

REGIM: Confidenţial Pagina 5 din 27

 PROGRAMUL SEPA

2
ID SCT tag CT tag
ID20BIC <CdtTrfTxInf><DbtrAgt><FinInstnId><BIC> <CdtTrf><FrstAgt><BIC>
sau indirect BIC din ID19IBAN
ID21BIC <CdtTrfTxInf><CdtrAgt> <FinInstnId><BIC>
<CdtTrf><FnlAgt><BIC>
sau indirect BIC din ID27IBAN
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"?> <?xml version="1.0" encoding="utf-8"?>
<CoreBlkLrgRmtCdtTrf <Document
xmlns="urn:swift:xsd:CoreBlkLrgRmtCdtTrf" > xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02">
<GrpHdr> <FIToFICstmrCdtTrf>
<GrpId>ID01T</GrpId> <GrpHdr>
<IndvItmTtlNb>ID03N</IndvItmTtlNb> <MsgId>ID01T</MsgId>
<TtlSttlmAmt Ccy = <CreDtTm>ID02D</CreDtTm>
"RON">ID04N</TtlSttlmAmt> <NbOfTxs>ID03N</NbOfTxs>
<IntrBkValDt>ID05D</IntrBkValDt> <TtlIntrBkSttlmAmt
<CreDt>ID02D</CreDt> Ccy="RON">ID04N</TtlIntrBkSttlmAmt>
</GrpHdr> <IntrBkSttlmDt>ID05D</IntrBkSttlmDt>
<CdtTrf> <SttlmInf>
<PmtInstr> <SttlmMtd>CLRG</SttlmMtd>
<InstrRef>ID10T</InstrRef> <ClrSys>
<SttlmInstr> <Prtry>SENT</Prtry>
<IntrBkSttlmAmt Ccy = </ClrSys>
"RON">ID12N</IntrBkSttlmAmt> </SttlmInf>
</SttlmInstr> <InstdAgt>
</PmtInstr> <FinInstnId>
<FrstAgt> <BIC> ID21BIC </BIC>
<BIC>ID20BIC</BIC> </FinInstnId>
</FrstAgt> </InstdAgt>
<FnlAgt> </GrpHdr>
<BIC>ID21BIC</BIC>
</FnlAgt> <CdtTrfTxInf>
<PmtTx> <PmtId>
<InstdAmt Ccy = "RON">ID12N</InstdAmt> <EndToEndId>NOTPROVIDED</EndToEndId>
<ChrgBr>ID13T</ChrgBr> <TxId>ID10T</TxId>
<DbtrAcct> </PmtId>
<Id> <PmtTpInf>
<IBAN>ID19IBAN</IBAN> <SvcLvl>
</Id> <Cd>SEPA</Cd>
</DbtrAcct> </SvcLvl>

REGIM: Confidenţial Pagina 6 din 27

 PROGRAMUL SEPA

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

<CdtrAcct> </PmtTpInf>
<Id> <IntrBkSttlmAmt Ccy="RON">ID12N</IntrBkSttlmAmt>
<IBAN>ID27IBAN</IBAN> <ChrgBr>ID13T</ChrgBr>
</Id> < InstgAgt >
</CdtrAcct> <FinInstnId>
<Dbtr> <BIC> ID20BIC</BIC>
<NFI> </FinInstnId>
<IdAndNmAdr> </ InstgAgt >
<Id> <Dbtr>
<ROURC>ID18N</ROURC> <Nm>ID14T</Nm>
</Id> <PstlAdr>
<NmAndAdr> <Ctry>ID15T</Ctry>
<Nm>ID14T</Nm> <AdrLine>ID16T</AdrLine>
<LngPstlAdrChc> <AdrLine>ID17T</AdrLine>
<Ustrd>ID15T+ID16T+ID17T</Ustrd> </PstlAdr>
</LngPstlAdrChc> <Id>
</NmAndAdr> <PrvtId>
</IdAndNmAdr> <Othr>
</NFI> <Id>ID18N</Id>
</Dbtr> <SchmeNm>
<Cdtr> <Prtry>ROURC</Prtry>
<NFI> </SchmeNm>
<IdAndNmAdr> </Othr>
<Id> </PrvtId>
<ROURC>ID26N</ROURC> </Id>
</Id> </Dbtr>
<NmAndAdr> <DbtrAcct>
<Nm>ID22T</Nm> <Id>
<LngPstlAdrChc> <IBAN>ID19IBAN</IBAN>
</Id>
<Ustrd>ID23T+ID24T+ID25T</Ustrd> </DbtrAcct>
</LngPstlAdrChc> <DbtrAgt>
</NmAndAdr> <FinInstnId>
</IdAndNmAdr> <BIC>ID20BIC sau indirect din IBAN</BIC>
</NFI> </FinInstnId>
</Cdtr> </DbtrAgt>
<RmtInf> <CdtrAgt>
<Ustrd>ID28T</Ustrd> <FinInstnId>
</RmtInf> <BIC>ID21BIC sau indirect din IBAN</BIC>
</PmtTx> </FinInstnId>
</CdtTrf> </CdtrAgt>
</CoreBlkLrgRmtCdtTrf> <Cdtr>
<Nm>ID22T</Nm>
<PstlAdr>
<Ctry>ID23T</Ctry>
<AdrLine>ID24T</AdrLine>
<AdrLine>ID25T</AdrLine>
</PstlAdr>
<Id>
<PrvtId>
<Othr>
<Id>ID26N</Id>
<SchmeNm>

REGIM: Confidenţial Pagina 7 din 27

 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"?> <?xml version = "1.0" encoding = "UTF-8"?>
<Document <CoreBlkLrgRmtCdtTrf
xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.02"> xmlns="urn:swift:xsd:CoreBlkLrgRmtCdtTrf" >
<FIToFICstmrCdtTrf> <GrpHdr>
<GrpHdr> <GrpId>ID01T</GrpId>
<MsgId>ID01T</MsgId> <IndvItmTtlNb>ID03N</IndvItmTtlNb>
<CreDtTm>ID02D</CreDtTm> <TtlSttlmAmt Ccy =
<NbOfTxs>ID03N</NbOfTxs> "RON">ID04N</TtlSttlmAmt>
<TtlIntrBkSttlmAmt <IntrBkValDt>ID05D</IntrBkValDt>
Ccy="RON">ID04N</TtlIntrBkSttlmAmt> <CreDt>ID02D</CreDt>
<IntrBkSttlmDt>ID05D</IntrBkSttlmDt> </GrpHdr>
<SttlmInf> <CdtTrf>
<SttlmMtd>CLRG</SttlmMtd> <PmtInstr>
<ClrSys> <InstrRef>ID10T</InstrRef>
<Prtry>SENT</Prtry> <SttlmInstr>
</ClrSys> <IntrBkSttlmAmt Ccy =
</SttlmInf> "RON">ID12N</IntrBkSttlmAmt>
<InstgAgt> </SttlmInstr>
<FinInstnId> </PmtInstr>
<BIC>ID08BIC</BIC> <FrstAgt>
</FinInstnId> <BIC> ID08BIC </BIC>
</InstgAgt> </FrstAgt>
</GrpHdr> <FnlAgt>
<BIC>ID21BIC sau se cauta in routing table
<CdtTrfTxInf> BICul directului</BIC>
<PmtId> </FnlAgt>
<EndToEndId>NOTPROVIDED</EndToEndId> <PmtTx>
<TxId>ID10T</TxId> <InstdAmt Ccy = "RON">ID12N</InstdAmt>
</PmtId> <ChrgBr>ID13T</ChrgBr>
<PmtTpInf> <DbtrAcct>
<SvcLvl> <Id>
<Cd>SEPA</Cd> <IBAN>ID19IBAN</IBAN>

REGIM: Confidenţial Pagina 8 din 27

 PROGRAMUL SEPA

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

</SvcLvl> </Id>
</PmtTpInf> </DbtrAcct>
<IntrBkSttlmAmt <CdtrAcct>
Ccy="RON">ID12N</IntrBkSttlmAmt> <Id>
<ChrgBr>ID13T</ChrgBr> <IBAN>ID27IBAN</IBAN>
<Dbtr> </Id>
<Nm>ID14T</Nm> </CdtrAcct>
<PstlAdr>
<Ctry>ID15T</Ctry> <Dbtr>
<AdrLine>ID16T</AdrLine> <NFI>
<AdrLine>ID17T</AdrLine> <IdAndNmAdr>
</PstlAdr> <Id>
<Id> <ROURC>ID18N</ROURC>
<PrvtId> </Id>
<Othr> <NmAndAdr>
<Id>ID18N</Id> <Nm>ID14T</Nm>
<SchmeNm> <LngPstlAdrChc>
<Prtry>ROURC</Prtry> <Ustrd>ID15T+ID16T+ID17T</Ustrd>
</SchmeNm> </LngPstlAdrChc>
</Othr> </NmAndAdr>
</PrvtId> </IdAndNmAdr>
</Id> </NFI>
</Dbtr> </Dbtr>
<DbtrAcct> <Cdtr>
<Id> <NFI>
<IBAN>ID19IBAN</IBAN> <IdAndNmAdr>
</Id> <Id>
</DbtrAcct> <ROURC>ID26N</ROURC>
<DbtrAgt> </Id>
<FinInstnId> <NmAndAdr>
<BIC>ID20BIC</BIC> <Nm>ID22T</Nm>
</FinInstnId> <LngPstlAdrChc>
</DbtrAgt> <Ustrd>ID23T+ID24T+ID25T</Ustrd>
<CdtrAgt> </LngPstlAdrChc>
<FinInstnId> </NmAndAdr>
<BIC>ID21BIC</BIC> </IdAndNmAdr>
</FinInstnId> </NFI>
</CdtrAgt> </Cdtr>
<Cdtr> <RmtInf>
<Nm>ID22T</Nm> <Ustrd>ID28T</Ustrd>
<PstlAdr> </RmtInf>
<Ctry>ID23T</Ctry> </PmtTx>
<AdrLine>ID24T</AdrLine> </CdtTrf>
<AdrLine>ID25T</AdrLine> </CoreBlkLrgRmtCdtTrf>
</PstlAdr>
<Id>
<PrvtId>
<Othr>
<Id>ID26N</Id>
<SchmeNm>
<Prtry>ROURC</Prtry>
</SchmeNm>
</Othr>

REGIM: Confidenţial Pagina 9 din 27

 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:

Nr Preluare in mesaj SEPA (pacs 008)

Info necesar curente in OP conform Normelor caractere In tag dedicat
In Remittance Info
(max) (distinct)
/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)

REGIM: Confidenţial Pagina 10 din 27

 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ă:

Preluare in mesaj SEPA (pacs 004) in urma

Info necesare in OP Nr
conversiei
(curent) caractere
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>
<TxInf><OrgnlIntrBkSttlmAmt> +
<CdtTrf> <PmtTx> <InstdAmt> +
<TxInf><RtrdIntrBkSttlmAmt>
ID10N <CdtTrf> <PmtInstr> <SttlmInstr>
Aceste doua sume trebuie sa fie identice
<IntrBkSttlmAmt>
<TxInf><RtrRsnInf><Orgtr><Id><OrgId><BIC
ID12BIC -- se completeaza în RmtInf --
OrBEI>
ID13T <TxInf><RtrRsnInf><Rsn><Cd> -- se completeaza în RmtInf --
<TxInf><OrgnlTxRef><IntrBkSttlmDt> <CdtTrf> <PmtInstr> <InstrRef> <SttlmInstr>
ID14D
<IntrBkValDt>
ID15T <TxInf><OrgnlTxRef><RmtInf> < CdtTrf> <PmtTx> <RmtInf>
<TxInf><OrgnlTxRef><Dbtr><Nm> <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>
ID16T
<NmAndAdr><Nm>
<TxInf><OrgnlTxRef><Dbtr><PstlAdr><Ctry> <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>
ID17T
<NmAndAdr><LngPstlAdrChc><Ustrd>
<TxInf><OrgnlTxRef><Dbtr><PstlAdr><AdrLi <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>
ID18T
ne> <NmAndAdr><LngPstlAdrChc><Ustrd>
<TxInf><OrgnlTxRef><Dbtr><PstlAdr><AdrLi <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>
ID19T
ne> <NmAndAdr><LngPstlAdrChc><Ustrd>
<TxInf><OrgnlTxRef><Dbtr><Id><PrvtId><Ot <CdtTrf><PmtTx><Dbtr><NFI><IdAndNmAdr>
ID20N
hr><Id> <Id><ROURC>
ID21IBAN <TxInf><OrgnlTxRef><DbtrAcct><Id><IBAN> <CdtTrf><PmtTx><DbtrAcct><Id><IBAN>
<TxInf><OrgnlTxRef>
ID22BIC <CdtTrf><FrstAgt><BIC>
<DbtrAgt><FinInstnId><BIC>
ID23BIC <TxInf><OrgnlTxRef><CdtrAgt><FinInstnId> <CdtTrf><FnlAgt><BIC>

REGIM: Confidenţial Pagina 11 din 27

 PROGRAMUL SEPA

ID SCT Return Return CT

<BIC>
<TxInf><OrgnlTxRef><Cdtr><Nm> <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr>
ID24T
<NmAndAdr><Nm>
<TxInf><OrgnlTxRef><Cdtr><PstlAdr><Ctry> <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr>
ID25T
<NmAndAdr><LngPstlAdrChc><Ustrd>
<TxInf><OrgnlTxRef><Cdtr><PstlAdr><AdrLi <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr>
ID26T
ne> <NmAndAdr><LngPstlAdrChc><Ustrd>
<TxInf><OrgnlTxRef><Cdtr><PstlAdr><AdrLi <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr>
ID27T
ne> <NmAndAdr><LngPstlAdrChc><Ustrd>
<TxInf><OrgnlTxRef><Cdtr><Id><PrvtId><Ot <CdtTrf><PmtTx><Cdtr><NFI><IdAndNmAdr>
ID28N
hr><Id> <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.

REGIM: Confidenţial Pagina 12 din 27

 PROGRAMUL SEPA

2.3. Transmiterea batch-urilor & modulele de transmitere

FTM Gateway
SVPO SEPA CT (pacs.008)
SVPO de returnare SEPA CT Return (pacs.004)
DD SEPA CT Recall (camt.056)
RDD SEPA CT Positive Answer to a Recall (pacs.004)
Tipuri de CEC SEPA CT Negative Answer to a Recall (camt.029)
instrucțiuni RCEC SEPA DD Collection (pacs.003)
BO SEPA DD Return (pacs.004)
RBO SEPA DD Reject (pacs.002)
CAM SEPA DD Refund (pacs.004)
RCAM 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.

REGIM: Confidenţial Pagina 13 din 27

 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ă):

Î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
Modul semnând automat batchurile cu un certificat simplu.
Manual Semnătura electronică este validată în cazul fișierelor care sunt încărcate gata
(default) 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.

Î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
Modul
modificate, de asemenea prin MQ, la aplicația STP.
STPSign
În acest mod se face validarea de semnătură electronică pentru mesajele primite din
ambele direcții.

În acest mod, Gateway primeste mesajele XML nesemnate de la aplicatia STP a

Modul băncii, le semnează și le trimite la sistemul central. Mesajelor venite de la sistemul
GatewaySign 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.

REGIM: Confidenţial Pagina 14 din 27

 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).

REGIM: Confidenţial Pagina 15 din 27

 PROGRAMUL SEPA

Orarul aplicației
Moment Eveniment
Start-of –day/
Sistemul recepţioneaza orice fel de mesaje (DI doar in ferestre) dupa acest moment.
Inceput fereastră ID

Setarea, de către operatorul TRANSDFOND (la cererea participanților direcți) sau

Setare garanții &
limite de expunere
participanti (dacă este
cazul)
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 Sistemul calculeaza plafonul de garantare pe baza datelor primite de la sistemele
(ReGIS si SaFIR) ReGIS si SaFIR

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

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
Sfârşit proces de
PARTIAL). Tranzactiile in status PENDING sunt amânate de asemenea pentru
compensare
sesiunea urmatoare.
Se calculează NSI.

Transmitere
instrucţiune de Sistemul transmite NSI la ReGIS si receptioneaza raspunsul de decontare NSI la ReGIS.
decontare pe bază
netă

Sfârşit de sesiune 1 Se generează rapoarte de sfârșit de sesiune.

Sesiunea 2, 3
.....
Interogare garantii

Sfârșit fereastră
Nu se mai pot transmite fișiere ID
ID/Cut-off ID

Cut-off transmitere
Nu mai pot fi transmise mesaje RID.
RID

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

Se generează şi se transmit rapoartele de sfârşit de zi şi participanții direcți nu vor

End-of-day
mai avea acces la unele opţiuni de meniu.

REGIM: Confidenţial Pagina 16 din 27

 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.
Este vorba de mesajul de ordin de plată Referințele alocate instrucțiunilor în format
008.001.02 de mică valoare în format electronic. SEPA CT de către participanții SENT trebuie
Trebuie să respecte aceleași reguli de să fie unice.
transmitere ca în prezent. Aplicația centrală va mai valida și respectarea
parametrilor de sistem privind perioadele de
Sistemul va putea fi setat astfel încât să transmitere
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).

SCT
Dacă dvs, în calitate de bancă
RETURN – beneficiară a unui SCT, din diverse
pacs. motive, nu puteți credita contul
004.001.02 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 Acest mesaj este o solicitare privind
RECALL – anularea unui SCT transmis sau
camt. returnarea unor fonduri care au
056.001.01
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

REGIM: Confidenţial Pagina 17 din 27

 PROGRAMUL SEPA
Tip mesaj Reguli de utilizare
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.
Positive
Dacă la primirea unui mesaj de
Answer to RECALL, sunteți de acord să
a Recall - returnați banii bancii initiatoare a
pacs RECALL-ului (recomandabil),
004.001.02 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.
REGIM: Confidenţial
Validări efectuate de aplicația centrală
mesajului Recall:
OriginalMessageIdentification
OriginalMessageNameIdentification
OriginalInstructionIdentification
(optional)
OriginalEndToEndIdentification
(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.
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.
OriginalMessageIdentification
OriginalMessageNameIdentification
OriginalInstructionIdentification
(optional)
OriginalEndToEndIdentification
(optional)
OriginalTransactionIdentification
OriginalInterbankSettlementAmount
Codul de motivare Positive Answer to a
RECALL trebuie să fie completat/un cod
valid.
Pagina 18 din 27
 PROGRAMUL SEPA
Tip mesaj Reguli de utilizare
Negative Dacă, dimpotrivă, nu doriți să
Answer to returnați suma instructiunii de SCT
a Recall – primite și solicitate înapoi prin
camt.
RECALL (în principiu,
029.001.03
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.
SDD – pacs.
Este vorba de instrucțiunea de
003.001.02 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.
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.
REGIM: Confidenţial
Validări efectuate de aplicația centrală
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.
OriginalMessageIdentification
OriginalMessageNameIdentification
OriginalInstructionIdentification
(optional)
OriginalEndToEndIdentification
(optional)
OriginalTransactionIdentification
Codul de motivare Negative Answer to a
RECALL trebuie să fie completat/un cod valid.
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.
Pagina 19 din 27
 PROGRAMUL SEPA

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

SDD Return
Acest mesaj este inițiat după Aplicația centrală verifică dacă instrucțiunea
– pacs. decontarea SDD de Banca Debitoare SDD Return este inițiată în termenul permis.
004.001.02 (câmpul “Return Originator” este Informațiile din mesajul SDD Return trebuie
completat cu un cod BIC) dintr-o să corespundă informațiilor din instrucțiunea
instrucțiune SDD decontată și SDD-RON care face obiectul mesajului SDD
reprezintă o solicitare de rambursare a RETURN:
fondurilor aferente instrucțiunii SDD OriginalMessageIdentification
decontate. OriginalMessageNameIdentification
Se inițiază dacă banca debitorului nu OriginalInstructionIdentification
poate debita contul debitorului, dar (optional)
instructiunea a fost deja decontată (să OriginalEndToEndIdentification
zicem că, de exemplu banca a ”uitat ” să (optional)
refuze la timp ) OriginalTransactionIdentification
Este un mesaj de debit cu decontare în OriginalInterbankSettlementAmount
aceeași zi (similar debitului direct dar Codul de motivare RETURN trebuie să fie
fără perioada de asteptare). completat/un cod valid (deci nu se face la
întâmplare, trebuie să existe motive serioase
Schema SDDCore și reale ).
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

SDD
Acest mesaj este inițiat după
REFUND – decontare, de către însuși clientul
pacs. Debitor (și ca atare câmpul “Return
004.001.02 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.
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.
OriginalMessageIdentification
OriginalMessageNameIdentification
OriginalInstructionIdentification
(optional)
OriginalEndToEndIdentification
(optional)
OriginalTransactionIdentification
OriginalInterbankSettlementAmount

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

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.

REGIM: Confidenţial Pagina 20 din 27

 PROGRAMUL SEPA

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

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

SDD Reject Acesta este un mesaj inițiat înainte Aplicația centrală verifică dacă instrucțiunea
pacs. de decontare de Banca Debitoare SDD Reject este inițiată în termenul permis.
002.001.03 dintr-o instrucțiune SDD și Informațiile din mesajul SDD Reject trebuie
– transmis
reprezintă refuzul acesteia sau al să corespundă informațiilor din instrucțiunea
de banca
debitoare
clientului acesteia de a plăti SDD-RON care face obiectul mesajului SDD
instrucțiunea SDD (similar refuzului REJECT.
de DD actual, doar că se numește OriginalMessageIdentification
Reject în cadrul SEPA). OriginalMessageNameIdentification
OriginalInstructionIdentification
Instrucțiunile SDD Reject trebuie (optional)
inițiate de băncile debitoare până în OriginalEndToEndIdentification
T (data decontării SDD), înainte să (optional)
fie compensată instrucțiunea/ OriginalTransactionIdentification
batchul SDD care se dorește refuzat. Codul de REJECT este un cod valid.

SDD
Dacă în calitate de bancă Creditoare
Reversal ați încasat printr-un SDD o sumă de
pacs. la o altă bancă și ați realizat, ulterior
07.001.02 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:
OriginalMessageIdentification
OriginalMessageNameIdentification
OriginalInstructionIdentification
(optional)
OriginalEndToEndIdentification
(optional)
OriginalTransactionIdentification
OriginalInterbankSettlementAmount
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)

REGIM: Confidenţial Pagina 21 din 27

 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.

REGIM: Confidenţial Pagina 22 din 27

 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
FUTURE READY (Limit check) PENDING TRANSFER

CLEARED 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 compensare 7.
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.

REGIM: Confidenţial Pagina 23 din 27

 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.

REGIM: Confidenţial Pagina 24 din 27

 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.
Tip alerta
Eveniment 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

REGIM: Confidenţial Pagina 25 din 27

 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.

Modul de Raportul se
Denumire raport Momentul generării trimite pe Lotus?
generare
Constituire garanţii După primirea de către sistem a
Automat garanțiilor constituite de participanți în Da
sistemele ReGIS și SaFIR

Poziţie participant Automat După transmiterea IDN către ReGIS. Nu

Raport poziţii nete calculate

Automat După transmiterea IDN către ReGIS Da
SENT

Decontare SENT Automat După transmiterea IDN către ReGIS Nu

Sfârşit de sesiune La sfârșitul fiecărei sesiuni de

Automat Da
compensare

Raport activitate
participant (File Activity La cerere În orice moment, pe parcursul zilei Da
Report)

Raport instrucțiuni care

depășesc limita minimă La cerere În orice moment, pe parcursul zilei Nu
(Large Payments Report)

Duplicate După Momentul limită de transmitere a

Automat Nu
refuzurilor DD/SDD/ID

SDD/ID/DD pentru După Momentul limită de transmitere a

Automat Da
Participant refuzurilor DD/SDD/ID

REGIM: Confidenţial Pagina 26 din 27

 PROGRAMUL SEPA

Modul de Raportul se
Denumire raport Momentul generării trimite pe Lotus?
generare
Raport instrucțiuni
La cerere Nu
nedecontate

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.

REGIM: Confidenţial Pagina 27 din 27