Software House dla bankowości w 2026: 7 kryteriów wyboru najlepszego partnera

Globalne banki wydają na technologię już 600 mld USD rocznie. To znaczna suma, ale dane pokazują, że banki wcale nie tracą apetytu na transformację cyfrową. Wręcz przeciwnie – aż 88% z nich planuje w 2025 roku zwiększyć budżety o kolejne 10%. Cyberbezpieczeństwo wskazują jako priorytet inwestycji.

Nakłady jednak wcale nie przekładają się na przewagę na rynku. Udział IT w przychodach przekroczył 10% i według prognoz BCG będzie rósł w tempie 9% rocznie, ale kapitał zamiast budować innowacje, często trafia w próżnię „pułapki efektywności” i pochłaniają go koszty utrzymania systemów legacy. W praktyce banki wydają coraz więcej, ale coraz trudniej im wyciągnąć realną wartość z inwestycji.

Poniższy raport analizuje 7 filtrów procesu decyzyjnego – od wymogów DORA i ESG po modele Managed Outcomes. W 2026 roku zadecydują one, czy Software House zostanie partnerem o strategicznym znaczeniu dla banku, czy bank wyeliminuje go z łańcucha dostaw już na etapie prekwalifikacji.

Wnioski o kluczowym znaczeniu

• Pułapka efektywności: Obecnie ponad 60% budżetów IT banków pochłania utrzymanie („Run the Bank”). Liderzy na 2026 rok stawiają sobie cel: zredukować wskaźnik poniżej 45% poprzez automatyzację.
• DORA jako efektywne narzędzie selekcji: Regulacja wymusza konsolidację rynku. Dostawcy bez audytowalnego łańcucha podwykonawców i gotowych planów wyjścia (Exit Strategy) odpadają już na etapie prekwalifikacji.
• Koniec body leasingu: Model rozliczeń Time & Material wypierany jest przez Managed Outcomes. Marża dostawcy ściśle wiąże się z dowiezieniem KPI biznesu i przejęciem ryzyka operacyjnego.
• Konieczność ESG (Scope 3): W 2026 roku brak twardych danych o śladzie emisji węgla z usług IT eliminuje dostawcę (knock-out) w przetargach banków Tier-1.
• Kryzys mainframe: Średni wiek ekspertów COBOL przekracza 55 lat. Banki wymagają od partnerów nie tylko ludzi, ale gotowych narzędzi AI do automatyzacji analizy i refaktoryzacji kodu legacy.
• Architektura composable: Banki dążą do uniknięcia „Vendor Lock-in 2.0″. Wymagają od dostawców neutralności technologicznej i przekazania praw autorskich (IP) do komponentów o unikalnym charakterze w systemie.
• AI governance: Wdrożenie autonomicznych agentów (Agentic AI) wymaga od Software House’u zastosowania barier bezpieczeństwa (Guardrails) zgodnych z EU AI Act.

Model działania wprowadzany w 2026: wyraźna odporność

Rok 2026 stanowi cezurę w ewolucji sektora usług finansowych. Po dekadzie walki o wolumen klientów i niskich stóp procentowych banki weszły w nowy model działania: „wyraźną odporność” (Radical Resilience).

Co to oznacza w praktyce? W rzeczywistości kryzysu (permacrisis) – zdefiniowanej przez cyberzagrożenia, nasilenie regulacji (DORA, FIDA) i presję ESG – technologia przestała „wspierać biznes”. Ona jest biznesem. Bank bez sprawnych systemów IT to nie bank, który działa wolniej. To bank, który w ogóle nie działa.

Dla dyrektorów ds. technologii (CIO) i szefów zakupów (CPO) stanowi to istotną zmianę w procesie wyboru partnerów IT. Sukces w 2026 roku nie mierzy się wyłącznie wskaźnikami finansowymi: zwrotem z kapitału (ROE) czy wskaźnikiem kosztów do dochodów (C/I). Nową walutą staje się zdolność do zarządzania złożonością i ciągłością operacji. Pytanie przestało brzmieć „ile oszczędzimy”, a zaczęło „czy przetrwamy kolejny kryzys”.

Software House nie może już być jedynie dostawcą „rąk do pracy” (body leasing). W 2026 roku rynek dzieli dostawców na dwie grupy: tych, którzy rozumieją, że stali się częścią łańcucha wartości banku podlegającego regulacji oraz tych, których bank odcina od kontraktów Tier-1. Nie ma trzeciej opcji.

Mapa drogowa decydenta: 7 filarów selekcji partnera IT

Zanim przejdziemy do analizy ofert, zweryfikujmy kandydata na partnera przez pryzmat poniższych siedmiu kryteriów. Kolejność nie jest przypadkowa – pierwsze z nich stanowią „Deal-Breakers”, które dyskwalifikują dostawcę na etapie prekwalifikacji.

1. Efektywność inżynierii (Engineering First): Dostawca musi udowodnić – nie zadeklarować – jak ucieknie z „pułapki efektywności”. Kluczem są automatyzacja i metryki DORA. Bez dowodów – puste obietnice.
2. Gotowość na regulacje (DORA-Ready): Audytowalny łańcuch poddostawców i polisy pokrywające kary za przestoje stanowią teraz standard, nie opcję. Knock-out criteria – brak któregokolwiek elementu wyklucza vendora z gry.
3. Transparentność ESG (Scope 3): Raportowanie śladu emisji węgla z usług IT przeszło z „nice to have” do twardego wymogu. W 2026 brak danych oznacza ryzyko compliance i koniec rozmowy.
4. Kompetencje w zakresie modernizacji (Legacy & Talent): Luka demograficzna w technologiach mainframe narasta. Partner musi pokazać plan – nie tylko ludzi, ale narzędzia AI do refaktoryzacji długu technicznego. Inaczej utonie razem z bankiem w starym kodzie.
5. Odpowiedzialność za wyniki biznesu (Managed Outcomes): Time & Material odchodzi do lamusa. Liczy się rozliczenie za „dowieziony wynik”. Albo firma bierze na siebie ryzyko operacyjne i wiąże marżę z KPI biznesu, albo szuka klientów gdzie indziej.
6. Zdolność do współtworzenia IP (Composable Banking): Bank potrzebuje partnera, który zintegruje gotowe klocki (SaaS) bez tworzenia kolejnego vendor lock-in. Neutralność technologiczna i przekazanie praw autorskich (IP) do komponentów o unikalnym charakterze stanowią warunki wstępne, nie temat do negocjacji.
7. Dojrzałość AI governance (Agentic AI): Modele AI muszą mieć wbudowane mechanizmy „Guardrails” zgodne z EU AI Act. To nie przyszłość – wymóg regulacji na dziś. W przeciwnym razie autonomiczni agenci pozostają w sferze marzeń.

Kryterium #1: inżynieryjna efektywność i ucieczka z „pułapki efektywności”

Pytanie Procurementu: „Dlaczego mimo rosnącego budżetu IT, wdrażamy zmiany wolniej?”

Banki wydają na technologię więcej niż kiedykolwiek. Budżety rosną w szybkim tempie. A mimo to instytucje działają coraz wolniej, jakby ugrzęzły w technologicznym bagnie. Analitycy Boston Consulting Group nazwali to zjawisko „pułapką efektywności”.

Dane są jasne. Jak wskazuje raport BCG, wydatki na technologię w bankowości rosną globalnie w tempie 9% rocznie (CAGR), znacznie przewyższając inflację. Pieniądze płyną strumieniem. Problem: instytucje nie potrafią wdrażać innowacji – tego, co branża nazywa „change the bank”. Stoją w miejscu. Całe dodatkowe budżety pochłaniają koszty utrzymania istniejących systemów – „run the bank”. Banki płacą coraz więcej, by po prostu nie stanąć w miejscu.

Diagnoza: paraliż struktury

Struktura wydatków pokazuje skalę problemu. W przeciętnym banku na operacyjną działalność idzie ponad 60% budżetu IT: utrzymanie legacy systemów, opłaty za licencje, łatanie luk w bezpieczeństwie, zapewnienie regulacyjnej zgodności. Proporcja staje się bardziej problematyczna, gdy zestawimy ją z innym trendem.

