Hotărâre nr.33 din 16.02.2026 privind aprobarea Cerinţelor funcţionale şi tehnice pentru interfeţele prestatorilor de servicii de plată care oferă servicii de administrare cont

BANCA NAŢIONALĂ A MOLDOVEI

H O T Ă R Â R E

privind aprobarea Cerinţelor funcţionale şi tehnice pentru

interfeţele prestatorilor de servicii de plată care

oferă servicii de administrare cont

nr. 33  din  16.02.2026

 (în vigoare 20.03.2026) 

Monitorul Oficial al R. Moldova nr. 88-91 art.137 din 20.02.2026

* * *

În temeiul art.52⁴ alin.(7) din Legea nr.114/2012 cu privire la serviciile de plată şi monedă electronică (Monitorul Oficial al Republicii Moldova, 2012, nr.193-197, art.661), cu modificările ulterioare, şi al pct.65 din Regulamentul cu privire la autentificarea strictă a clienţilor şi standardul deschis, comun şi sigur de comunicare între prestatorii de servicii de plată, aprobat prin Hotărârea Comitetului executiv nr.12/2024 (publicat în Monitorul Oficial al Republicii Moldova, 2024, nr.36-39, art.90), Comitetul executiv al Băncii Naţionale a Moldovei

HOTĂRĂŞTE:

1. Se aprobă Cerinţele funcţionale şi tehnice pentru interfeţele prestatorilor de servicii de plată care oferă servicii de administrare cont (se anexează).

2. Prestatorii de servicii de plată prevăzuţi la art.5 alin.(1) lit.a)-c) din Legea nr.114/2012 cu privire la serviciile de plată şi moneda electronică vor asigura conformarea cu cerinţele 4 şi 5 din Tabelul nr.3 din Cerinţele funcţionale şi tehnice pentru interfeţele prestatorilor de servicii de plată care oferă servicii de administrare cont, în termen de 8 luni de la data intrării în vigoare a prezentei hotărâri.

3. Prezenta hotărâre intră în vigoare peste o lună de la data publicării în Monitorul Oficial al Republicii Moldova.

Anexă

la Hotărârea Comitetului executiv

al Băncii Naţionale a Moldovei

nr.33 din 16 februarie 2026

Cerinţe funcţionale şi tehnice pentru interfeţele prestatorilor

de servicii de plată care oferă servicii de administrare cont

Capitolul I

DISPOZIŢII GENERALE

Secţiunea 1

Obiectul şi scopul

1. Cerinţele funcţionale şi tehnice pentru interfeţele prestatorilor de servicii de plată care oferă servicii de administrare cont (în continuare – Cerinţe) stabilesc condiţiile funcţionale, tehnice şi de securitate pentru implementarea Open Banking de către prestatorii de servicii de plată care oferă servicii de administrare cont (ASPSP), în conformitate cu reglementările naţionale şi standardele internaţionale aplicabile.

2. Cerinţele reprezintă standardul naţional pentru Open Banking, au ca obiectiv asigurarea conformităţii cu prevederile Legii 114/2012 cu privire la serviciile de plată şi monedă electronică (în continuare – Legea nr.114/2012) şi ale Regulamentului nr.12/2024 cu privire la autentificarea strictă a clienţilor şi standardul deschis, comun şi sigur de comunicare între prestatorii de servicii de plată, aprobat prin Hotărârea Comitetului executiv al Băncii Naţionale a Moldovei nr.12/2024 (în continuare – Regulamentul nr.12/2024), facilitarea interoperabilităţii cu prestatorii de servicii de plată terţi şi crearea unei platforme sigure şi standardizate pentru utilizatori.

Secţiunea 2

Noţiuni principale

3. Noţiunile şi expresiile utilizate în prezentele Cerinţe au semnificaţia prevăzută în Legea nr.114/2012 şi în actele normative ale Băncii Naţionale a Moldovei (în continuare - BNM), emise în temeiul Legii nr.114/2012.

4. Suplimentar, în sensul prezentelor Cerinţe, se aplică următoarele noţiuni:

