Băncile captive în sisteme informatice vechi: de ce modernizarea infrastructurii poate fi mai riscantă decât amânarea?

În centrul multor bănci europene funcționează încă sisteme concepute cu zeci de ani în urmă. Ele țin evidența conturilor, calculează dobânzi, procesează plăți și alimentează aplicațiile moderne pe care clienții le văd pe telefon. Unele rulează pe mainframe, folosesc limbaje pe care tot mai puțini specialiști le cunosc și au acumulat mii de modificări. Cu toate acestea, procesează volume uriașe cu o stabilitate pe care multe platforme mai noi nu au demonstrat-o încă.

De aici apare paradoxul. Amânarea modernizării păstrează vulnerabilități, costuri și dependențe care cresc anual. Dar o înlocuire amplă poate concentra într-un singur proiect riscuri pe care banca le-a absorbit treptat în decenii. Migrarea greșită a datelor, o regulă de calcul omisă sau o comutare eșuată poate afecta milioane de conturi în câteva ore. Pentru conducere, un sistem vechi care funcționează astăzi pare uneori mai sigur decât unul nou care promite eficiență mâine.

Sistemul vechi este și arhiva nevăzută a băncii

Un „core banking” nu este doar o bază de date și câteva programe. În el sunt sedimentate produse retrase de mult din ofertă, excepții acordate anumitor clienți, reguli fiscale, convenții de rotunjire, calendare, procese de închidere a zilei și legături cu sute de aplicații. O parte din această logică este documentată; o parte există doar în cod, în proceduri locale sau în memoria oamenilor care au întreținut sistemul.

Înlocuirea devine riscantă atunci când proiectul presupune că platforma nouă trebuie doar să copieze funcțiile celei vechi. În realitate, banca trebuie mai întâi să descopere ce face sistemul. Un câmp aparent inutil poate alimenta raportarea de reglementare. O prelucrare nocturnă poate repara automat diferențe produse în timpul zilei. O interfață rar folosită poate deveni critică la sfârșit de lună. Dacă aceste dependențe sunt observate după migrare, problema nu mai este una de proiect, ci una operațională.

Vezi și:

Întrebarea la care să nu răspunzi în grabă când ești oprit de Poliție în trafic. Ce recomandă un avocat șoferilor

Datele ridică o dificultate separată. În decenii de utilizare apar formate diferite, valori lipsă, duplicate și convenții schimbate. Mutarea lor nu înseamnă copiere, ci interpretare. Soldul total trebuie să coincidă, dar și istoricul tranzacțiilor, dobânzile acumulate, garanțiile și relațiile dintre produse. O migrare poate trece testul tehnic și totuși să creeze erori financiare mici, răspândite în milioane de înregistrări.

Reglementarea amplifică miza. Datele din nucleul bancar alimentează raportări prudențiale, prevenirea spălării banilor, protecția consumatorului și calculul capitalului. O transformare aparent tehnică poate schimba sensul unui atribut folosit de mai multe controale. De aceea, validarea nu poate fi delegată doar echipei IT: finanțele, riscul, conformitatea și proprietarii produselor trebuie să confirme rezultatele pe seturi complete, nu doar pe câteva exemple curate.

Mai există și riscul competențelor. Specialiștii în platforma veche se apropie adesea de pensionare, iar cei noi preferă tehnologii actuale. Banca devine dependentă de un grup restrâns de angajați sau furnizori. Totuși, aceeași oameni sunt indispensabili modernizării, pentru că ei pot explica excepțiile pe care documentația nu le surprinde. Dacă proiectul începe prea târziu, transferul de cunoștințe se transformă într-o cursă contra cronometru.

Vezi și:

RoPay la casa de marcat: poate plata direct din cont să devină alternativa românească la Visa și Mastercard?

Schimbarea poate provoca exact întreruperea pe care vrea să o prevină

Banca Centrală Europeană a inclus managementul schimbărilor informatice între temele de supraveghere pentru 2026-2028 și observă că modificările sistemelor se află frecvent la originea întreruperilor neplanificate. Constatarea explică de ce modernizarea trebuie tratată ca risc operațional, nu doar ca investiție tehnologică. Cu cât proiectul atinge mai multe servicii simultan, cu atât crește numărul combinațiilor care trebuie testate.

O înlocuire de tip „big bang” mută într-un weekend conturile, interfețele și procesele pe noua platformă. Avantajul este că perioada de dublă operare rămâne scurtă. Dezavantajul este concentrarea riscului. Dacă apar probleme după comutare, revenirea la vechiul sistem poate fi dificilă: în noua platformă s-au înregistrat deja tranzacții, iar cele două evidențe trebuie reconciliate. O revenire improvizată riscă să dubleze sau să piardă operațiuni.

Funcționarea în paralel reduce riscul comutării, dar adaugă alte costuri și vulnerabilități. Banca întreține două platforme, sincronizează datele și cere angajaților să lucreze cu proceduri duble. Perioada de tranziție se poate prelungi, iar arhitectura temporară devine permanentă. În plus, testele nu pot reproduce complet zilele cu volume excepționale, incidente simultane sau comportamentul real al clienților.

Un material al Rezervei Federale din Kansas City enumeră exact aceste riscuri: indisponibilitate, probleme de migrare a datelor, fiabilitatea platformei noi și lipsa resurselor necesare. Ele nu demonstrează că înlocuirea este o greșeală, ci că beneficiul pe termen lung trebuie câștigat printr-o tranziție atent controlată. Tehnologia nouă nu este automat rezilientă doar pentru că este nouă.