Cykl życia technologii się skraca. Eksperci BCG szacują, że technologiczne umiejętności tracą połowę wartości w ciągu zaledwie czterech lat. Inwestycja w technologię dokonana dziś może okazać się przestarzała, zanim zdążymy ją w pełni wykorzystać. W efekcie banki znalazły się w paradoksalnej sytuacji: inwestują kwoty, by „stać w miejscu”, podczas gdy konkurencja ze strony natywnie cyfrowych podmiotów – neo-banki, BigTech – nie dźwiga bagażu technologii minionych dekad.

Pułapka efektywności wyrasta wprost z tego, że latami kumulowaliśmy dług technologiczny. Decyzje podjęte w latach 2015–2020 – gdy dobudowywaliśmy interfejsy dla urządzeń mobilnych i dla webowych aplikacji do przestarzałych systemów core banking – sprawiają, że w 2026 roku złożoność znacznie rośnie. Każda zmiana w systemie wymaga nakładów na integracyjne i regresyjne testy. Pozornie prosty update może wymagać tygodni pracy, bo trzeba sprawdzić, czy nie rozsypie dziesiątek powiązań z innymi modułami.

Benchmark selekcyjny: struktura zespołu i metryki DORA

Wybierając Software House w 2026 roku, banki muszą odrzucić marketingowe deklaracje o „agile” i „nowoczesnych metodykach”. Zamiast tego – zażądać danych o strukturze kadr i wynikach zespołów.

Stosunek „doers” do „orchestrators”

Wiodące instytucje finansowe restrukturyzują kadry IT. Punkt ciężkości przesuwa się z ról zarządczych – Project Manager, Scrum Master, Coordinator – na inżynieryjne role. Po latach rozbudowywania warstwy koordynacyjnej banki odkryły prawdę: zbyt wielu ludzi planuje pracę, zbyt mało pracuje.

Dane rynkowe pokazują średnią: około 50% personelu to inżynierowie. Zgodnie z rekomendacjami BCG, liderzy transformacji w 2026 roku stawiają sobie cel: 75% personelu IT to inżynierowie („doers”). Software House, który oferuje zespół złożony w dużej mierze z „proxy-managerów” i koordynatorów, jedynie pogłębia pułapkę efektywności. Bank płaci za godziny spotkań, raportów, synchronizacji – nie za kod i rozwiązania. Banki szukają płaskich struktur technologicznych, gdzie każda osoba w zespole coś buduje.

Wskaźniki DORA (DevOps Research and Assessment)

Dostawca musi wykazać doskonałość w czterech metrykach DevOps Research and Assessment. To nie KPI – to miary zdolności do szybkiego, bezpiecznego dostarczania wartości:

• Deployment Frequency: Jak często dostawca wdraża zmiany na produkcję? Bezpiecznie wdraża, nie „pcha na produkcję”. Liderzy rynku osiągają dziesiątki wdrożeń dziennie. Krytyczna poprawka trafia na produkcję w ciągu godziny, nie tygodni. W bankowości, gdzie każda minuta niedostępności systemu płatniczego to utracone miliony, różnica decyduje o konkurencyjności.
• Time-to-Recovery (MTTR): Ile średnio trwa, zanim przywrócimy usługi po awarii. W bankowości każda minuta niedostępności systemu płatniczego to nie tylko utracone przychody, ale przede wszystkim uszczerbek na reputacji. Różnica między MTTR wynoszącym 2 godziny a 20 minut to różnica między utratą zaufania klientów a incydentem, którego większość nawet nie zauważy.
• Change Failure Rate: Jaki odsetek wdrożeń wymaga natychmiastowych poprawek (hotfix). Wysoki wskaźnik oznacza, że jakościowe procesy u dostawcy nie działają. Każdy hotfix to koszt, stres, ryzyko dalszych błędów.
• Lead Time for Changes: Ile czasu mija od zatwierdzenia kodu do uruchomienia na produkcji. Im dłużej, tym mniej elastycznie dostawca reaguje na zmieniające się biznesowe potrzeby. Regulatorzy wprowadzają nowe wymogi, konkurencja wypuszcza nowe funkcje – bank musi nadążać.

Wymagane jest również, by dostawca potrafił zautomatyzować procesy testowania (CI/CD) na poziomie minimum 80% pokrycia automatycznymi testami. Gdy testujemy ręcznie cały system po każdej drobnej poprawce, jest to po prostu niemożliwe czasowo i kosztowo. Automatyzacja minimalizuje koszty regresji przy każdej zmianie w systemie legacy.

Nowa ekonomia: risk-weighted TCO

Dział zakupów (Procurement) i CFO inaczej patrzą teraz na koszty Software House. Stawka za dzień przestała wyznaczać, czy oferta jest atrakcyjna. Perspektywa – skupienie wyłącznie na rate card – była popularna w latach 2010–2020, ale doprowadziła do nietrafnych wyborów. Wprowadzane są zaawansowane modele Risk-Weighted TCO (Total Cost of Ownership skorygowany o ryzyko).

Problem tkwi w konsekwencjach zakupowych decyzji w długoterminowej perspektywie. Software House „tani” w stawce godzinowej, ale który generuje wysoki dług technologiczny – niska jakość kodu, brak testów, powierzchowna dokumentacja – w perspektywie 3–5 lat staje się najdroższym wyborem. Bank oszczędza dziś 20% na stawkach programistów, by za dwa lata wydać trzykrotność kwoty, gdy trzeba będzie refaktoryzować kod albo przepisać system.

Elementy risk-weighted TCO:

1. CAPEX vs OPEX: Banki preferują modele „pay-as-you-grow”, które nie zamrażają kapitału w fazie projektu. Bank chce płacić za wykorzystanie, nie za zakupione licencje leżące na półce.
2. Koszt ryzyka operacyjnego: Godzina niedostępności systemu spowodowana błędem dostawcy w bankach Tier-1 to miliony euro. Jeden incydent może przekreślić wszystkie oszczędności z niskich stawek. Dział zakupów musi przeliczać nie tylko to, ile kosztuje godzina programisty, ale ile może kosztować potencjalna awaria, którą programista spowoduje.
3. Exit Cost: Ile będzie kosztować potencjalna migracja od dostawcy. Uniknięcie vendor lock-in staje się strategicznym priorytetem. Bank musi mieć możliwość zmiany dostawcy bez konieczności przepisywania całej aplikacji od zera. Im bardziej dostawca używa proprietary rozwiązań i niestandardowych architektur, tym wyższy exit cost.

Tabela: transformacja struktury wydatków IT (2026)

Kategoria wydatków	Stan obecny (średnia rynkowa)	Cel liderów transformacji (2026)	Implikacja dla wyboru partnera
Run the bank (utrzymanie)	> 60%	< 45%	Partner, który jedynie rejestruje przepracowane godziny, ale nie automatyzuje tego, jak utrzymuje systemy, pogłębia problem zamiast go rozwiązywać.
Change the bank (innowacja)	< 40%	> 55%	Partner musi posiadać innowacyjne kompetencje (Agentic AI, Composable Architecture) i udowodnić je referencjami, nie slajdami.
Struktura kadr	47% Doers	75% Doers	Każdy dodatkowy manager projektu, który bezpośrednio nie wnosi technologicznej wartości, zwiększa koszt bez zwiększania wartości.
Dług technologiczny	Ukryty	15% Budżetu (jawna spłata)	Umowa musi zobowiązywać do systematycznej refaktoryzacji, nie tylko do dostarczania nowych funkcji.

Źródło: Opracowanie własne na podstawie danych BCG.

Decyzja procurementu: kto odpada w przedbiegach?

W ramach Kryterium #1, banki w 2026 roku odrzucają dostawców według jasnych, mierzalnych kryteriów:

• Brak metryk efektywności: Dostawca nie potrafi przedstawić danych historycznych o tym, jak efektywnie wdraża. Bez metryk DORA oznacza to jedno – nie mierzy jakości pracy. A czego nie mierzymy, tym nie zarządzamy. Odpowiedź „pracujemy agile, nie gromadzimy takich danych” dyskwalifikuje natychmiast.
• Niski wskaźnik inżynierów: Dostawca utrzymuje niski wskaźnik inżynierów w zespołach (poniżej 60%), próbując maskować to rozbudowanym managementem projektu. Bank widzi jasno: płaci za koordynację, nie za wykonanie. Oferta zawierająca 3 Scrum Masterów na 5 programistów to sygnał ostrzegawczy.
• Brak kontroli długu technologicznego: Dostawca nie posiada procesów, które automatycznie kontrolują dług technologiczny. Bez narzędzi takich jak SonarQube jako standard kontraktu oznacza to, że jakość kodu nie jest monitorowana systematycznie, tylko okazjonalnie – gdy już jest za późno. Dług kumuluje się w cieniu, by eksplodować za rok lub dwa.

