Wprowadzenie nowego produktu kredytowego lub aktualizacja modelu oceny zdolności kredytowej stają się dziś jednym z czynników, które realnie różnicują banki na rynku. Nie chodzi już tylko o samą ofertę, cenę czy trafność scoringu. Chodzi o to, jak szybko bank reaguje: na ruch konkurencji, nowy segment klientów, sygnał ryzyka albo wymóg regulatora.
W wielu bankach komercyjnych w Polsce to tempo wciąż zależy od czegoś, na co ani osoba zarządzająca obszarem kredytowym, ani osoba odpowiedzialna za modele ryzyka nie ma pełnego wpływu. Chodzi o kolejkę i harmonogram prac zespołu IT. Każda zmiana w produkcie kredytowym i każda modyfikacja modelu scoringowego trafiają do tej samej kolejki co projekty regulacyjne i poprawki bezpieczeństwa. Efekt bywa taki, że wdrożenie, które mogłoby zająć tygodnie, rozciąga się na miesiące.
Skala problemu jest większa, niż pokazują wewnętrzne raporty
Warto zacząć od liczby, która dobrze tłumaczy, skąd bierze się ten problem. Według raportu Accenture „Top Banking Trends for 2026”, banki przeznaczają dziś około 70 procent budżetów IT na utrzymanie istniejących systemów oraz spełnianie wymogów regulacyjnych. Na rozwój i nowe produkty kredytowe, czyli na to, co realnie generuje przychód, zostaje ułamek środków i czasu zespołu IT.
Podobny obraz wyłania się z danych McKinsey dotyczących planowania budżetów technologicznych na lata 2025 i 2026. Znacząca część dyrektorów IT w bankach przyznaje, że dług technologiczny pochłania ponad jedną piątą budżetu przeznaczonego na nowe produkty. Ten udział rośnie z każdym rokiem, w którym problem zostaje odłożony.
Dla obszaru ryzyka kredytowego skala problemu jest dobrze zmapowana w badaniu EY „Banki wobec ryzyka kredytowego i przestępczości finansowej” (2026). Ryzyko kredytowe wskazuje jako największy problem w działalności banku 62 procent respondentów, a 55 procent dyrektorów ds. ryzyka deklaruje, że zaawansowane technologie, w tym AI, są dla nich dziś priorytetem. Sztuczna inteligencja jest już wykorzystywana do modelowania ryzyka kredytowego przez 33 procent badanych instytucji, ale blisko trzy czwarte respondentów przyznaje, że to wykorzystanie znajduje się nadal na wczesnym etapie wdrażania. Główną barierą, wskazywaną przez 80 procent badanych, nie jest brak chęci ani strategii. Jest nią jakość i dostępność danych w systemach, na których pracuje model.
To nie jest kwestia słabej organizacji pracy jednego działu IT. To cecha architektury systemów, w której każda zmiana, regulacyjna, produktowa czy modelowa, musi przejść przez ten sam wąski punkt: zespół programistów pracujących na systemie, który nie był projektowany pod częste i szybkie modyfikacje.
Skąd bierze się to opóźnienie
Odpowiedź zaczyna się od tego, jak zbudowane są systemy, na których pracuje większość dużych banków komercyjnych w Polsce. To architektury tworzone wiele lat temu, w czasach, gdy zmiana produktowa, regulacyjna albo modelowa zdarzała się raz na kilka lat. Dziś zdarza się właściwie bez przerwy, bo regulacje takie jak DORA i AI Act nakładają się na siebie i wymagają stałej zdolności systemu do adaptacji, a nie jednorazowego dostosowania.
Dobrze pokazuje to raport Programu Analityczno-Badawczego WIB, poświęcony wdrażaniu rozporządzenia DORA przez banki komercyjne w Polsce (marzec 2026). Autorzy raportu, prof. Krzysztof Waliszewski, dr Michał Nowakowski i dr Marcin Idzik, wskazują, że największym wyzwaniem wdrożeniowym nie jest znajomość przepisów. Jest nim konieczność integracji nowych wymogów z systemami zarządzania ryzykiem ICT, które już działają w banku. To nie jest dopisanie nowego obowiązku. To przebudowa fundamentów.
Do tego dochodzi nowa warstwa presji regulacyjnej, która dotyczy bezpośrednio modeli oceny zdolności kredytowej. Systemy AI wykorzystywane do scoringu kredytowego zostały w unijnym AI Act zaklasyfikowane jako rozwiązania wysokiego ryzyka, co oznacza obowiązki w zakresie dokumentacji, wyjaśnialności decyzji, monitoringu odchyleń i nadzoru nad danymi uczącymi model. Dla osoby odpowiedzialnej za modele ryzyka to konkretna konsekwencja: każda zmiana w metodyce scoringu przestaje być wyłącznie decyzją analityczną, staje się też projektem zgodności, który znów czeka w tej samej kolejce IT.
Dla osoby zarządzającej obszarem kredytowym oznacza to inną, równie konkretną konsekwencję. Każda zmiana regulacyjna KNF, EBA czy unijna staje się osobnym, wielomiesięcznym projektem IT. Wprowadzenie nowego produktu kredytowego czeka w tej samej kolejce co projekty regulacyjne i zwykle przegrywa, bo regulacja ma twardy termin, a produkt może poczekać.
Koszt, którego nie widać w arkuszu kalkulacyjnym
Koszty tego opóźnienia są realne i dotyczą kilku obszarów naraz.
Pierwszy to utracony przychód. Każdy miesiąc opóźnienia we wprowadzeniu nowego produktu kredytowego oznacza miesiąc, w którym klienci trafiają do konkurencji z gotową ofertą. Dane BIK z 2026 roku pokazują rekordową sprzedaż kredytów hipotecznych i rosnącą akcję kredytową w segmencie gotówkowym. Przy takim ożywieniu rynku koszt opóźnienia rośnie razem z jego wielkością.
Drugi to koszt gorszego ryzyka. Model scoringowy, którego aktualizacja trwa miesiącami, ocenia klientów na podstawie danych i zależności, które są coraz bardziej nieaktualne. W czasie, gdy 33% banków już wykorzystuje AI do modelowania ryzyka kredytowego, bank z zamrożonym, trudnym do zmiany modelem traci przewagę w trafności decyzji, a nie tylko w tempie.
Trzeci to ryzyko regulacyjne. Gdy system nie nadąża za wymogami KNF, DORA czy AI Act, efektem bywa audyt wskazujący niezgodności. Ich źródłem nie jest brak wiedzy czy dobrej woli, tylko ograniczenia samego systemu IT i brak jego audytowalności.
Czwarty koszt jest bardziej organizacyjny. Pełne uzależnienie od działu IT przy każdej zmianie procesu kredytowego lub modelu ryzyka to jeden z najczęściej wskazywanych problemów osób zarządzających obszarem kredytowym i obszarem ryzyka w dużych bankach. Ogranicza to zdolność szybkiego reagowania na zmiany rynkowe, niezależnie od tego, jak dobra jest sama koncepcja produktu albo jak trafny jest sam model.
Dlaczego kolejny projekt IT nie jest odpowiedzią
Naturalną reakcją na ten problem bywa kolejny duży projekt modernizacyjny: wymiana systemu, wielomiesięczne wdrożenie, obietnica, że tym razem będzie inaczej. Taki projekt sam w sobie trwa do kilkunastu miesięcy, obciąża budżet i niesie ryzyko. Banki, które pamiętają wdrożenia przekraczające harmonogram i budżet, słusznie podchodzą do tego ostrożnie.
Odpowiedzią, która zyskuje w polskiej bankowości realne znaczenie, jest zmiana modelu pracy nad systemem, a nie kolejna jego wymiana. Mowa o platformach low-code. Pozwalają one przenieść ciężar wprowadzania zmian, zarówno w produkcie kredytowym, jak i w regułach modelu scoringowego, z wielomiesięcznego cyklu programistycznego na konfigurację liczoną w tygodniach.
Dane potwierdzają, że to już nie eksperyment, tylko mainstream. Wartość rynku low-code w Polsce w 2026 roku szacuje się na 1,8 miliarda złotych, a korzysta z technologii low-code/ no-code już 39% polskich firm.
Co zyskuje bank, który zmienia model
Praktyczna różnica jest prosta do opisania. Zamiast zlecać każdą zmianę regulacyjną, produktową czy modelową jako osobny projekt programistyczny, zespół biznesowy konfiguruje ją bezpośrednio w systemie. Wspiera go w tym dostawca, który rozumie specyfikę bankową. Wprowadzenie nowego produktu kredytowego albo zmiana reguł w modelu oceny ryzyka przestają być projektem na pół roku. Stają się zadaniem na kilka tygodni.
Takie podejście wymaga czegoś więcej niż samej technologii. Wymaga zespołu, który rozumie specyfikę procesów kredytowych i modeli ryzyka na tyle dobrze, żeby projektować systemy pod realne potrzeby biznesu, a nie odwrotnie. Na tym doświadczeniu, budowanym od ponad 30 lat pracy z sektorem bankowym, opiera się podejście VSoft. Kluczowe elementy tego podejścia to:
- Platforma low-code, w której zmiany regulacyjne i modelowe można wdrażać w godzinach, a nie miesiącach.
- Domain experts w zespole wdrożeniowym, czyli ludzie, którzy rozumieją proces kredytowy i logikę modeli scoringowych, a nie tylko kod.
- Gotowy produkt branżowy, który konfiguruje się pod bank, zamiast budować od zera.
- Obsługa całego cyklu życia systemu przez jeden zespół: od koncepcji, przez wdrożenie, po utrzymanie.
Jeśli chcesz zobaczyć, jak w praktyce wygląda platforma low-code, o której mowa powyżej? Kliknij tutaj i poznaj VSoft archITekt!
Ile cykli można jeszcze przegrać
Presja regulacyjna nie zniknie. DORA, AI Act i kolejne unijne regulacje będą się nakładać, a nie zastępować, i będą dotykać zarówno samego produktu kredytowego, jak i modeli, które oceniają ryzyko związane z jego udzieleniem. Rynek kredytowy nie zwolni. Dane z 2026 roku pokazują wyraźne ożywienie akcji kredytowej w niemal każdym segmencie, a jednocześnie rosnącą presję na to, by decyzje o kredycie były szybsze i trafniejsze niż rok wcześniej.
W tych warunkach czas wdrożenia nowego produktu kredytowego i czas aktualizacji modelu oceny ryzyka przestają być wewnętrznymi wskaźnikami operacyjnymi. Stają się realną przewagą konkurencyjną banku albo, w przypadku tych, którzy zostają w tyle, realnym zagrożeniem dla ich pozycji rynkowej.
Pytanie, które warto sobie dziś zadać, nie brzmi już, czy da się to przyspieszyć. Brzmi: ile jeszcze cykli regulacyjnych, produktowych i modelowych bank może sobie pozwolić przegrać, zanim zmieni model, w którym pracuje jego system.
Źródła:
Accenture, „Top Banking Trends for 2026”; McKinsey, dane o wpływie długu technologicznego na budżety IT banków (2025–2026); EY, „Banki wobec ryzyka kredytowego i przestępczości finansowej” (2026); Program Analityczno-Badawczy WIB, „Doświadczenia z wdrażania Rozporządzenia DORA przez banki komercyjne w Polsce: dobre praktyki, wyzwania i rekomendacje” (marzec 2026); AI Act — klasyfikacja systemów scoringu kredytowego jako obszaru wysokiego ryzyka (harmonogram stosowania po porozumieniu politycznym z 7 maja 2026 r.); Biuro Informacji Kredytowej, dane o rynku kredytowym w Polsce (2026).
Jesteśmy zespołem specjalistów pracujących głównie przy projektach dla sektora finansowego. Na blogu dzielimy się wiedzą z realizowanych projektów: omawiamy technologie, analizujemy podejścia do wdrożeń i pokazujemy, co sprawdza się w praktyce. Tworzymy materiały, które pomagają lepiej rozumieć IT i podejmować świadome decyzje, zarówno po stronie biznesu, jak i zespołów technologicznych.
