Sztuczna inteligencja w bankowości: jak testować AI, która wykrywa oszustwa

AI w bankowości to przede wszystkim modele uczenia maszynowego, które w ułamku sekundy oceniają, czy przelew, płatność kartą albo logowanie wygląda na oszustwo, i podpowiadają systemowi decyzję: przepuścić, poprosić o dodatkowe uwierzytelnienie albo zatrzymać. Ten artykuł nie jest kolejną laurką dla sztucznej inteligencji. Pokazujemy, jak taki system przetestować, zanim zablokuje pensję Waszego najlepszego klienta albo przepuści przelew na konto słupa.

Sztuczna inteligencja w bankowości ma dziś dwie twarze. Dla zarządu to obietnica niższych strat. Dla zespołu QA to system, który podejmuje tysiące decyzji na minutę, uczy się na danych, których nikt nie przejrzał wiersz po wierszu, i może się mylić w obie strony. Dlatego pytanie „czy AI działa” zamieniamy na trzy konkretne: ile oszustw łapie, ilu uczciwych klientów przy tym męczy i czy potrafimy to udowodnić audytorowi.

Czym jest AI w bankowości i gdzie naprawdę pracuje przy oszustwach?

W systemach przeciwdziałania oszustwom AI zwykle nie zastępuje reguł, tylko pracuje obok nich. Reguły łapią znane schematy, na przykład przelew na rachunek z listy ostrzeżeń, a model ocenia ryzyko transakcji na tle historii klienta: kwoty, pory dnia, urządzenia, odbiorcy, tempa wpisywania danych. Wynik to liczba, zwykle od 0 do 1, a nad nią stoi próg decyzyjny ustawiony przez bank.

Najczęstsze zastosowania w banku, które spotykamy w rozmowach z zespołami QA z sektora finansowego:

• monitorowanie transakcji w czasie rzeczywistym, czyli ocena ryzyka każdej płatności przed jej realizacją,
• analiza zachowania przy logowaniu i w sesji: urządzenie, lokalizacja, sposób korzystania z aplikacji,
• wykrywanie przejęcia konta po nietypowej sekwencji zdarzeń, na przykład zmiana numeru telefonu i od razu nowy odbiorca przelewu,
• wykrywanie słupów, czyli rachunków, które przyjmują i natychmiast wyprowadzają środki z wielu źródeł,
• priorytetyzacja alertów dla analityków, żeby człowiek patrzył najpierw na przypadki z najwyższym ryzykiem.

Osobną kategorią jest AI w ocenie zdolności kredytowej. To inny system, inne ryzyko i, jak zobaczycie niżej, zupełnie inny reżim prawny. Mieszanie obu tematów to najczęstszy błąd w dyskusjach o „AI w bankowości”.

Jak duża jest skala oszustw płatniczych w Europie i w Polsce?

Według wspólnego raportu Europejskiego Urzędu Nadzoru Bankowego i Europejskiego Banku Centralnego z grudnia 2025 roku wartość oszukańczych płatności w Europejskim Obszarze Gospodarczym wyniosła w 2024 roku 4,2 mld euro, o 17 procent więcej niż rok wcześniej. Ten sam raport EBA i EBC podaje, że oszukańcze polecenia przelewu osiągnęły 2,5 mld euro, a więc wzrosły o 24 procent, a oszustwa kartami wydanymi w UE i EOG 1,3 mld euro.

W Polsce obraz jest podobny, tylko liczony inaczej. Raport roczny CERT Polska za 2025 rok podaje 658 320 zgłoszeń i 260 783 zarejestrowane incydenty, o 152 procent więcej niż w 2024 roku. Według tego samego raportu oszustwa komputerowe stanowiły 97 procent incydentów, a sam phishing to 78 391 przypadków, czyli 30 procent wszystkich zdarzeń.

Dla zespołu testowego najważniejsze zdanie raportu EBA i EBC jest jednak inne: manipulacja płatnikiem odpowiada za ponad połowę wartości oszukańczych przelewów. To oszustwa, w których klient sam, przekonany przez „konsultanta banku” albo „policjanta”, zleca przelew i sam przechodzi silne uwierzytelnienie. Dla modelu AI to trudny przypadek, bo wszystkie techniczne sygnały są poprawne: właściwe urządzenie, właściwy PIN, właściwy klient.

Jak działa system wykrywania oszustw oparty na sztucznej inteligencji?

Typowy system antyfraudowy, czyli najczęstsze dziś wdrożenie AI w bankowości, to łańcuch kilku kroków, z których każdy można i trzeba przetestować osobno. Dane o transakcji trafiają do warstwy cech, gdzie powstają zmienne w rodzaju „liczba przelewów do nowych odbiorców w ostatniej godzinie”. Potem reguły biznesowe, model, próg decyzyjny i na końcu akcja: przepuszczenie, żądanie silnego uwierzytelnienia, wstrzymanie do weryfikacji przez analityka albo odrzucenie.