Kryterium #2: gotowość na regulacje (DORA-ready) i konsolidacja dostawców

Pytanie Procurementu: „Czy dostawca potrafi udowodnić, że nie stanowi zagrożenia dla systemu Banku?”

Gdy w styczniu 2025 roku weszło w życie rozporządzenie Digital Operational Resilience Act (DORA), z wymaganą w 2026 roku implementacją, zmieniło to relacje na linii bank-dostawca technologii. To nie kolejna inicjatywa compliance, którą można zrzucić na dział prawny i zapomnieć. DORA przestała być postrzegana jako „kolejny projekt zgodności z regulacjami”. Stała się czynnikiem, który kształtuje architekturę korporacji i zakupową strategię banków.

W 2026 roku „compliance” to nie dodatek do usługi. To usługa sama w sobie. Bank nie kupuje już tylko technologicznych kompetencji – kupuje to, że dostawca potrafi udowodnić zgodność, przejrzystość i operacyjną odporność.

Nowy cykl życia wyboru dostawcy (vendor selection lifecycle 2026)

Proces wyboru dostawcy się wydłużył i stał bardziej formalny. Ścieżka o tradycyjnym charakterze RFI (Request for Information) → RFP (Request for Proposal) odeszła do lamusa. Zastąpił ją lejek bezpieczeństwa, który eliminuje większość kandydatów na samym początku procesu:

1. Pre-qualification (bramka DORA): Etap eliminacji, który odbywa się jeszcze przed formalnym zapytaniem ofertowym. Bez gotowych raportów zgodności, polis ubezpieczeniowych pokrywających ryzyko cybernetyczne i udokumentowanego łańcucha poddostawców – dostawca nie otrzymuje nawet zapytania ofertowego. To skutecznie odcina tych, którzy nie spełniają wymogów.
2. Risk Assessment: Dział Vendor Risk Management (VRM) ocenia ryzyko koncentracji. Pytanie centralne: czy bank nie jest już zbyt uzależniony od dostawcy? Czy awaria u partnera nie sparaliżowałaby krytycznych procesów biznesowych? To analiza portfela dostawców pod kątem tego, jak zdywersyfikować ryzyko.
3. Proof of Concept (PoC) / Technical Challenge: Weryfikacja kompetencji „hands-on” na żywym organizmie. Bank nie wierzy już w slajdy PowerPoint i referencje. Chce zobaczyć działający kod, przeprowadzić testy bezpieczeństwa, sprawdzić, jak zespół reaguje na symulowane incydenty.
4. Decyzja tieringowa: Dostawcę klasyfikuje się jako „krytycznego” (Tier-1) lub „wspierającego” (Tier-2). Tier-1 oznacza pełny reżim audytu – regularne audyty, ciągły monitoring, testy penetracji. To zobowiązanie dla dostawcy, które wiąże się z dodatkowymi kosztami i zasobami.

Wymogi regulacyjne: koniec ukrywania podwykonawców

Regulacja DORA nakłada na finansowe instytucje obowiązki, jeśli chodzi o to, jak zarządzają ryzykiem z zewnątrz (Third-Party Risk Management – TPRM). Raport EY podkreśla, że banki muszą nie tylko monitorować bezpośrednich dostawców, ale także posiadać wiedzę o podwykonawcach, którzy wspierają biznesowe funkcje.

Każda umowa ICT musi trafić do scentralizowanego rejestru, który zawiera dane o tym, jak są usługi, gdzie przetwarza się dane i jaki jest łańcuch podmiotów powiązanych. Standardy techniczne omawiane przez Deloitte oznaczają dla Software House koniec ukrywania podwykonawców. Popularna praktyka zatrudniania „freelancerów B2B” bez formalnego zgłoszenia teraz bezpośrednio narusza regulację. Bank musi wiedzieć, kto ma dostęp do danych, gdzie siedzi, jakie ma kompetencje i czy przeszedł weryfikację bezpieczeństwa. Dostawca, który odpowiada „mamy elastyczny model zasobów, w razie potrzeby dołączamy dodatkowe osoby” bez możliwości natychmiastowego wskazania osób z imienia i nazwiska – nie spełnia wymogów.

Mechanizm wymuszonej konsolidacji

To, jak złożone i kosztowne jest zachowanie zgodności z DORA, sprawia, że ekonomicznie nie ma już sensu utrzymywać rozdrobnionej bazy dostawców. Banki, które wcześniej stosowały strategię „best-of-breed” – integrując setki rozwiązań niszowych od dziesiątek różnych vendorów – jak zauważa Forrester, w 2026 roku masowo konsolidują portfel dostawców. To nie przypadkowa tendencja. To strategia, którą wymusza ekonomika compliance.

Dzieje się tak z trzech powodów:

1. Koszty nadzoru: Każdy dodatkowy dostawca to dodatkowy koszt audytu, testów penetracji (TLPT) i monitoringu SLA. Dane Forrestera dowodzą, że gdy bank redukuje liczbę dostawców o 20–30%, przynosi to oszczędności w obszarze compliance. Koszty nie rosną liniowo – rosną znacznie. Gdy zarządzamy 100 dostawcami, koszty nie są dwa razy wyższe niż przy 50 dostawcach, ale często czterokrotnie wyższe. Każdy vendor wymaga managera ryzyka, cyklicznych audytów, testów, weryfikacji tego, jak zmienia infrastrukturę.
2. Odpowiedzialność zarządu: Eksperci EY przypominają, że DORA przypisuje bezpośrednią, osobistą odpowiedzialność za ryzyko ICT członkom zarządu banku. Nie deleguje się tego na CIO czy CISO – to odpowiedzialność na poziomie Board of Directors. W obliczu administracyjnych kar sięgających milionów euro i ryzyka dla reputacji, decydenci preferują współpracę z dużymi, stabilnymi podmiotami. Duże, stabilne podmioty dysponują zasobami – działy prawne, polisy ubezpieczeniowe, procedury zarządzania w kryzysowej sytuacji – by zagwarantować bezpieczeństwo. Mały, dynamiczny startup może mieć technologię, ale rzadko dysponuje ubezpieczeniem na 50 milionów euro czy działem compliance.
3. Szacunki kosztów wdrożenia: Według szacunków McKinsey, koszt pełnego wdrożenia DORA w dużych grupach finansowych może sięgać nawet 100 milionów euro. Kwota obejmuje nie tylko technologiczne zmiany, ale przede wszystkim budowę całego aparatu compliance, audytu, monitoringu. Banki oczekują, że partnerzy o strategicznym znaczeniu wezmą na siebie część ciężaru związanego z dostosowaniem. Dostawca, który mówi „to problem banku, nie nasz” – odpada.

FIDA: otwartość vs bezpieczeństwo

Równolegle do DORA, ramy prawne Financial Data Access (FIDA) wymuszają na bankach, by udostępniały dane klientów szerszemu ekosystemowi. Tworzy to napięcie, które trudno rozwiązać bez odpowiedniej technologii. Bank musi być otwarty (FIDA wymaga, by dzielił się danymi z zewnętrznymi podmiotami posiadającymi autoryzację), ale jednocześnie hermetyczny (DORA wymaga maksymalnego bezpieczeństwa i kontroli).

Wyobraźmy sobie sytuację: fintech chce pobrać dane transakcji klienta – FIDA wymaga, by bank udostępnił dane po uzyskaniu zgody. Jednocześnie każde API musi być zabezpieczone na najwyższym poziomie, monitorowane w czasie rzeczywistym, z pełnym audit trail – tego wymaga DORA. Tradycyjne systemy nie są zaprojektowane do dwoistości. API stworzone dla wewnętrznych potrzeb banku nagle musi obsłużyć setki podmiotów z zewnątrz, każdy z innym poziomem zaufania, innymi uprawnieniami, innym profilem ryzyka.

Analiza trendów CIO przeprowadzona przez SAP wskazuje, że banki w 2026 roku poszukują platform oferujących „compliance by design” – wbudowane mechanizmy, które zarządzają zgodami i bezpieczeństwem API. Zamiast doklejać warstwy bezpieczeństwa post factum, bank potrzebuje architektury, gdzie zgodność z regulacjami stanowi fundament, nie dodatek. To sprzyja dostawcom, którzy oferują kompleksowe platformy (end-to-end suites) kosztem dostawców punktowych rozwiązań. Gdy integrujemy dziesiątki niezależnych narzędzi, to recepta na lukę w zabezpieczeniach – każdy styk między systemami to potencjalna furtka dla ataku.