4.1. Autentificare strictă a clienţilor – autentificare care se bazează pe utilizarea a două sau mai multe elemente din categoria cunoştinţelor deţinute (ceva ce doar utilizatorul cunoaşte), a posesiei (ceva ce doar utilizatorul posedă) şi a inerenţei (ceva ce reprezintă utilizatorul). Elementele respective sunt independente, iar compromiterea unui element nu duce la compromiterea fiabilităţii celorlalte elemente. De asemenea, elementele respective sunt concepute astfel încât să protejeze confidenţialitatea datelor de autentificare;

4.2. Berlin Group – un grup de lucru care defineşte standarde tehnice pentru implementarea Open Banking în conformitate cu Directiva (UE) 2015/2366 a Parlamentului European şi a Consiliului din 25 noiembrie 2015 privind serviciile de plată în cadrul pieţei interne, de modificare a Directivelor 2002/65/CE, 2009/110/CE şi 2013/36/UE şi a Regulamentului (UE) nr.1093/2010 şi de abrogare a Directivei 2007/64/CE (text cu relevanţă pentru SEE);

4.3. Interfeţe specifice – reprezintă setul de interfeţe implementate de prestatorii de servicii de plată care oferă servicii de administrare cont, conform standardului deschis, comun şi sigur de comunicare, care permit schimbul securizat şi standardizat de informaţii între participanţi, precum şi iniţierea operaţiunilor financiare în numele utilizatorilor, cu respectarea Cerinţelor;

4.4. Prestator de servicii terţ – entitate autorizată care, cu consimţământul expres al utilizatorilor, poate accesa informaţiile financiare din conturile acestora sau poate iniţia plăţi în numele lor;

4.5. Metoda Redirect – modalitate de autentificare şi autorizare în cadrul Open Banking, prin care utilizatorul este redirecţionat din aplicaţia prestatorului de servicii terţe către aplicaţia prestatorului de servicii de plată care oferă servicii de administrare cont pentru efectuarea Autentificării Stricte a Clientului şi pentru autorizarea unei plăţi sau a accesului de date;

4.6. Dashboard – reprezintă o interfaţă digitală unificată, pusă la dispoziţia utilizatorului de către prestatorul de servicii de plată care oferă servicii de administrare cont care permite vizualizarea, controlul şi gestionarea tuturor permisiunilor acordate prestatorilor de servicii terţi pentru accesarea datelor financiare ale utilizatorului;

4.7. SCA – Autentificare strictă a clienţilor;

4.8. API – Interfeţe specifice;

4.9. ASPSP – Prestator de servicii de plată care oferă servicii de administrare cont;

4.10. AISP – Prestator de servicii de informare cu privire la conturi;

4.11. PISP – Prestator de servicii de iniţiere a plăţii;

4.12. TPP – Prestator de servicii terţ;

4.13. AIS – Serviciu de informare cu privire la conturi;

4.14. PIS – Serviciu de iniţiere a plăţii;

4.15. Open Banking – Standard deschis, comun şi sigur de comunicare, în sensul art.52⁴ alin.(7) din Legea nr.114/2012 şi pct.3 din Regulamentul nr.12/2024;

4.16. PSU – Utilizator al serviciilor de plată;

4.17. URI – Identificator Uniform de Resurse;

4.18. CAS – Serviciul de căutare al Sistemului de Plăţi Instant.

Capitolul II

MODELUL DE FUNCŢIONARE ŞI TIPURILE

DE SERVICII DISPONIBILE ÎN OPEN BANKING

5. Modelul de funcţionare Open Banking permite accesul securizat şi controlat la informaţiile financiare ale utilizatorilor şi iniţierea plăţilor în numele acestora, cu consimţământul expres al deţinătorului contului. Interacţiunea dintre părţile implicate se realizează prin intermediul API standardizate, care asigură interoperabilitatea, securitatea şi protecţia datelor utilizatorilor.

6. În Open Banking sunt disponibile următoarele tipuri de servicii:

6.1. AIS – acest serviciu permite TPP să acceseze şi să consolideze date financiare din conturile utilizatorilor de la diferiţi prestatori de servicii de plată.