Z naszego doświadczenia najwięcej defektów nie siedzi w samym modelu, tylko na stykach: w warstwie cech liczonej inaczej na produkcji niż w środowisku treningowym, w strefach czasowych, w zaokrągleniach kwot i w tym, co system robi, gdy model nie odpowie w wymaganym czasie. Jeśli testujecie wyłącznie model, testujecie mniejszą część systemu.

Co o systemach antyfraudowych mówią PSD2, AI Act, DORA i KNF?

Tu potrzebna jest precyzja, bo w tym obszarze krąży dużo uproszczeń. Każdy akt poniżej podajemy z artykułem i linkiem do tekstu urzędowego. Artykuł opisuje wymogi z perspektywy testów, nie jest poradą prawną, a o kwalifikacji konkretnego systemu decyduje Wasz dział prawny i compliance.

Referencyjne wskaźniki oszustw z załącznika do rozporządzenia 2018/389 są bardzo konkretne: dla zdalnych płatności kartą wynoszą 0,13 procent przy progu 100 euro, 0,06 procent przy 250 euro i 0,01 procent przy 500 euro, a dla zdalnych przelewów 0,015, 0,01 i 0,005 procent. To liczby, które zespół testowy może i powinien zamienić na asercje w testach akceptacyjnych logiki zwolnień.

Co z wytycznymi KNF? Na stronie Komisji Nadzoru Finansowego z rekomendacjami dla banków, sprawdzonej przez nas 10.10.2026, nie ma już Rekomendacji D, która przez lata porządkowała zarządzanie IT w bankach. Punktem odniesienia dla testów systemów ICT jest dziś przede wszystkim DORA, a aktualne dokumenty nadzorcze warto czytać bezpośrednio na stronie KNF z rekomendacjami dla banków. Szerzej o samym AI Act i o terminach dla systemów wysokiego ryzyka piszemy w artykule AI Act: obowiązki testowania systemów wysokiego ryzyka, a o DORA w tekście rozporządzenie DORA a testy niezależne.

Jak testować AI w bankowości, która wykrywa oszustwa?

AI w bankowości testujecie na czterech poziomach: dane, model, integracja i proces. Pominięcie któregokolwiek kończy się zwykle tym samym: model ma piękne wyniki w notatniku analityka, a na produkcji blokuje klientów w poniedziałek rano, bo w weekend zmienił się format pola z kwotą.

Dane syntetyczne to temat sam w sobie. Kopiowanie produkcji do środowiska testowego w banku to proszenie się o kłopoty z RODO i z audytem, co dobrze opisuje Strefa QA w tekście o danych testowych i GDPR. Zbiór syntetyczny ma jeszcze jedną zaletę: znacie w nim prawdę, bo sami ją zaprojektowaliście. Możecie wstrzyknąć sto przypadków przejęcia konta i sprawdzić, ile z nich model wyłapie.

Druga rzecz to testy stronniczości. Nawet jeśli Wasz model antyfraudowy nie jest systemem wysokiego ryzyka w rozumieniu AI Act, warto sprawdzić, czy odsetek fałszywych alarmów nie jest wyraźnie wyższy dla jednej grupy klientów, na przykład seniorów, osób korzystających ze starszych telefonów albo klientów z kont w innej walucie. Taki wynik to zwykle sygnał, że model nauczył się skrótu zamiast schematu oszustwa.

Trzecia to testy w cieniu (shadow mode). Nowa wersja modelu przez kilka tygodni ocenia prawdziwy ruch, ale jej decyzje nie są wykonywane, tylko porównywane z decyzjami wersji produkcyjnej. Dopiero gdy różnice są wyjaśnione, przełączacie ruch. To nudne, powolne i najskuteczniejsze zabezpieczenie przed wdrożeniem, którego nie da się szybko wycofać. Jeśli budujecie takie testy pierwszy raz, pomoże usługa testowania systemów AI, a zespołowi, który chce przejść przez to samodzielnie, praktyczne szkolenie z testowania AI dla testerów.

Ogólne zasady testowania systemów uczących się, od wyroczni testowej po testy metamorficzne, zebraliśmy w artykule testowanie systemów AI: jak zapewnić jakość. Tutaj skupiamy się na tym, co specyficzne dla banku: koszt każdej pomyłki jest policzalny, a każdą decyzję trzeba umieć wyjaśnić.

Jakie metryki pokazać zarządowi, zanim model trafi na produkcję?

Skuteczność modelu antyfraudowego mierzy się co najmniej trzema liczbami naraz. Sama „trafność” jest bezużyteczna, bo przy oszustwach stanowiących ułamek procenta transakcji model, który nie blokuje niczego, ma trafność powyżej 99 procent. Z drugiej strony model, który blokuje wszystko, łapie sto procent oszustw i ma przy tym zero klientów, co też trudno nazwać sukcesem.

Poniżej krótki skrypt w Pythonie, który liczy te metryki dla dwóch progów decyzyjnych na zbiorze testowym. Liczby w przykładzie są ilustracyjne, ale pokazują typowy kompromis: wyższy próg zmniejsza liczbę fałszywych alarmów ponad trzykrotnie, za to przepuszcza więcej oszustw.

from dataclasses import dataclass