Decyzja procurementu: knock-out criteria (kogo eliminujemy?)

W kontekście Kryterium #2, Software House odpada z gry według jasno określonych kryteriów do wykluczenia:

• Brak audytowalności: Dostawca nie zgadza się na zewnętrzne audyty bezpieczeństwa i procesów wytwarzania na żądanie regulatora – KNF, EBA – w ciągu 24–48 godzin. Jeśli dostawca potrzebuje tygodni, by przygotować dokumentację albo odmawia dostępu audytorom, to czerwona flaga. Bank nie może sobie pozwolić na partnera, który blokuje nadzór. Regulator nie będzie czekał, aż dostawca „uporządkuje dokumentację”.
• Niejasny łańcuch poddostawców: Dostawca nie potrafi natychmiast zaraportować pełnego łańcucha sub-outsourcingu do Rejestru Informacji ICT banku. Odpowiedź „sprawdzimy i prześlemy za tydzień” jest nieakceptowalna. Bank musi mieć real-time visibility na wszystkich uczestników łańcucha dostaw. Każda osoba z dostępem do kodu, środowiska testowego czy produkcyjnych danych musi być znana z imienia, nazwiska, lokalizacji i statusu prawnego.
• Brak wsparcia exit plan: Dostawca nie chce lub nie potrafi aktywnie wspierać tego, jak tworzymy plany wyjścia (exit strategies) dla jego usług. To klasyczny objaw vendor lock-in w fazie zawierania kontraktu. Jeśli dostawca nie jest gotów pomóc bankowi w ewentualnej migracji do innego partnera, oznacza to, że podstawa modelu biznesowego opiera się na tym, że uzależnia klienta, nie na oferowanej wartości usługi. Dobry partner wie, że zarabia na jakości, nie na tym, że nie można od niego odejść.

Failure mode (przykład z życia wzięty)

Firma „DORA-ready na papierze”. Deklaruje zgodność w ofercie, przedstawia certyfikaty i dokumenty. Bank decyduje się na współpracę. Pierwszy audyt operacyjny – na przykład testy penetracji według metodyki TIBER-EU – kończy się niepowodzeniem. Okazuje się, że dokumentacja nie odpowiada rzeczywistości, a zabezpieczenia istnieją tylko w procedurach, nie w kodzie. Firewall skonfigurowany domyślnie, hasła do środowisk testowych to „admin123”, backup działa „prawie zawsze”. Bank marnuje miesiące i setki tysięcy euro na partnera, który nie przetrwał pierwszej weryfikacji. To, ile kosztuje zerwanie umowy i znalezienie nowego dostawcy, przewyższa wielokrotnie oszczędności z atrakcyjnej oferty.

Kryterium #3: Transparentność ESG i Scope 3

Pytanie procurementu: „Czy współpraca z tym dostawcą pogorszy nasz aport niefinansowy i podniesie koszt kapitału?”

Dyrektywa CSRD (Corporate Sustainability Reporting Directive) zobowiązuje banki do raportowania nie tylko własnych emisji, ale przede wszystkim emisji z łańcucha wartości – tzw. Scope 3.

Scope 3 jako nowe ryzyko finansowe

Dla sektora bankowego Scope 3 dominuje w strukturze emisji, obejmując finansowane emisje – cały portfel kredytowy – oraz emisje z łańcucha dostaw, gdzie przeważają zakupione towary i usługi IT. Szacunki ekspertów Capgemini wskazują, że Scope 3 może stanowić nawet 95% całkowitego śladu węglowego finansowej instytucji. Bank może prowadzić zielone biurowce, ale kiedy finansuje elektrownię węglową lub współpracuje z dostawcą IT o wysokiej emisji, wskaźniki ESG znacznie spadają.

Brak precyzji danych w tym obszarze przekłada się na ryzyko zgodności i reputacji. Autorzy raportu ostrzegają, że banki, które nie realizują celów dekarbonizacji (SBTi), mają trudniejszy dostęp do taniego finansowania na międzynarodowych rynkach.

Instytucjonalni inwestorzy patrzą na wskaźniki ESG równie uważnie jak na rentowność. W analizach Capgemini na 2026 rok „Green Risk” wchodzi integralnie do oceny dostawcy, stając obok ryzyka finansowego i ryzyka cybernetycznego. Dostawca o wysokim śladzie węglowym – nieefektywne centra danych, stary sprzęt, brak energetycznej polityki – naraża się na ryzyka transformacji: węglowe podatki, wzrost cen energii, koszty dostosowania do regulacji. Te ryzyka bank odczuwa bezpośrednio jako wzrost kosztów.

Sustainable procurement: mechanizm selekcji

Banki wdrażają w odpowiedzi rygorystyczne polityki „Sustainable Procurement”. Kryteria ESG stają się warunkiem koniecznym – knock-out criteria – w przetargach na usługi IT. Efekt? Software House bez raportu ESG odpada w prekwalifikacji, niezależnie od ceny czy jakości kodu. Można mieć najlepszy zespół programistów i najbardziej konkurencyjną wycenę – bez certyfikowanych danych o emisjach oferta trafia do kosza.

Banki wykorzystują siłę nabywczą, wymuszając na dostawcach redukcję emisji. Według benchmarków Capgemini, współpracę z vendorami niezdolnymi do dostarczenia wiarygodnych danych o śladzie węglowym usług – energochłonności chmury, śladzie węglowym pracy programistów – stopniowo wygaszają.

Green coding

Na rynku pojawia się wymiar konkurencji: Green Coding. Banki zaczynają wymagać optymalizacji kodu pod kątem zużycia energii. Zły kod to nie tylko wolna aplikacja – to aplikacja zużywająca więcej prądu w chmurze, podnosząca rachunki banku i pogarszająca wskaźniki ESG. Każda nieoptymalna pętla, każde zbędne zapytanie do bazy danych przekłada się na kilowatogodziny. Dostawcy oferujący energetyczną optymalizację oprogramowania zyskują przewagę w przetargach.

Decyzja procurementu: kto zostaje wykluczony?

W ramach Kryterium #3 proces selekcji przebiega zero-jedynkowo:

• Brak danych (No Data, No Deal): Dostawca nie raportuje emisji w zakresach Scope 1, 2 i 3. Brak certyfikowanych danych oznacza odrzucenie oferty – bank nie może wpisać „zera” w raporcie CSRD ani napisać „dane niedostępne” bez narażenia się na audyt i potencjalne kary.
• Brak planu dekarbonizacji: Dostawca nie posiada zatwierdzonych celów redukcji emisji, na przykład w ramach Science Based Targets initiative (SBTi). Banki wymagają konkretów: zatwierdzonych celów, harmonogramu działań, mierzalnych kamieni milowych.
• Greenwashing: Dostawca deklaruje „neutralność klimatyczną” opartą wyłącznie na tanim offsetowaniu emisji – sadzeniu lasów, które pochłoną CO2 dopiero za 20–30 lat, o ile w ogóle nie spłoną. Banki w 2026 roku rozpoznają greenwashing natychmiast. Neutralność klimatyczna musi opierać się na redukcji zużycia energii i optymalizacji infrastruktury, nie na zakupie offsetowych certyfikatów.

Kryterium #4: Kompetencje w zakresie modernizacji – demografia i AI

Pytanie procurementu: „Kto naprawi nasze krytyczne systemy, gdy ostatni eksperci przejdą na emeryturę?”

Mimo postępującej chmuryzacji mainframe’y w 2026 roku pozostają bijącym sercem transakcyjnych systemów wielu największych banków świata, przetwarzając miliardy operacji dziennie. Technologia ta stoi jednak w obliczu zagrożenia o naturze nie technicznej, lecz demograficznej.

Demograficzna bomba zegarowa

Średnia wieku ekspertów od technologii mainframe i języka COBOL przekracza 55 lat. Luka w kompetencjach powiększa się z każdym rokiem. Specjaliści IBM zauważają, że doświadczeni inżynierowie odchodzą na emeryturę, a uniwersytety od lat nie kształcą następców. Studenci nie uczą się COBOL-a – to technologia postrzegana jako „dinozaur”, niepasująca do nowoczesnego CV. Młodzi programiści chcą pisać w Pythonie, React, Go – chcą budować mobilne aplikacje i systemy AI, nie utrzymywać kodu z lat 70.