6.2. PIS – acest serviciu permite TPP să iniţieze plăţi din conturile utilizatorilor, cu consimţământul acestora, prin intermediul API puse la dispoziţie de ASPSP, la care deţin conturi. Utilizatorii autorizează tranzacţiile prin mecanismele de autentificare impuse de prestatorul respectiv, conform cerinţelor de SCA.

7. ASPSP permite accesul la serviciile AIS şi PIS, TPP-urilor care:

7.1. sunt înregistraţi pentru prestarea serviciilor de informare cu privire la conturi sau licenţiaţi pentru prestarea serviciului de iniţiere a plăţii, conform prevederilor Legii nr.114/2012;

7.2. utilizează certificatele cheilor publice pentru autentificare şi semnătură electronică, conform prevederilor Legii nr.124/2022 privind identificarea electronică şi serviciile de încredere (în continuare – Legea nr.124/2022).

8. La implementarea Open Banking, ASPSP ţine cont de următoarele funcţionalităţi:

8.1. serviciile Open Banking sunt disponibile persoanelor fizice;

8.2. accesul la Open Banking este realizat prin aplicaţiile mobile a prestatorilor de servicii de plată;

8.3. conturile de plăţi sunt operate în moneda naţională (MDL), în corespundere cu Legea nr.114/2012;

8.4. produsele de plată disponibile în Open Banking includ plăţi domestice de tip A2A (domestic-payments) şi plăţi instant de tip P2P (instant-payments), oferite într-un singur serviciu de plată (“payments”) pentru iniţierea plăţilor una câte una;

8.5. autorizarea consimţămintelor şi autentificarea utilizatorilor se realizează prin metoda redirect.

Capitolul III

CERINŢE FUNCŢIONALE ŞI TEHNICE

Secţiunea 1

Cerinţe funcţionale şi de interfaţă

9. Implementarea Open Banking de către ASPSP trebuie să asigure o experienţă optimă pentru PSU, garantând securitate, accesibilitate şi transparenţă, iar cerinţele din Tabelele nr.1, nr.2 şi nr.3 să fie concentrate pe interacţiunea intuitivă a PSU cu aplicaţiile ASPSP, precum şi pe conformitatea cu standardele de securitate şi reglementările aplicabile în conformitate cu prevederile Regulamentului nr.12/2024.

10. ASPSP trebuie să asigure un design intuitiv a interfeţelor destinate Open Banking din aplicaţia mobilă, coerent şi uşor de navigat, care să permită utilizatorilor să găsească rapid informaţiile necesare.

11. ASPSP trebuie să respecte cerinţele pentru AIS, prevăzute în tabelul nr.1.

Tabelul nr.1

12. ASPSP trebuie să respecte cerinţele pentru PIS, prevăzute în tabelul nr.2.

Tabelul nr.2

13. ASPSP trebuie să respecte cerinţele şi recomandările pentru PIS şi AIS (incluse într-un Dashboard), prevăzute în tabelul nr.3.

Tabelul nr.3

Secţiunea 2

Cerinţe tehnice

14. ASPSP trebuie să asigure o infrastructură tehnică, capabilă să ofere interoperabilitate cu TPP-urile autorizate, respectând prezentele Cerinţe. Sistemele implementate trebuie să garanteze protecţia datelor PSU, integritatea tranzacţiilor şi continuitatea serviciilor furnizate.

15. ASPSP trebuie să respecte cerinţele tehnice prevăzute în tabelul nr.4.

Tabelul nr.4

16. ASPSP trebuie să respecte reglementările aplicabile la nivel naţional referitoare la furnizarea serviciilor de plată, integrarea în cadrul Open Banking şi protecţia datelor cu caracter personal.

Secţiunea 3

Interfeţe specifice

17. ASPSP are obligaţia de a pune la dispoziţia TPP interfeţe specifice, dedicate accesului securizat şi controlat la datele conturilor PSU, precum şi iniţierii plăţilor în numele PSU, în baza consimţământului expres al PSU.

18. API trebuie să fie conforme cu Anexa nr.1 la prezentele Cerinţe, care este elaborată în baza standardului Berlin Group şi care a fost adaptată la cadrul normativ şi operaţional aplicabil în Republica Moldova.