Și furnizorul poate schimba profilul de risc. O platformă standardizată reduce codul întreținut intern și poate accelera lansarea produselor, dar introduce dependența de calendarul, competențele și sănătatea financiară a companiei care o livrează. Soluția cloud poate oferi capacitate și redundanță, însă cere control asupra configurației, identităților, datelor și planului de ieșire. Modernizarea mută riscul; rareori îl elimină.

Contractul trebuie să acopere și finalul relației, nu doar implementarea. Banca are nevoie de acces la date într-un format portabil, sprijin pentru tranziție, drepturi clare asupra modificărilor și termene realiste de remediere. Fără aceste clauze, platforma modernă poate deveni următorul sistem captiv. Tehnologia se schimbă, dar dependența rămâne și va fi descoperită abia la o renegociere, un incident sau o nouă migrare.

Amânarea cumpără liniște astăzi și fragilitate mâine

Faptul că migrarea este periculoasă nu face sistemul vechi sigur. Costul amânării apare în incidente mai frecvente, integrare lentă și schimbări tot mai greu de testat. Fiecare produs nou construit peste nucleul vechi adaugă adaptoare, copii de date și procese manuale. Arhitectura devine atât de interconectată încât nimeni nu mai poate anticipa toate efectele unei modificări.

Raportul de risc al Autorității Bancare Europene din iunie 2026 arată că defecțiunile sistemelor rămân dominante între incidentele informatice majore și că pierderile asociate noilor evenimente IT au crescut în 2025. Nu toate aceste incidente provin din tehnologie veche, dar datele contrazic ideea că menținerea situației existente este lipsită de cost. Un sistem stabil poate deveni vulnerabil prin lipsa pieselor, a suportului sau a oamenilor, chiar dacă software-ul nu se schimbă.

Amânarea limitează și libertatea comercială. O bancă poate avea o aplicație elegantă, dar dacă deschiderea unui produs necesită prelucrări nocturne și intervenții manuale, experiența digitală rămâne o fațadă. Datele fragmentate îngreunează detectarea fraudei și evaluarea riscului, iar modificările cerute de reglementare devin mai scumpe. Instituția plătește o taxă de complexitate la fiecare lansare.

Această taxă afectează și securitatea. Un sistem vechi poate fi bine protejat în interiorul unei rețele, însă adaptoarele construite pentru aplicații web, parteneri și acces mobil creează tot mai multe puncte de intrare. Patch-urile devin dificil de aplicat când o versiune nouă poate rupe o interfață critică. Echipele ajung să compenseze tehnologia rigidă prin controale manuale, iar numărul excepțiilor face mediul mai greu de înțeles tocmai când apare un atac.

Mai grav, riscul se acumulează până când modernizarea nu mai este o alegere planificată. Un furnizor retrage suportul, o platformă nu mai poate satisface cerințele de securitate sau o fuziune impune consolidarea rapidă. Banca este obligată atunci să transforme sub presiune, exact când are mai puțin timp pentru inventariere și testare. Amânarea poate fi justificată un an, dar devine periculoasă atunci când nu cumpără pregătire, ci doar întârzie decizia.

Modernizarea sigură începe cu reducerea mizei fiecărui pas

Între înghețarea sistemului vechi și înlocuirea totală există o strategie graduală. Banca poate separa domenii, expune funcțiile prin interfețe controlate și muta produse sau grupuri de clienți în etape. O abordare de tip „strangler” construiește treptat noua arhitectură în jurul nucleului existent și retrage componentele numai după ce traficul și datele au fost mutate în siguranță. Nu este spectaculoasă, dar face erorile mai mici și mai ușor de reparat.

Prioritatea trebuie stabilită după risc și valoare, nu după vârsta tehnologiei. Unele componente vechi sunt stabile, bine izolate și merită păstrate temporar. Altele blochează schimbarea, nu mai au suport sau concentrează date critice și trebuie abordate primele. Inventarul dependențelor, indicatorii de sănătate și incidentele reale oferă o ordine mai bună decât dorința de a înlocui tot ce pare depășit.

Fiecare etapă are nevoie de criterii verificabile: reconcilierea completă a datelor, volume testate peste vârful istoric, capacitate de revenire, separarea responsabilităților și limite clare pentru perioada de operare paralelă. Echipele de afaceri trebuie să dețină regulile produselor, iar specialiștii sistemului vechi trebuie implicați înainte ca informația lor să se piardă. Repetițiile comutării și ale revenirii sunt la fel de importante ca testele funcționale.

Guvernanța financiară trebuie să susțină aceeași logică. Programele multianuale eșuează când bugetul este aprobat pentru lansarea vizibilă, dar nu și pentru curățarea datelor, dezafectarea aplicațiilor sau perioada de stabilizare. Economiile apar numai după oprirea componentelor vechi. Dacă banca păstrează toate sistemele „pentru siguranță”, ajunge să plătească simultan datoria tehnică și transformarea, fără să obțină simplitatea promisă.

Modernizarea poate fi mai riscantă decât amânarea într-un interval scurt, mai ales dacă banca concentrează totul într-o singură lansare. Pe termen lung, comparația se inversează: datoria tehnică, lipsa competențelor și dependențele nevăzute cresc probabilitatea unui incident și reduc opțiunile. Decizia matură nu este să alegi între curaj și prudență, ci să transformi în pași suficient de mici încât eșecul unuia să nu devină criză bancară.

Succesul se vede când banca poate schimba mai repede un produs, poate explica traseul datelor și poate opri, în sfârșit, componentele retrase. Fără aceste rezultate, proiectul a mutat complexitatea într-o platformă nouă.

Cinci lucruri pe care să nu le faci niciodată în aeroport. Obiceiurile pasagerilor care îi enervează pe piloți și însoțitorii de bord