Powstaje paradoks: systemy przetwarzające setki miliardów dolarów dziennie zależą od kurczącego się grona specjalistów, których usługi drożeją z każdym rokiem. To klasyczne ryzyko operacyjne w rozumieniu DORA. Ankiety rynkowe Ensono mówią jednoznacznie: 79% liderów biznesu uznaje pozyskanie odpowiednich zasobów i umiejętności za największe wyzwanie związane z utrzymaniem platform mainframe.

Software House ignorujący ten problem i oferujący tylko „modne” technologie cloud-native nie wchodzi w rolę strategicznego partnera dla Tier-1 Banku. Pozostaje partnerem tylko do „ładnych interfejsów” – warstw widocznych dla użytkownika. To, co dzieje się w głębi, w core banking system, pozostaje nierozwiązanym problemem.

Strategie modernizacji: precyzja chirurgiczna vs AI

W 2026 roku banki wymagają od partnerów IT czegoś więcej niż tylko „przepisania systemu”. Nauczyły się bolesnych lekcji z modernizacyjnych projektów zakończonych katastrofą – przepalone budżety, niedziałające systemy, rozliczenia sądowe. Dziś wymagają strategii dopasowanej do typu długu technologicznego.

• Tier-1 Legacy Bank: Posiada miliony linii kodu w COBOL/PL1 – kod pisany przez dekady, warstwa po warstwie, przez różnych programistów, często bez dokumentacji. Tutaj bank szuka partnera do „chirurgicznej migracji” lub „bezpiecznej hibernacji”. Nie można wyłączyć mainframe’a i przepisać wszystkiego od nowa – to byłoby operacyjne samobójstwo.
• Digital Challenger: Nie posiada mainframe’u, ale zmaga się z „Legacy 2.0″ – mikroserwisami pisanymi 5–6 lat temu w technologiach, które już wyszły z głównego nurtu: stare wersje Angulara, Node.js bez wsparcia LTS, nieaktualizowane biblioteki.

Rola AI w modernizacji

Banki w 2026 roku masowo wykorzystują AI jako narzędzie mitygacji ryzyka utraty wiedzy. Strategie opisywane przez Bain & Company pokazują, jak zaawansowane modele analizują stary kod, dokumentują go i tłumaczą na nowoczesne języki – Java, C#, Python. Młody programista nieznający COBOL-a może użyć AI do przeanalizowania kodu z 1987 roku, wygenerowania dokumentacji i przetłumaczenia go na pseudokod zrozumiały dla programisty Java. To zmienia ekonomię modernizacji.

Software House musi jednak wykazać się ostrożnością. Banki rozumieją ryzyko „Black Box” – sytuacji, w której AI wygeneruje kod, którego nikt nie rozumie.

Failure mode (porażka modernizacyjna)

Przykład: Software House chwalił się użyciem autorskiego AI do automatycznej translacji COBOL → Java. Obiecywano redukcję kosztów o 70%, skrócenie czasu migracji o połowę. Efekt? Powstał kod w Javie strukturalnie naśladujący stare procedury COBOL-a – tzw. „Java-flavoured COBOL”. Kod pozostał niezrozumiały dla programistów Java, ponieważ używał proceduralnych wzorców zamiast obiektowych wzorców. Nikt nie mógł go utrzymywać. TCO (Total Cost of Ownership) systemu wzrosło zamiast spaść, a bank musiał zatrudnić drogich konsultantów do „odkręcania” migracji. W niektórych modułach wrócono do oryginalnego COBOL-a. Lekcja: automatyzacja migracji musi iść w parze z głębokim zrozumieniem wzorców programowania i docelowej architektury.

Citizen development: równoległy rozwój

Równolegle, w obliczu niedoboru inżynierów, banki otwierają się na „Business Technologists” – domenowych ekspertów używających platform Low-Code/No-Code. To analitycy biznesowi budujący proste aplikacje bez pisania tradycyjnego kodu – przeciągają komponenty w graficznym interfejsie, łączą ze źródłami danych, tworzą formularze i raporty.

Rola CIO ewoluuje w kierunku „strażnika platformy”. Zgodnie z wizją BCG, zamiast tego IT dostarcza bezpieczne środowisko (Governance), w którym biznes buduje proste aplikacje, nie naruszając standardów bezpieczeństwa.

Decyzja procurementu: wymogi wobec partnera

W ramach Kryterium #4 Software House musi udowodnić:

• Narzędzia AI do migracji: Potrzeba własnych lub sprawdzonych narzędzi AI przyspieszających analizę i refaktoryzację kodu legacy. Samo „ręczne” przepisywanie trwa zbyt długo i kosztuje zbyt dużo – w bankach mamy miliony linii kodu. Bez case studies z udanych migracji brak wiarygodności.
• Coverage refaktoryzacji: Gwarancja, że po migracji kod będzie pokryty jednostkowymi testami w stopniu przekraczającym 80%. Bez testów każda zmiana w nowym kodzie staje się loterią – może zadziałać, a może zepsuć coś w innym module.
• Akademie kadr: Programy szkoleniowe (np. New to Z) gwarantujące dopływ kadr do utrzymania legacy. Bazowanie tylko na coraz droższych freelancerach, licytowanie się z konkurencją o kurczące się grono specjalistów nie tworzy długoterminowego modelu.

Kryterium #5: Biznesowa odpowiedzialność (managed outcomes)

Pytanie procurementu: „Dlaczego mamy płacić za wasz czas, skoro interesuje nas tylko wynik?”

Tradycyjny model outsourcingu IT, oparty na „body leasingu” (rozliczenie Time & Material – T&M), w 2026 roku ulega erozji. Przez lata banki wynajmowały setki specjalistów, płacąc za czas pracy – niezależnie od tego, czy projekt szedł zgodnie z planem, czy wykolejał się. Bank brał na siebie pełne ryzyko zarządzania projektem. W obliczu „Pułapki efektywności” oraz wymogów DORA dotyczących jasnego podziału odpowiedzialności, zarządy uznały ten model za nieakceptowalny.

Zmierzch modelu „Time & Material”

Dla Software House’ów oznacza to koniec ery „sprzedawania CV”. Nie wystarczy wystawić faktury za 1000 roboczogodzin seniora programisty. Raporty McKinsey on Risk potwierdzają, że banki masowo przechodzą na modele Managed Services i Managed Outcomes. Zmienia się struktura marży i ryzyka:

• Model T&M (malejący): Niska marża dostawcy, całe ryzyko po stronie banku. W 2026 stosowany tylko do prostych prac (staff augmentation) lub w małych spółdzielczych bankach bez zasobów do zarządzania dostawcami w zaawansowanych modelach.
• Model Managed Outcome (rosnący): Wyższa marża dla dostawcy – premia za przejęcie ryzyka. Bank płaci tylko za efekt. Wymaga to od dostawcy operacyjnej doskonałości. Jeśli „przepali” budżet, pokrywa to z własnej kieszeni.

W tym modelu działania bank definiuje cel – na przykład: „utrzymanie dostępności systemu natychmiastowych płatności na poziomie 99,999%” lub „wdrożenie modułu AI do detekcji fraudów w 3 miesiące z dokładnością detekcji minimum 95%”. Dostawca wycenia realizację tego celu, biorąc na siebie ryzyko doboru metod, narzędzi i kadr.

Ekonomia współpracy: SLA i malusy

W 2026 roku kontrakt z Software Housem przypomina bardziej polisę ubezpieczeniową niż umowę o dzieło. Z perspektywy Vendor Risk Management decydują:

• SLA (Service Level Agreement): Gwarancje technicznej dostępności. Nie „dołożymy starań” – tylko konkretne liczby. Dostępność 99,9% oznacza maksymalnie 8,76 godzin przestoju rocznie. Przekroczenie? Finansowe kary.
• Business KPIs: Powiązanie wynagrodzenia dostawcy z wynikami biznesowymi. Jeśli bank wdraża nowy kanał sprzedaży kredytów online, współczynnik konwersji z aplikacji do wypłaty kredytu staje się KPI-em dostawcy. Konwersja poniżej 15%? Malus. Powyżej 20%? Bonus.
• Risk Sharing / Malus Clauses: Klauzule, w których dostawca finansowo partycypuje w kosztach awarii (zgodnie z reżimem DORA) lub opóźnień wdrożeniowych. Przykład: jeśli system płatności padnie na 2 godziny podczas Black Friday, wizerunkowe i operacyjne koszty banku mogą sięgnąć milionów. Dostawca płaci określony procent tych kosztów.