19. Detaliile privind metodele API care trebuie expuse de către ASPSP, structura datelor şi parametrii necesari pentru integrare sunt prevăzute în Anexa nr.1 la prezentele Cerinţe, tipurile de răspuns şi codurile de eroare standardizate sunt prevăzute în Anexa nr.2 la prezentele Cerinţe, iar mecanismul de verificare de către ASPSP a apelurilor transmise de TPP este prevăzut în Anexa nr.3 la prezentele Cerinţe.

Secţiunea 4

Lista metodelor obligatorii

20. Metodele ce urmează a fi elaborate de ASPSP pentru oferirea consimţămintelor sunt prevăzute în tabelul nr.5.

Tabelul nr.5

21. Metodele ce urmează a fi elaborate de ASPSP pentru AIS sunt prevăzute în tabelul nr.6.

Tabelul nr.6

22. Metodele ce urmează a fi elaborate de ASPSP pentru PIS sunt prevăzute în tabelul nr.7.

Tabelul nr.7

Capitolul IV

LISTA DIGITALĂ OPEN BANKING

23. Pentru implementarea Open Banking, BNM a dezvoltat şi gestionează Lista digitală Open Banking - o platformă digitală interoperabilă, accesibilă prin API, care asigură evidenţa şi gestionarea participanţilor din ecosistemul Open Banking.

24. Lista digitală Open Banking este destinată atât pentru ASPSP cât şi pentru TPP, API-ul oferă date despre fiecare participant, contribuind la transparenţa şi securitatea sistemului.

25. Prestatorii de servicii de plată implicaţi în Open Banking beneficiază de informaţiile relevante, în funcţie de rolul lor, după cum urmează:

25.1. ASPSP primesc lista TPP licenţiaţi şi înregistraţi de BNM. Această listă include detalii precum numărul licenţei, numărul de serie al certificatului (în format hexadecimal) cheii publice utilizat de TPP şi alte informaţii necesare pentru validarea accesului acestora.

25.2. TPP primesc lista ASPSP integraţi în ecosistemul Open Banking, împreună cu detaliile privind endpointurile API disponibile pentru accesarea datelor.

26. Pentru asigurarea respectării cerinţei prevăzute la pct.7, ASPSP poate accesa Lista digitală Open Banking conform detaliilor tehnice de conectare comunicate de BNM. Pentru verificarea în timp real a informaţiei cu privire la TPP în baza Listei digitale Open Banking, ASPSP va interoga Lista digitală Open Banking cu o periodicitate cuprinsă între 1 şi 10 minute. În intervalul dintre două interogări succesive, ASPSP poate utiliza versiunea memorată (cache) a listei până la efectuarea următoarei actualizări. În cazul în care Lista Digitală Open Banking nu este disponibilă, ASPSP poate utiliza datele din ultima versiune memorată.

27. ASPSP trebuie să monitorizeze în mod continuu starea certificatelor cheii publice associate TPP şi să refuze accesul oricărui certificat expirat, compromis sau revocat.

28. În cazul în care, în urma verificărilor, ASPSP depistează neconcordanţe între informaţiile de care dispune privind TPP şi informaţiile prezentate în cererea TPP, se recomandă ca ASPSP să blocheze accesul şi să informeze BNM prin intermediul poştei electronice open.banking@bnm.md. În urma notificării recepţionate, BNM examinează informaţia în conformitate cu procedurile sale interne şi informează ASPSP cu privire la rezultatele examinării în termen de 5 zile lucrătoare.

29. În cazul în care un ASPSP identifică necesitatea unor funcţionalităţi suplimentare sau modificări tehnice celor existente, acesta va expedia o cerere oficială către BNM. BNM este în drept să respingă solicitările respective dacă, în urma analizei, acestea nu întrunesc (cumulativ) următoarele criterii:

29.1. solicitarea nu contravine prevederilor actelor normative;

29.2. sunt necesare şi conforme cu funcţionalităţile Open Banking.

Anexa nr.1

la Cerinţe funcţionale şi tehnice pentru

interfeţele prestatorilor de servicii de plată

care oferă servicii de administrare cont

Metodele API