@dataclass
class Wynik:
    tp: int  # oszustwo zablokowane
    fp: int  # uczciwa transakcja zablokowana
    fn: int  # oszustwo przepuszczone
    tn: int  # uczciwa transakcja przepuszczona


def metryki(w: Wynik) -> dict:
    precyzja = w.tp / (w.tp + w.fp)
    czulosc = w.tp / (w.tp + w.fn)
    fpr = w.fp / (w.fp + w.tn)
    return {
        "precyzja": round(precyzja, 3),
        "czulosc (recall)": round(czulosc, 3),
        "false positive rate": round(fpr, 5),
        "fałszywe alarmy na 1 trafienie": round(w.fp / w.tp, 1),
    }


# Zbiór testowy: 200 000 transakcji, w tym 400 oznaczonych jako oszustwo
for prog, w in {0.5: Wynik(tp=320, fp=2400, fn=80, tn=197200),
                0.8: Wynik(tp=260, fp=600, fn=140, tn=199000)}.items():
    print(prog, metryki(w))

Wynik: przy progu 0,5 model łapie 80 procent oszustw, ale na jedno trafienie przypada 7,5 fałszywego alarmu. Przy progu 0,8 łapie 65 procent, a fałszywych alarmów jest 2,3 na trafienie. Wybór progu to decyzja biznesowa, nie techniczna, i właśnie dlatego zespół QA powinien przynosić na spotkanie tabelę z kilkoma progami, a nie jedną liczbę. W naszych projektach dla sektora regulowanego, takich jak strategia jakości i audyt procesów QA w PKO BP, widzimy, że najwięcej czasu oszczędza wspólny słownik: kiedy dział ryzyka, IT i biznes mówią „skuteczność”, muszą mieć na myśli tę samą metrykę.

Czego sztuczna inteligencja w bankowości nie załatwi?

AI nie zastąpi trzech rzeczy. Pierwsza to człowiek przy decyzjach granicznych. Model ma podpowiadać, a analityk z dostępem do kontekstu decyduje o przypadkach, w których stawka jest wysoka. Druga to edukacja klientów: skoro według raportu EBA i EBC ponad połowa wartości oszukańczych przelewów pochodzi z manipulacji płatnikiem, żaden model nie wyłapie wszystkich przelewów, które klient zleca w pełni świadomie, tylko pod wpływem kłamstwa.

Trzecia to bezpieczeństwo samego systemu. Każde wdrożenie AI w bankowości dokłada nową powierzchnię ataku: model, cechy i dane treningowe. Ktoś, kto pozna logikę progów, będzie dzielił kwoty tak, by się pod nie zmieścić. Testy bezpieczeństwa aplikacji bankowej obejmują więc także API modelu i panel analityka. W tym zakresie wspiera Was zespół od testów bezpieczeństwa i testów penetracyjnych, a o tym, jak wygląda podejście do testów w organizacji regulowanej, piszemy w artykule audyt QA w sektorze regulowanym na przykładzie PKO BP.

Na koniec uczciwie o granicach: żaden zestaw testów nie gwarantuje, że system nie przepuści oszustwa ani że nie zablokuje uczciwej płatności. Dobre testy dają coś innego: wiedzę, jak często się myli, w którą stronę i ile to kosztuje. Z tą wiedzą da się świadomie ustawić próg, a nie zgadywać.

Powiązane na blogu Quality Island

• AI Act: obowiązki testowania systemów wysokiego ryzyka
• Rozporządzenie DORA a testy: kto musi, jak często i dlaczego niezależnie
• Testowanie systemów AI: jak zapewnić jakość
• Audyt QA w sektorze regulowanym: co pokazuje case PKO BP
• Testy bezpieczeństwa i testy penetracyjne: co sprawdzają i jak je zaplanować

Pełna lista źródeł

• EBA i EBC, Joint EBA ECB report on payment fraud, komunikat prasowy, grudzień 2025. Stąd 4,2 mld euro, wzrost o 17 procent i udział manipulacji płatnikiem.
• EBA i EBC, 2025 Report on payment fraud, pełny raport PDF, 2025. Stąd 2,5 mld euro oszustw w przelewach, 1,3 mld euro w kartach i wskaźniki oszustw 0,002 i 0,033 procent.
• CERT Polska, NASK, Raport roczny 2025 z działalności CERT Polska, 2026. Stąd 658 320 zgłoszeń, 260 783 incydenty, 97 procent oszustw i 78 391 przypadków phishingu.
• Komisja Europejska, Dziennik Urzędowy UE, Rozporządzenie delegowane (UE) 2018/389, regulacyjne standardy techniczne silnego uwierzytelniania klienta, 2018. Art. 2, art. 18 i załącznik z referencyjnymi wskaźnikami oszustw.
• Parlament Europejski i Rada UE, Rozporządzenie (UE) 2024/1689 w sprawie sztucznej inteligencji (AI Act), 2024. Art. 6, art. 10 i załącznik III pkt 5 lit. b.
• Parlament Europejski i Rada UE, Rozporządzenie (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego (DORA), 2022. Art. 24, 25 i 26.
• Komisja Nadzoru Finansowego, Rekomendacje dla banków, stan na 10.10.2026.