Failure mode (porażka wdrożeniowa)

Przypadek niepowodzenia: Bank wybrał dostawcę w modelu Managed Outcome (Fixed Price), kierując się najniższą ceną ryczałtową – o 30% tańszą niż konkurencja. Brzmiało idealnie – fixed price, przewidywalny budżet, wszystkie ryzyka po stronie vendora. Problem? Dostawca, aby utrzymać marżę przy tak niskiej cenie, zaczął ciąć koszty. Ograniczył regresyjne testy – zamiast pełnego coverage, testował tylko „happy path”. Ograniczył code review – seniorzy sprawdzali co piątą zmianę zamiast każdej. Efekt: mimo „dowiezienia” funkcjonalności w terminie, system okazał się niestabilny. Dług techniczny ukryty w jakości kodu eksplodował po wdrożeniu – awarie, rollbacki, kryzysowe poprawki. TCO (Total Cost of Ownership) systemu okazało się wyższe o 200% od zakładanych. Bank formalnie zaoszczędził na wdrożeniu, ale wydał fortunę na utrzymanie.

Luka kadr i rola MSSP

Przejście na Managed Outcomes stanowi również odpowiedź na kryzys kadr. Banki przegrywają walkę o najlepszych inżynierów z BigTechami – Google, Meta, Amazon płacą dwukrotnie więcej i oferują benefity, których bank nigdy nie przebije.

Dostawcy usług Managed Services, operujący w skali globalnej, lepiej zarządzają ścieżkami kariery – mogą rotować ludzi między projektami, oferować technologiczną różnorodność. Dla banku – jak argumentuje BCG – oznacza to stabilność, gdzie odejście programisty staje się problemem dostawcy, który musi zapewnić ciągłość usługi zgodnie z SLA. Bank nie budzi się rano z informacją „senior developer odszedł do konkurencji, projekt stoi”.

Szczególnie widoczne staje się to w cyberbezpieczeństwie. Niedobór ekspertów SecOps sprawia, że banki oddają całe procesy monitorowania (SOC – Security Operations Center) wyspecjalizowanym dostawcom MSSP (Managed Security Service Providers). Prognozy McKinsey wskazują na wzrost udziału MSSP w rynku bezpieczeństwa dla bankowości do 2026 roku.

Decyzja procurementu: kto wchodzi do gry?

W ramach Kryterium #5 banki w 2026 poszukują partnerów, którzy:

• Cenowa elastyczność: Oferują modele z mechanizmem gain-sharing (podział korzyści z optymalizacji), a nie tylko sztywne stawki godzinowe. Przykład: dostawca optymalizuje kod i redukuje koszty chmurowej infrastruktury o 20%. Zamiast zatrzymać oszczędności dla siebie, dzieli się nimi z bankiem w proporcji 50/50. To wyrównanie interesów.
• Gwarancja jakości: Gotowość przejęcia kontraktowej odpowiedzialności za błędy w kodzie (warranty & support) zamiast przerzucania ich na bankowe zespoły zajmujące się utrzymaniem. W tradycyjnym modelu T&M, gdy programista napisał kod z błędem, bank płacił za godziny naprawy. W nowym modelu dostawca naprawia błędy na koszt przez okres gwarancji (często 12–24 miesiące).
• Techniczne benchmarki dojrzałości: Dostawca musi pokazać mierzalne wskaźniki operacyjnej doskonałości. Na przykład Innovation Cycle Time – jak szybko wdraża usprawnienia w zarządzanym procesie. Jeśli cykl od pomysłu do wdrożenia trwa 3 miesiące, a konkurencja robi to w 3 tygodnie, to czerwona flaga. Bank kupuje nie tylko kod, ale zdolność do szybkiej ewolucji systemu.

Kryterium #6: Zdolność do współtworzenia IP (Composable banking)

Dylemat procurementu: Kupujemy elastyczność czy budujemy nowe uzależnienie?

„Composable banking”, czyli bankowość komponentowa, przestała być technologiczną nowinką – to dominujący standard nowych wdrożeń. Rynek tych aplikacji rośnie w tempie 17,5% rocznie (CAGR), a prognozy ResearchAndMarkets wskazują, że do 2028 roku osiągnie wartość 11,8 miliarda dolarów.

Te liczby niosą konkretne konsekwencje. Banki porzucają monolityczne struktury na rzecz podejścia opartego na PBC (Packaged Business Capabilities). W ramach tego modelu systemy buduje się z niezależnych, gotowych komponentów – takich jak silnik kredytowy, moduł KYC czy księga główna – komunikujących się poprzez API.

Dla software house’ów to koniec ery prostego body leasingu. Banki nie szukają wykonawców do izolowanego tworzenia oprogramowania dedykowanego (custom development). Potrzebują zaawansowanych integratorów, którzy potrafią orkiestrować gotowe elementy. Finansowe instytucje odchodzą od ryzykownych projektów wymiany całego systemu jednego dnia („Big Bang”). Zastępuje je strategia „Hollowing out the Core” – stopniowa dekompozycja rdzenia. Funkcje przenosi się na nowoczesne platformy krok po kroku, aż serce starego systemu przestanie bić.

Dylemat własności intelektualnej: Commodity vs differentiator

Ekspansja rozwiązań SaaS zmusza dyrektorów IT (CIO) do rozstrzygnięcia strategicznej kwestii: gdzie w świecie gotowych klocków leży przewaga konkurencyjna? Gdy wszyscy korzystają z tych samych procesowych silników od wąskiej grupy globalnych vendorów (np. Mambu, Thought Machine), wyróżnienie się na rynku wymaga strategicznej decyzji o lokalizacji unikalnego IP.

W 2026 roku krystalizuje się podział determinujący rolę software house’u. Strategiczna dychotomia „Build vs Buy” zależy bezpośrednio od klasyfikacji danego biznesowego obszaru:

Obszar	Strategia	Rola software house’u	Status IP (własność)
Commodity (np. księga główna, płatności SEPA)	KUPUJ (SaaS)	Integrator. Wdraża gotowe rozwiązanie „z pudełka”, minimalizuje kosztowną kastomizację.	IP należy do dostawcy SaaS. Bank płaci jedynie za licencję.
Differentiator (np. scoring ryzyka, UI/UX, AI personalizacja)	BUDUJ (Custom)	Współtwórca (Co-creator). Buduje unikalne rozwiązanie od zera lub na bazie open source.	IP musi należeć do banku. To „korona królestwa”.

Źródło: Opracowanie własne na podstawie analiz rynkowych Mambu.

Wniosek jest jeden: software house, który próbuje sprzedać własny, zamknięty system do obsługi obszaru „Differentiator”, nie rozumie potrzeb banku klasy Tier-1. Instytucje te szukają partnerów działających jak przedłużenie wewnętrznych działów R&D i godzących się na transfer praw autorskich w modelu work for hire.

Ryzyko „vendor lock-in” i mapa kompetencji

Model composable, mimo zalet, generuje nowe zagrożenia. Wielość dostawców rodzi ryzyko uzależnienia (vendor lock-in) w nowej formie – nie od jednego monolitu, lecz od gęstej sieci powiązań API. Dlatego w 2026 roku banki kładą nacisk na architekturę „vendor agnostic”. System musi pozwalać na relatywnie łatwą i bezpieczną wymianę modułów. To fundament strategii odporności wymaganej przez unijne rozporządzenie DORA – bank musi, co podkreślają eksperci EY, posiadać realny plan wyjścia (exit strategy) dla każdego krytycznego komponentu.

Mapa kompetencji (Skills matrix 2026)

Aby obsłużyć ten model, software house musi wykazać się nowym zestawem kompetencji, weryfikowanym podczas technicznego audytu:

• Techniczne (must-have): Biegłość w architekturze sterowanej zdarzeniami (Event-Driven Architecture, np. Kafka) oraz konteneryzacji (Kubernetes). Kluczowa jest też doskonała jakość dokumentacji API (Swagger/OpenAPI).
• Operacyjne: FinOps, czyli umiejętność optymalizacji kosztów chmury (elastyczność nie może zrujnować budżetu) oraz Site Reliability Engineering (SRE) dla zapewnienia ciągłości działania.
• Integracyjne: Głęboka znajomość ekosystemu PBC (np. Salesforce, Temenos, Mambu) i umiejętność ich bezpiecznego spięcia bez tworzenia plątaniny zależności („spaghetti code”).