care trebuie expuse de către ASPSP, structura

datelor şi parametrii necesari pentru integrare

1. Consents Endpoints

Metoda: Create Consent

Tipul metodei: POST /v1/consents

Descriere: Această metodă permite crearea unui consimţământ de acces pentru un PSU. Un consimţământ este necesar pentru a autoriza un TPP să acceseze informaţiile contului (AIS).

[TPP] Request Header Parameters:

[TPP] Request Header Sample:

Unde “signing string” este:

digest: SHA-256=VYe+GLeBVnBVH8A50NP0Cawtg1xwkfe+XufPzmVGGMA=
date: Wed, 11 Sep 2024 12:34:56 GMT
x-request-id: 123e4567-e89b-12d3-a456-426614174000
tpp-redirect-uri: https://tpp-example.md/redirect

[TPP] Request Body Sample for Consent Request on Dedicated Accounts (detailed consent – support by ASPSP is mandatory):

[TPP] Request Body Sample for Consent on Account List of Available Accounts (global consent - support by ASPSP is mandatory):

[TPP] Request Body Sample for Consent on Account List or without Indication of dedicated Accounts (bank offered consent - support by ASPSP is mandatory):

[TPP] Request Body Parameters:

[ASPSP] Response Header sample:

[ASPSP] Response Body Sample (Success - 201 Created):

[ASPSP] Response Header Parameters:

[ASPSP] Parameters of Success Response:

[ASPSP] Response Sample (Error - 400 Bad Request):

[ASPSP] Parameters of Error Response:

Metoda: Get Consent

Tipul metodei: GET /v1/consents/{consentId}

Descriere: Această metodă permite TPP să obţină informaţii detaliate despre un consimţământ creat anterior. ID-ul consimţământului (consentId) este furnizat în URL. TPP poate verifica statutul consimţământului şi detaliile asociate, cum ar fi conturile şi valabilitatea.

[TPP] Path Parameters:

[TPP] Request Header Parameters:

[TPP] Request Header Sample:

[ASPSP] Response Header sample:

[ASPSP] Response Body Sample (Success - 200 OK):

[ASPSP] Response Header Parameters:

[ASPSP] Parameters of Success Response:

[ASPSP] Response Sample (Error - 400 Bad Request):

Metoda: Delete Consent

Tipul metodei: DELETE /v1/consents/ {consentId}

Descriere: Această metodă permite TPP să revoce un consimţământ existent utilizând consentId. Odată revocat, consimţământul nu va mai permite accesul la conturile PSU. Această acţiune este necesară pentru a stopa/bloca accesul la datele conturilor sau pentru a întrerupe accesul recurent.

[TPP] Path Parameters:

[TPP] Request Header Parameters:

[TPP] Request Header Sample:

[ASPSP] Response Header sample:

[ASPSP] Response Body Sample (Success - 204 No Content):

Nu este returnată în corpul răspunsului vreo informaţie, doar statutul 204 No Content, care confirmă că revocarea a fost efectuată cu succes.

[ASPSP] Response Header Parameters:

[ASPSP] Response Sample (Error - 400 Bad Request):

Metoda: Consent status

Tipul metodei: GET /v1/consents/{consentId}/status

Descriere: Această metodă permite TPP să obţină statutul actual al unui consimţământ identificat prin consentId. Statutul consimţământului indică dacă acesta este valid, expirat, revocat, respins sau în stadiul initial - recepţionat, oferind informaţii importante despre starea consimţământului acordat.

[TPP] Path Parameters:

[TPP] Request Header Parameters:

[TPP] Request Header Sample:

[ASPSP] Response Header sample:

[ASPSP] Response Body Sample (Success - 200 OK):

[ASPSP] Response Header Parameters:

[ASPSP] Parameters of Success Response:

[ASPSP] Response Sample (Error - 400 Bad Request):

[ASPSP] Parameters of Error Response:

2. Accounts Endpoint

Metoda: Read account list

Tipul metodei: GET /v1/accounts

