Cât de aproape suntem de un agent AI care îți administrează banii fără să te mai întrebe de fiecare dată? Tudor Stanciu, de la Ventures’n’Law, explică de ce reglementarea europeană a plăților nu lasă loc, deocamdată, unui mandat unic dat unui algoritm — și ce înseamnă asta pentru bănci și fintech-uri.
Într-un interviu acordat banko.ro, avocatul discută patru fronturi regulatorii care se închid simultan asupra industriei: autentificarea puternică a clientului (SCA) versus finanțele autonome, obligațiile de reziliență digitală (DORA) pe care băncile le transferă furnizorilor tech, protecția reală a banilor clienților ținuți în conturi collector la EMI-uri și neobănci, și noul regim de răspundere pentru produse defecte, care pentru prima dată include explicit software-ul și sistemele AI. Concluzia lui Stanciu: conformitatea nu mai e doar o listă de bifat, ci un avantaj competitiv — sau, netratată corect, un risc contractual major.
Banko.ro: Analizele recente publicate pe banko.ro indică un interes major pentru trecerea de la Open Banking la finanțele autonome (autonomous finance). Din perspectiva dumneavoastră, care sunt principalele bariere de reglementare din spațiul est-european care împiedică implementarea unor algoritmi de inteligență artificială capabili să execute tranzacții financiare autonome în numele utilizatorilor, fără aprobare manuală pentru fiecare operațiune?
T.S.: Dacă ne uităm la cea mai recentă versiune draft a regulamentului privind serviciile de plăți (care va înlocui PSD2 pentru anumite aspecte comune serviciilor de plăți care necesită uniformizare la nivelul statelor membre), regula de strong customer authentication (SCA) nu are o exceptare explicită sau implică care să permit unui agent AI să acționeze în baza unui mandat unic din partea plătitorului – posibil cu excepția anumitor operațiuni de transfer credit, însă și acolo există parametri prestabiliți care trebuie luați în calcul. PSR nu creează o exceptare tip „blanket” pentru clienți corporate sau pentru fluxuri delegate. Chiar dacă sunt preconizate în continuare excepții permise de la regula SCA pentru tranzacții de risc scăzut, cu valoare redusă, recurente sau transferuri intra-cont, este important de observat care poate fi considerat elementul de inițiere a plății, din perspectiva activităților ce pot fi realizate de către plătitor.
Banko.ro: Ventures’n’Law a fost implicat activ în evenimentele Cybersecurity Week 2026. Odată cu implementarea strictă a Regulamentului DORA (Digital Operational Resilience Act) în sistemul bancar european, băncile sunt obligate să auditeze riguros reziliența digitală a tuturor furnizorilor lor de tehnologie, inclusiv a startup-urilor fintech partenere. Cum sprijină Ventures’n’Law acești furnizori de tehnologie în redactarea acordurilor privind nivelul serviciilor (SLA) și a clauzelor de răspundere pentru a nu fi excluși din lanțul de aprovizionare al marilor instituții financiare?
T.S.: Aș vrea să setez mai întâi cadrul întrebării: DORA nu se limitează la furnizorii desemnați drept critici, ci obligă entitățile financiare să introducă în contractele cu furnizorii de tehnologie un set specific de clauze precum drepturi de audit, niveluri de prestare a mentenanței, cooperare în caz de incidente, sau claritate privind locația de unde se prestează efectiv serviciile.
Dacă descoperi relevanța acestor clauze abia la primul draft primit de la un potențial client, vei acționa defensiv și doar dorind să bifezi niște cerințe, fără să înțelegi impactul lor. Exact aici intervine rolul Ventures’n’Law, în a explica clienților noștri cum pot construi conformitatea într-un avantaj comercial pe care îl pot utiliza în procesul de vânzare.
Un aspect pe care încercăm să-l explicăm clienților este cum să trateze obligațiile pe care le au, ca furnizori de tehnologie, în contextul DORA. Există un nivel de bază – clauze standard, obligatorii – și un nivel consolidat – pentru funcții și situații critice. Ca fondator sau manager de departament, poți să acționezi prin subdimensionare: crezi că vei scăpa cu clauze minimale, deși susții o funcție critică pentru o bancă, de exemplu. Dar poți merge și în extrema cealaltă, acționând prin supra-reglementare contractuală: accepți obligații excesive pentru servicii care nu prezintă un impact semnificativ pentru clientul tău, doar pentru că nu înțelegi ce îți asumi cu adevărat.
Banko.ro: Ca parte a adopției unei soluții dezvoltate de către un fintech, trebuie să discutăm despre siguranța utilizării – și specific despre siguranța fondurilor. Cum ar trebui să gestioneze un fintech care gestionează și fondurile clienților această problemă?
T.S.: Trebuie mai întâi să înțelegem mecanismul de bază: când o instituție de plată sau o instituție de monedă electronică – de exemplu, multe neobănci sau portofele digitale – deține banii tăi, aceștia nu stau într-un cont de depozit normal. Stau într-un cont collector segregat la o bancă parteneră, ținut în numele și pe seama primei instituții, pentru utilizatorii săi. Însă, dacă banca intră în faliment sau devine incapabilă să plătească fondurile asociate acelor conturi, acele conturi nu erau automat protejate. Cea mai recentă Directivă UE privind garantarea depozitelor extinde protecția depozitelor pentru a acoperi acest scenariu, în limita a 100.000 euro per client pentru care s-au îndeplinit procedurile de KYC, și doar dacă fintech-ul a ținut evidențe suficient de clare pentru ca banca să identifice ce sumă din contul colector aparține fiecărui utilizator.
Banko.ro: În alte intervenții, ați abordat nuanțat problema răspunderii civile și tehnice în situațiile în care sisteme hardware, module software sau algoritmi de Inteligență Artificială cauzează un prejudiciu material sau financiar. Având în vedere aplicarea progresivă a cerințelor din Regulamentul privind Inteligența Artificială (EU AI Act) și tendința băncilor de a integra algoritmi financiari autonomi în gestionarea tranzacțiilor, cum modifică aceste noi reguli de răspundere strictă profilul de risc al companiilor tech?
T.S.: E util să ținem cont de 2 arhitecturi. În momentul de față, anterior lui 9 decembrie 2026 – termenul de transpunere a directivei 2024/2853 privind răspunderea pentru produse defecte în legislația locală -, prevederile legale actuale nu sunt deocamdată suficiente cât să surprindă o nuanță importantă, anume răspunderea în contextul învățarii continue a sistemelor de AI. În era AI, software-ul nu mai este static și creează efecte variabile în funcție de procesul de învățare automată, antrenare ori calibrare. Noua Directivă vine la pachet, printre altele, cu măsuri procedurale pentru ușurarea sarcinii probei victimei care a suferit un prejudiciu, dar și cu faptul că victima nu trebuie să dovedească culpa producătorului, ci doar că produsul era defect și a cauzat prejudiciul.
Ce aduce în plus, pe zona de inteligență artificială, este includerea explicită a software-ului și a sistemelor bazate pe aceasta în categoria produselor pentru care poate fi angajată răspunderea. Este o schimbare față de abordarea anterioară, în care software-ul era adesea dificil de încadrat în termeni de răspundere, atunci când el era integrat într-un produs considerat defect.
Ce decurge de aici este o responsabilitate contractuală care trebuie împărțită între clientul final – în cazul expus în întrebare, banca – și furnizorul soluției software utilizate, care la rândul său poate fi un grup de companii, organizate pe un lanț decizional de integrare, până la furnizorul modelului de inteligență artificială integrat în produs. O problemă potențială pe care o anticipăm este nevoia furnizorului de software de a putea explica băncii cum funcționează produsul furnizat, și care sunt zonele în care furnizorul nu-și poate asuma o răspundere (și de ce). Va fi o curbă de învățare pentru ambele părți, iar de modul în care înțeleg ele să-și asume această învățare va depinde și arhitectura contractuală a relației lor.
Primul interviu cu Tudor poate fi citit aici.