Decyzja procurementu: Kto odpada?

W ramach analizy Kryterium #6 banki bezwzględnie odrzucają dostawców, którzy wykazują:

• Brak neutralności technologicznej: Próby wdrażania własnych, zamkniętych rozwiązań tam, gdzie standardem jest SaaS lub open source.
• Słabą kulturę API: Traktowanie API jako technicznego dodatku, a nie produktu (API-as-a-Product), co drastycznie utrudnia integrację i podnosi koszty utrzymania.
• Opór przed przekazaniem IP: Brak zgody na modele joint venture lub pełny transfer kodów źródłowych w warstwie budującej przewagę konkurencyjną („Differentiator”).

Kryterium #7: Dojrzałość AI governance (Agentic AI)

Pytanie procurementu: Kto odpowie karnie, gdy AI odmówi kredytu – my czy dostawca?

Rok 2026 to moment przełomowy. Sztuczna inteligencja w bankowości przechodzi z generatywnej fazy (tworzenie treści, proste chatboty) do agentowej fazy (Agentic AI). Systemy te autonomicznie planują, podejmują decyzje i wykonują złożone działania w imieniu banku lub klienta – np. samodzielnie, jak opisuje to Capgemini, procesują restrukturyzację zadłużenia. Raporty tej samej firmy wskazują, że adopcja Agentic AI przyspiesza, a średni zwrot z inwestycji (ROI) wynosi 1,7x. Jednak wdrożenie systemów o tak wysokiej autonomii redefiniuje odpowiedzialność prawną i etyczną.

EU AI Act: Nowe reguły gry

W 2026 roku banki działają w reżimie pełnego obowiązywania EU AI Act. Systemy oceny zdolności kredytowej oraz inne algorytmy decyzyjne zyskały status systemów „wysokiego ryzyka”. Wymusza to na bankach wdrożenie rygorystycznych ram nadzoru:

1. Nadzór czynnika ludzkiego: Decyzje o dużym znaczeniu musi zatwierdzać lub nadzorować człowiek. Automat sugeruje, ale nie wyrokuje.
2. Wytłumaczalność (XAI): Bank musi wyjaśnić logikę każdej decyzji agenta AI. Funkcjonowanie na zasadzie „czarnej skrzynki” jest nielegalne.
3. Odporność: Systemy muszą przechodzić regularne testy pod kątem ataków (np. wstrzykiwanie promptów) oraz uprzedzeń (bias), na co uwagę zwraca Capgemini.

Zarządy banków stawiają „AI governance” na równi z zarządzaniem ryzykiem finansowym. Powstają dedykowane komitety etyki AI, a audyt algorytmów to standardowa operacyjna procedura.

Scenariusz porażki (Failure mode)

Aby zrozumieć wagę problemu, przeanalizujmy konkretną sytuację. Bank wdraża autonomicznego agenta obsługi klienta od software house’u, który nie zaimplementował odpowiednich barier bezpieczeństwa (guardrails). Agent, poddany manipulacji (wstrzykiwanie promptów), zaczyna oferować produkty na warunkach rażąco niezgodnych z kredytową polityką.

Skutek? Bezpośrednie straty finansowe, konieczność wyłączenia systemu i dotkliwa kara od regulatora za brak nadzoru. Co gorsza, okazuje się, że software house nie posiada polisy OC obejmującej algorytmiczne błędy, co zostawia bank z całym ciężarem odpowiedzialności.

Ekonomia AI: Koszty ukryte (AI FinOps)

Wybór dostawcy AI w 2026 roku to kwestia operacyjnej ekonomii. Modele AI generują ogromne zmienne koszty (liczba tokenów, moc GPU). Banki odrzucają rozwiązania „AI compliant”, które są nieutrzymywalne finansowo. Dostawca musi wdrożyć AI FinOps, wykazując kosztową optymalizację. Przykład: tam, gdzie to technicznie możliwe, zamiast drogich modeli LLM stosuje mniejsze, wyspecjalizowane modele (SLM – Small Language Models), realizujące zadania z tą samą precyzją, ale za ułamek ceny.

Decyzja procurementu: Wymogi bezpieczeństwa AI

W ramach Kryterium #7 software house musi spełnić brzegowe warunki. Brak któregokolwiek dyskwalifikuje dostawcę:

• Audytowalność modeli: Pełna dokumentacja procesu trenowania i działania modeli (zgodność z EU AI Act).
• Bariery bezpieczeństwa AI: Implementacja mechanizmów fizycznie uniemożliwiających agentom AI działanie niezgodne z bankową polityką – niezależnie od treści wpisanej przez użytkownika.
• Risk-adjusted pricing: Przejęcie odpowiedzialności za „halucynacje” modelu i uwzględnienie ryzyka błędnych decyzji agenta w modelu rozliczeń.

Podsumowanie: Nowy archetyp partnera i checklista CIO

Wielka segmentacja rynku: Kto przetrwa rok 2026?

Analiza przecięcia trendów Managed Outcomes, Composable Banking i Agentic AI ujawnia trwałą stratyfikację rynku dostawców IT. Pojęcie „jednego rynku” odeszło do lamusa. Wyłoniły się trzy ligi, a awans z niższej do wyższej staje się coraz trudniejszy. Analiza siedmiu kryteriów pozwala jasno zidentyfikować graczy:

• Grupa 1: Klasyczny body leasing (Dinozaury)Firmy oferujące wynajem specjalistów (Time & Material) bez odpowiedzialności za wynik. Ich jedyny atut – niska stawka w rate card – traci znaczenie. Wymogi DORA i zarządzanie ńańcuchem dostaw sprawiają, że koszt nadzoru nad takimi podmiotami przewyższa oszczędności. Są spychane do prostych utrzymaniowych prac lub roli podwykonawców.
• Grupa 2: Niszowi vendorzy punktowi (Zagrożeni)Dostawcy pojedynczych aplikacji, zagrożeni falą konsolidacji. Banki tną koszty compliance (mniej audytów = taniej), preferując platformy „All-in-One” lub dużych integratorów. Przetrwają tylko ci z unikalnym rozwiązaniem typu „Differentiator” lub perfekcyjną integracją w modelu API-first.
• Grupa 3: Outcome-driven partners (Nowy archetyp)Partnerzy, którzy zmodernizowali biznesowy model: akceptują Managed Outcomes (odpowiedzialność za KPI), posiadają frameworki AI Governance, raportują emisje Scope 3 i działają hybrydowo (integrują SaaS + budują custom IP). To oni są „pierwszym wyborem” (Tier-1 Vendors). Nie konkurują ceną godziny, lecz całkowitym kosztem osiągnięcia rezultatu (Risk-weighted TCO).

Checklista decyzyjna: Weryfikacja nowej rzeczywistości

Dla software house’ów wniosek jest jasny: konieczna jest redefinicja partnerstwa. Dostawca IT staje się integralną częścią systemu odporności banku. Poniższa analiza podsumowuje obszary weryfikowane przez CIO, CPO i risk oficerów.

I. Stabilność i bezpieczeństwo (Brzegowe warunki)

To sito selekcji (knock-out criteria). Brak spełnienia tych wymogów kończy rozmowy.

• [ ] Gotowość DORA: Banki żądają dowodów, nie deklaracji: rejestrów podwykonawców, gotowości do audytu 24h, scenariuszy testów TLPT.
• [ ] Stabilność finansowa: Analiza cashflow w perspektywie 3–5 lat, a nie tylko bieżące przychody.
• [ ] ESG i cyber: Twarde raportowanie Scope 3 oraz polisa cyber insurance na kwoty adekwatne do skali współpracy.

II. Odpowiedzialność biznesowa (Warunek shortlisty)

O wejściu na krótką listę decyduje podejście do ryzyka.

• [ ] Managed outcomes: Marża powiązana z realizacją celów, a nie tylko dostarczeniem godzin.
• [ ] Risk sharing: Klauzule malusowe za krytyczne przestoje.
• [ ] AI governance i zespół: Zgodność z EU AI Act i struktura inżynierowie/management min. 70:30 (eliminacja fasadowych struktur).