Descriere: Această metodă permite TPP să obţină o listă de conturi deţinute de PSU, pentru care există un consimţământ valid. Datele returnate includ informaţii esenţiale despre fiecare cont, cum ar fi IBAN-ul, valuta şi alte detalii despre cont. Această metodă este esenţială în contextul serviciilor de acces la informaţii despre cont (AIS).

[TPP] Query Parameters:

[TPP] Request Header Parameters:

[TPP] Request Header Sample:

[ASPSP] Response Header sample:

[ASPSP] Response Body Sample (Success - 200 OK):

[ASPSP] Response Body Sample withBalance (Success - 200 OK):

[ASPSP] Response Header Parameters:

[ASPSP] Parameters of Success Response:

[ASPSP] Response Sample (Error - 400 Bad Request):

[ASPSP] Parameters of Error Response:

Parametrii cashAccountType (exemple conform ISO 20022):

Metoda: Read account details

Tipul metodei: GET /v1/accounts/{account-id}

Descriere: Această metodă permite TPP să obţină detalii despre un cont specific al PSU, identificat prin accountId. Datele returnate includ informaţii esenţiale despre cont, cum ar fi IBAN-ul, valuta, şi alte detalii relevante. Această metodă este esenţială pentru furnizarea de servicii de informare despre cont (AIS).

[TPP] Path Parameters:

[TPP] Query Parameters:

[TPP] Request Header Parameters:

[TPP] Request Header Sample:

[ASPSP] Response Header sample:

[ASPSP] Response Body Sample (Success - 200 OK):

[ASPSP] Response Body Sample withBalance (Success - 200 OK):

[ASPSP] Response Header Parameters:

[ASPSP] Parameters of Success Response:

[ASPSP] Response Sample (Error - 400 Bad Request):

[ASPSP] Parameters of Error Response:

Metoda: Read Balance

Tipul metodei: GET /v1/accounts/{account-id}/balances

Descriere: Această metodă permite TPP să obţină balanţele asociate unui cont specific, identificat prin accountId. Datele returnate includ soldurile disponibile, soldurile contabile (booked) şi alte detalii legate de balanţa contului. Această metodă este esenţială pentru furnizarea de servicii de informare despre cont (AIS).

[TPP] Path Parameters:

[TPP] Request Header Parameters:

[TPP] Request Header Sample:

[ASPSP] Response Header sample:

[ASPSP] Response Body Sample (Success - 200 OK):

[ASPSP] Response Header Parameters:

[ASPSP] Parameters of Success Response:

[ASPSP] Response Sample (Error - 400 Bad Request):

[ASPSP] Parameters of Error Response:

Metoda Read transaction list of an account

Tipul metodei: GET /v1/accounts/ {account-id}/transactions

Descriere: Această metodă permite TPP-ului să obţină o listă de tranzacţii asociate unui cont specific, identificat prin accountId. Tranzacţiile returnate includ atât tranzacţiile înregistrate (booked) cât şi tranzacţiile în aşteptare (pending). Această metodă este esenţială pentru furnizarea de servicii de informare despre cont (AIS).

Pentru determinarea tipului de plată, dacă o plată este de intrare (încasare) sau de ieşire (plată efectuată), se bazează pe informaţia de mai jos:

• Prezenţa câmpului creditorAccount → plată de ieşire (banii pleacă către creditor) → plată de Debit

• Prezenţa câmpului debtorAccount → plată de intrare (banii vin de la debitor) → plată de Credit

[TPP] Path Parameters:

[TPP] Query Parameters:

[TPP] Request Header Parameters:

[TPP] Request Header Sample:

[ASPSP] Response Header sample:

[ASPSP] Response Body Sample (Success - 200 OK):

[ASPSP] Response Body Sample withBalance (Success - 200 OK):

[ASPSP] Response Header Parameters:

[ASPSP] Parameters of Success Response:

[ASPSP] Response Sample (Error - 400 Bad Request):

[ASPSP] Parameters of Error Response:

3. Payments Endpoint

Metoda: Payment initiation

Tipul metodei: POST /v1/{payment-service}/{payment-product}

Descriere: Această metodă iniţiază o plată în funcţie de tipul de produs ales, care include la moment plăţi domestice şi instante, definite de schema naţională din Republica Moldova. Fiecare tip de plată este specificat prin {payment-product}.

[TPP] Path Parameters:

[TPP] Request Header Parameters:

Exemplu de iniţiere de plată prin produsul: domestic-credit-transfers-md

[TPP] Request Header Sample:

[TPP] Request body Sample:

[TPP] Parameters of body request:

Exemplu de iniţiere de plată prin produsul: instant-credit-transfers-md

[TPP] Request Header Sample:

[TPP] Request body Sample:

[TPP] Parameters of body request:

[ASPSP] Response Header sample:

[ASPSP] Response Sample (201 Created):

[ASPSP] Parameters of Success Response:

[ASPSP] Response Sample (Error or Warning):

[ASPSP] Parameters of Error Response:

Metoda: Get payment information

Tipul metodei: GET /v1/{payment-service}/{payment-product}/{paymentId}

Descriere: Această metodă permite vizualizarea detaliilor despre o plată iniţiată folosind identificatorul unic al plăţii ({paymentId}) pentru tipul de plată specificat ({payment-product}).

[TPP] Path Parameters:

[TPP] Request Header Parameters:

[TPP] Request Sample:

[ASPSP] Response Sample (200 OK) (domestic-credit-transfers-md):

[ASPSP] Parameters of Success Response (domestic-credit-transfers-md):

[ASPSP] Response Sample for instant-credit-transfers-md (200 OK):

[ASPSP] Parameters of Success Response (domestic-credit-transfers-md):

[ASPSP] Response Sample (Error or Warning):

[ASPSP] Parameters of Error Response:

Metoda: Get payment status

Tipul metodei: GET /v1/{payment-service}/{payment-prodyuct}/{paymentId}/status

Descriere: Această metodă returnează statutul actual al unei plăţi iniţiate, identificată prin {paymentId}, pentru tipul de produs de plată specificat ({payment-product}).

[TPP] Path Parameters:

[TPP] Request Header Parameters:

[TPP] Request Header Sample:

[ASPSP] Response Header sample:

[ASPSP] Response Body Sample (200 OK):

[ASPSP] Response Header Parameters:

[ASPSP] Parameters of Success Response:

[ASPSP] Response Sample (Error or Warning):

[ASPSP] Parameters of Error Response:

Anexa nr.2

la Cerinţe funcţionale şi tehnice pentru

interfeţele prestatorilor de servicii de plată

care oferă servicii de administrare cont

Tipurile de răspuns şi codurile de eroare standardizate

1. Consent Status

2. Account Access

3. Account Reference

4. Account Details

5. Links

6. SCA Status

7. Transaction Status

8. Balance Type

9. HTTP Response

10. HTTP Error Codes

Anexa nr.3

la Cerinţe funcţionale şi tehnice pentru

interfeţele prestatorilor de servicii de plată

care oferă servicii de administrare cont

Mecanismul de verificare de către ASPSP a apelurilor transmise de TPP

1. Generarea cererii de către TPP

Pasul 1. Calcularea hash-ului pentru câmpul Digest

1.1. TPP-ul creează corpul cererii (de exemplu, JSON-ul cu datele tranzacţiei sau consimţământului).

1.2. TPP-ul aplică algoritmul SHA-256 asupra corpului cererii pentru a genera un hash unic.

1.3. Hash-ul rezultat este codificat în format Base64 şi plasat în header-ul cererii Digest.

Pasul 2. Crearea stringului de semnare (signing string)

2.1. TPP pregăteşte un string de semnare (signing string) pe baza unor câmpuri specifice din header-ul cererii.

2.2. Stringul de semnare se obţine prin concatenarea valorilor header-ilor semnate, în format specific.

2.3. Ordinea valorilor header-ilor este importantă şi este conformă specificaţiilor.

Pasul 3. Semnarea stringului de semnare

3.1. TPP foloseşte cheia privată RSA asociată certificatului său pentru a genera semnătura electronică.

3.2. Semnătura este aplicată pe stringul de semnare folosind algoritmul RSA-SHA256.

3.3. Semnătura electronică rezultată este codificată în Base64 şi plasată în header-ul Signature.

Pasul 4. Adăugarea certificatului în header-ul TPP-Signature-Certificate