III. Architektura i przyszłość (Strategiczne dopasowanie)

O zwycięstwie decyduje długoterminowa wizja.

• [ ] Exit strategy: Dostawca aktywnie wspiera plan wyjścia i transfer IP (work for hire).
• [ ] Metryki DORA: Raportowanie MTTR i Deployment Frequency w rzeczywistym czasie.
• [ ] Modernizacja legacy: Zdolność obsługi mainframe/Cobol przy użyciu nowoczesnych narzędzi AI.

4. Wnioski końcowe: Architekci odporności

Bankowość 2026 przeszła głęboką metamorfozę. Finansowe instytucje to dziś „Architekci Odporności” – zaawansowane organizacje zarządzające złożoną siecią zależności: od mainframe’ów po autonomiczne agenty AI.

Cztery imperatywy dla liderów i ich partnerów IT:

1. Uproszczenie to innowacja: Finansowanie transformacji („Change”) wymaga radykalnego cięcia kosztów utrzymania („Run”) poprzez automatyzację.
2. Konsolidacja dla bezpieczeństwa: DORA wymusza ograniczenie liczby partnerów na rzecz ściślejszej kontroli.
3. Odpowiedzialna autonomia: AI napędza efektywność tylko w ścisłych prawnych ramach.
4. Zrównoważony łańcuch wartości: ESG Scope 3 to twardy parametr biznesowego ryzyka i kosztu kapitału.

Wybór software house’u w 2026 roku nie jest techniczną decyzją. To strategiczna decyzja o odporności organizacji na nadchodzące wstrząsy. Współpraca z podmiotem gotowym na to wyzwanie to warunek przetrwania w nowej rzeczywistości.

Najczęściej zadawane pytania (FAQ)

Jak wybrać najlepszy software house dla bankowości i jakie są kluczowe kryteria selekcji?

Aby wybrać najlepszy software house dla bankowości, szukaj partnera z doświadczeniem w fintech i sektorze finansowym, rozumiejącego regulacje (RODO, PSD2, DORA) i bezpieczeństwo (szyfrowanie, monitoring). Taka firma powinna posiadać solidne referencje na platformach takich jak Clutch czy Google, oferować elastyczne i zintegrowane rozwiązania oraz działać jako partner biznesowy. Kluczowe jest sprawdzenie portfolio z case studies, opinii i zgodności z wymogami regulacyjnymi, a także rozmowa z kilkoma firmami.

Główne kryteria wyboru to:

• Doświadczenie i specjalizacja: sprawdź, czy firma realizowała projekty dla banków lub fintechów (np. core banking, platformy cyfrowe) i czy posiada wiedzę o specyfice branży.
• Zgodność z regulacjami i bezpieczeństwo: upewnij się, że dostawca zna RODO, PSD2, DORA i stosuje zaawansowane szyfrowanie oraz wykrywanie fraudów.
• Referencje i opinie: analizuj wpisy na Clutch.co i dopytaj o zdanie znanych klientów.
• Zrozumienie biznesu: dobry software house pomaga budować przewagę konkurencyjną, a nie tylko dostarcza kod.
• Elastyczność i integracja: szukaj rozwiązań modułowych, które łatwo zintegrować z systemami legacy i które umożliwiają analizę danych.
• Proces i transparentność: porównaj oferty, zwróć uwagę na komunikację i proaktywność w zarządzaniu projektem.

Z jakimi wyzwaniami branży finansowej muszą mierzyć się banki inwestujące w oprogramowanie?

Głównym wyzwaniem branży finansowej jest „Pułapka Efektywności”. Mimo że banki na całym świecie zwiększają budżety IT, ponad 60% środków pochłania utrzymanie starych systemów („Run the Bank”). Oprogramowanie legacy i koszty licencji blokują innowacje. Aby temu zaradzić, firma IT musi wdrożyć agresywną automatyzację, redukując koszty utrzymania poniżej 45% i uwalniając kapitał na innowacyjne rozwiązania. Tworzymy rozwiązania, które pozwalają uciec z tej pułapki poprzez kontrolę długu technicznego.

Jak tworzyć innowacyjne produkty i produkty cyfrowe unikając uzależnienia od dostawcy?

Aby bezpiecznie budować innowacyjne produkty i produkty cyfrowe, banki wdrażają architekturę Composable Banking. Polega ona na łączeniu gotowych modułów (SaaS) poprzez API, co zapewnia dużą elastyczność. Projektowanie w tym modelu wymaga od dostawcy neutralności technologicznej. W obszarach budujących przewagę rynkową (Differentiator), firma musi przekazać bankowi prawa autorskie (IP) i kod źródłowy, unikając ryzyka „Vendor Lock-in 2.0”.

Jakie wymagania stawia branży IT wdrożenie autonomicznej sztucznej inteligencji (Agentic AI)?

Adopcja sztucznej inteligencji w fazie agentowej stawia przed branżą IT rygorystyczne wymogi zgodne z EU AI Act. Firma zajmująca się wdrażaniem AI musi zaimplementować sztywne bariery bezpieczeństwa („Guardrails”) oraz zapewnić audytowalność modeli. Oprogramowanie oparte na AI musi być wytłumaczalne i nadzorowane przez człowieka (Human-in-the-loop). Firma dostarczająca te rozwiązania musi również wdrożyć AI FinOps, aby kontrolować koszty tokenów i mocy obliczeniowej.

Jakie standardy rozwoju oprogramowania są wymagane przez liderów sektora finansowego?

Liderzy sektora finansowego odrzucają rozbudowany management na rzecz struktur inżynierskich. W procesie rozwoju oprogramowania oczekuje się, że 75% zespołu to inżynierowie („doers”). Firma musi wykazać się doskonałością w metrykach DORA: częstotliwości wdrożeń i czasie naprawy (MTTR). Tworzymy rozwiązania z wykorzystaniem automatyzacji testów (min. 80% pokrycia), co gwarantuje wysoką wydajność i jakość kodu przy każdej zmianie, a programiści skupiają się na dostarczaniu wartości.

Czy doświadczenie w technologiach legacy jest nadal kluczowe dla firm obsługujących usługi finansowe?

Tak, doświadczenie w technologiach mainframe jest krytyczne, ponieważ systemy te wciąż przetwarzają miliardy operacji. W obliczu luki demograficznej (wiek ekspertów COBOL >55 lat), firma musi oferować kompleksowe wsparcie obejmujące nie tylko ludzi, ale i narzędzia GenAI do automatycznej refaktoryzacji kodu. Tylko takie podejście pozwala bezpiecznie modernizować oprogramowanie i minimalizować ryzyko operacyjne w świecie finansów.

Jak zmienia się model rozliczeń, aby lepiej realizować potrzeby klientów bankowych?

Aby lepiej zaspokajać potrzeby klientów, rynek odchodzi od modelu Time & Material na rzecz Managed Outcomes. W tym modelu firma specjalizująca się w technologii przejmuje odpowiedzialność za dowiezienie konkretnych KPI biznesowych. Klienci płacą za efekt, a nie za godziny pracy. Wymaga to od dostawcy, aby jego oprogramowanie i usługi były objęte gwarancją jakości, a marża była powiązana z sukcesem wdrożenia i brakiem awarii.

Czy firma realizuje projektowanie aplikacji mobilnych i webowych oraz buduje portfolio klienta?

Tak, w dobie bankowości cyfrowej projektowanie nowoczesnych aplikacji mobilnych i webowych (interfejsów dla „Digital Challengers”) jest kluczowe. Nasza firma tworzy produkty cyfrowe, które realnie budują portfolio własności intelektualnej banku (IP). Dostarczamy dedykowane oprogramowanie w obszarach budujących przewagę („Differentiator”), a każda firma współpracująca z nami zyskuje pewność, że finalne produkty są jej własnością i nie generują długu technologicznego.

Jakie doświadczenie posiada firma w zakresie integracji i czy oferuje doradztwo technologiczne?

Nasza firma posiada udokumentowane doświadczenie w integracji systemów typu „Composable Banking”. Oferujemy strategiczne doradztwo, pomagając klientom bezpiecznie łączyć gotowe moduły SaaS z autorskim kodem. Jako firma odpowiedzialna, dbamy o to, by surowe wymagania regulacyjne były spełnione, a pracownicy banku otrzymali stabilne środowisko pracy. To sprawia, że nasza firma jest bezpiecznym wyborem dla instytucji Tier-1.