4.1. TPP-ul include certificatul său public în header-ul cererii TPP-Signature-Certificate.

4.2. Certificatul este emis de o autoritate de certificare (CA) de încredere şi conţine cheia publică a TPP-ului.

Pasul 5. Trimiterea cererii către ASPSP

5.1. TPP-ul trimite cererea completă, inclusiv header-urile Digest, Signature şi TPP-Signature-Certificate, către endpoint-ul ASPSP.

2. Verificarea cererii de către ASPSP

Pasul 1. Validarea certificatului TPP

1.1. ASPSP verifică certificatul TPP-ului inclus în TPP-Signature-Certificate.

Etape:

1.1.1. Verificarea lanţului de încredere al certificatului până la o autoritate de certificare de încredere.

1.1.2. Verificarea că certificatul este valid (neexpirat şi nerevocat).

1.1.3. ASPSP trebuie să verifice că certificatul prezentat de TPP este emis şi valid pentru utilizarea în cadrul serviciilor Open Banking, având scopul de semnare electronică şi autentificare, şi că acesta corespunde exact TPP-ului înregistrat sau licenţiat de BNM (prin interogarea Listei digitale Open Banking a BNM în cazul utilizării acesteia de ASPSP pentru verificare TPP), prin validarea numărului de serie al certificatului şi a autorităţii emitente (CA nivel 2 sau root CA), precum şi a câmpului Signature.

Rezultat: Dacă certificatul este valid, identitatea TPP-ului este confirmată.

Pasul 2. Verificarea hash-ului din Digest

2.1. ASPSP calculează propriul hash SHA-256 asupra corpului cererii primit.

2.2. Hash-ul calculat este comparat cu valoarea din header-ul Digest.

Rezultat: Dacă cele două hash-uri sunt identice, integritatea corpului cererii este confirmată.

Pasul 3. Verificarea semnăturii din Signature

3.1. ASPSP-ul extrage valorile header-ilor incluse în "signing string" pe baza informaţiilor din Signature.

3.2. ASPSP recreează stringul de semnare conform aceluiaşi format folosit de TPP.

3.3. ASPSP foloseşte publică extrasă din certificatul aflat în header TPP-Signature-Certificate pentru a verifica semnătura din Signature.

Rezultat: Dacă semnătura este validă, autenticitatea cererii este confirmată.

Pasul 4. Autorizarea cererii

4.1. Dacă toate verificările sunt trecute (rolul, integritatea, semnătura şi certificatul), ASPSP procesează cererea.

4.2. În caz contrar, cererea este respinsă cu un mesaj de eroare (de exemplu, 401 Unauthorized sau 403 Forbidden).

3. Detalii adiţionale.

Cum verifică ASPSP semnătura din Signature?

1. Extrage cheia publică din certificatul TPP-Signature-Certificate:

1.1. ASPSP preia certificatul (TPP-Signature-Certificate) din header-ul (TPP-Signature-Certificate) cererii.

1.2. Din acest certificat, ASPSP extrage cheia publică a TPP-ului.

2. Recreează signing string:

2.1. ASPSP analizează header-ul Signature pentru a identifica câmpurile semnate (ex.: Digest, X-Request-ID, Date, etc.).

2.2. ASPSP recreează signing string din valorile efective ale acestor headere, în ordinea specificată.

3. Decodifică semnătura:

3.1. ASPSP decodifică valoarea din câmpul signature al antetului HTTP Signature (adică Signature.signature), care reprezintă semnătura electronică generată de TPP.Decodarea se face utilizând cheia publică extrasă din certificatul TPP-Signature-Certificate şi algoritmul specificat în Signature.algorithm (ex.: RSA-SHA256).

4. Compară hash-ul rezultat:

4.1. În timpul decodificării, ASPSP obţine un hash calculat de TPP în momentul semnării.

4.2. ASPSP compară acest hash cu hash-ul generat intern din stringul de semnare recreat.

5. Rezultate posibile:

5.1. Dacă hash-urile coincid, semnătura este validă.

5.2. Dacă hash-urile nu coincid, semnătura este invalidă, iar cererea este respinsă.