Dla dyrektora ryzyka scoring nie jest ćwiczeniem analitycznym, tylko dźwignią, która przekłada się wprost na koszty ryzyka, na poziom akceptacji wniosków i na to, czy portfel wytrzyma gorszy cykl. Dobrze zbudowany scoring kredytowy pozwala podejmować decyzje szybciej, taniej i powtarzalnie, a przy tym obronić je przed audytem wewnętrznym i regulatorem. Problem rzadko leży w samym algorytmie, znacznie częściej w danych, w procesie wokół modelu i w tym, kto potrafi to utrzymać przez lata.
Z naszego doświadczenia najtrudniejsze w tych projektach jest połączenie trzech światów naraz: inżynierii danych, modelowania ryzyka i zgodności. W obszarze scoringu nie prowadzimy własnego gotowego wdrożenia, które moglibyśmy pokazać jako referencję, natomiast dostarczamy coś równie konkretnego: ludzi i kompetencje, którzy takie rozwiązania budują. Łączymy inżynierów danych i specjalistów AI/ML z Grupy RITS (nasze zespoły AI/Data wyspecjalizowane w danych i uczeniu maszynowym) z naszym doświadczeniem w projektach dla sektora finansowego.
Po co w ogóle scoring kredytowy i ocena ryzyka?
Ocena ryzyka porządkuje decyzję, która inaczej jest uznaniowa i trudna do obrony. Zamiast opierać się na wyczuciu analityka, sprowadzamy ryzyko klienta do mierzalnej, powtarzalnej wartości i dopiero na niej budujemy politykę kredytową. Bank zyskuje wtedy kilka rzeczy naraz: krótszy czas decyzji, spójność między oddziałami i kanałami, czytelny ślad audytowy oraz możliwość sterowania apetytem na ryzyko progami odcięcia. To właśnie ta powtarzalność, a nie wynik pojedynczej decyzji, robi różnicę w skali portfela.
Jakie dane wejściowe zasilają modele scoringowe i co z ich jakością?
Scoring jest dokładnie tak dobry, jak dane, na których się uczy i działa. Zanim ktokolwiek dotknie modelu, układamy warstwę danych, bo to w niej kryje się większość późniejszych problemów. W praktyce pracujemy z kilkoma typami źródeł:
- dane wewnętrzne banku - historia rachunków, transakcji, spłat i zaległości,
- dane z zewnętrznych rejestrów - biura informacji kredytowej i gospodarczej,
- dane behawioralne i aplikacyjne - zachowanie w kanałach cyfrowych, dane z wniosku,
- dane makro i sektorowe - kontekst, w którym portfel się porusza.
Największe ryzyko to nie brak danych, tylko ich niespójność, luki i ciche zmiany definicji między systemami. Dlatego budujemy kontrolę jakości, słownik cech i monitoring kompletności jako element rozwiązania, a nie dodatek po fakcie. Model wytrenowany na zanieczyszczonych danych wygląda dobrze na papierze, a zawodzi w produkcji.
Modele reguł czy uczenie maszynowe, i co z wyjaśnialnością?
To nie jest wybór zero-jedynkowy. Reguły biznesowe dają pełną kontrolę i natychmiastową interpretowalność, więc świetnie sprawdzają się w twardych politykach i odcięciach regulacyjnych. Modele ML, z kolei, wychwytują zależności, których nie zapiszemy ręcznie, i zwykle podnoszą jakość różnicowania klientów. W projektach scoringowych najczęściej łączymy oba podejścia: warstwę regułową dla twardych warunków i model statystyczny lub ML tam, gdzie decyduje jakość predykcji.
Kluczowa jest przy tym wyjaśnialność. W kredytach decyzja musi być uzasadniona wobec klienta i nadzoru, więc stawiamy na modele i narzędzia, które pokazują, dlaczego klient dostał taki, a nie inny wynik. W praktyce oznacza to przejrzyste scorecardy, a tam gdzie wchodzi ML, techniki typu SHAP i jasny opis cech. Model, którego nie da się wytłumaczyć, jest w tym obszarze ryzykiem, a nie przewagą.
Jak walidować i monitorować modele scoringowe po wdrożeniu?
Model nie jest projektem, który się kończy, tylko systemem, który żyje. Portfel się zmienia, zachowania klientów dryfują, a dobry rok potrafi uśpić czujność tuż przed gorszym. Dlatego traktujemy walidację i monitoring jako stały proces, nie jednorazowy odbiór. W tej warstwie zwykle pilnujemy:
- jakości różnicowania (Gini, KS, AUC) na danych out-of-time, a nie tylko treningowych,
- stabilności populacji i cech (PSI) w czasie,
- zgodności predykcji z realizacją (kalibracja, backtesting),
- progów alertów, które z wyprzedzeniem sygnalizują degradację modelu.
Projektujemy to tak, żeby zespół ryzyka widział kondycję modeli na bieżąco i miał twarde przesłanki do retrainingu, zanim pogorszenie uderzy w koszty ryzyka.
Jak zapanować nad zgodnością, biasem i nadzorem człowieka?
Scoring działa na danych o ludziach, więc zgodność i etyka nie są dodatkiem, tylko warunkiem brzegowym. Dbamy o to, żeby model nie opierał się na cechach wrażliwych ani na ich ukrytych reprezentantach, i testujemy go pod kątem biasu wobec grup klientów. Równolegle utrzymujemy pełną dokumentację: skąd wzięły się dane, jak powstał model, jak był walidowany, bo to ona przechodzi przez audyt.
Osobno projektujemy człowieka w pętli decyzyjnej. Automat rekomenduje i odcina oczywiste przypadki, ale decyzje graniczne i odmowy wymagające uzasadnienia zostawiamy ekspertowi, z czytelnym kontekstem na ekranie. Taki układ łączy tempo automatu z odpowiedzialnością, której oczekuje nadzór.
Jak wpiąć scoring w proces kredytowy i systemy banku?
Najlepszy model nie da wartości, dopóki nie jest częścią realnego procesu decyzyjnego. Dlatego patrzymy na scoring end-to-end: od wniosku, przez silnik decyzyjny, po systemy core i raportowanie. Udostępniamy model jako usługę z API, tak żeby decyzja zapadała w czasie liczonym w milisekundach i wracała do procesu wraz z uzasadnieniem. Spinamy go z silnikiem reguł, z systemem wnioskowym i z hurtownią danych, dbając o wersjonowanie modeli i pełny zapis każdej decyzji. Celem jest jedno: żeby scoring był powtarzalnym elementem procesu, a nie arkuszem uruchamianym z boku.
Jakie kompetencje dostarczamy do projektu scoringowego?
Dobieramy skład pod konkretny etap i lukę w zespole, a nie „na zapas”. W projektach z obszaru danych i ryzyka obsadzamy zwykle takie role:
- inżynierowie danych - budują warstwę danych, pipeline’y i kontrolę jakości,
- data scientist / specjaliści ML - projektują, trenują i walidują modele,
- inżynierowie MLOps / DevOps - wdrażają modele i monitoring na produkcji,
- programiści backend - spinają scoring z silnikiem decyzyjnym i systemami banku.
Taki zespół pracuje w modelu wzmocnienia zespołu lub zespołu dedykowanego, pod Twoim nadzorem i w Twoich ramach zgodności, uzupełniając kompetencje dokładnie tam, gdzie ich brakuje.
Jak robimy to w RITS?
Robimy to jako partner nearshore z Polski, który łączy kompetencje danych i AI z doświadczeniem w sektorze finansowym. Nie sprzedajemy gotowego „pudełka” ze scoringiem, bo dobry scoring zawsze jest szyty pod portfel, politykę i dane konkretnego banku. Zamiast tego obsadzamy role i współtworzymy rozwiązanie razem z Twoim zespołem ryzyka: inżynierowie danych z Grupy RITS i specjaliści AI/ML (nasze zespoły AI/Data) budują warstwę danych i modele, a my dbamy o wyjaśnialność, walidację i wpięcie w proces. Kompetencje weryfikujemy przed startem, a bliska strefa czasowa sprawia, że zespół wchodzi w przeglądy i spotkania bez długiego rozruchu.
Od czego zacząć budowę scoringu i oceny ryzyka?
Zacznij od jednej decyzji kredytowej i jej danych, a nie od wyboru algorytmu. Ustal, co dokładnie chcesz przewidywać (np. ryzyko defaultu w danym produkcie), jakie dane realnie masz i w jakiej jakości, oraz jak decyzja ma wpiąć się w proces i nadzór. To wyznacza zakres modelu, wymagania walidacyjne i role, których potrzebujesz. Jeśli zastanawiasz się, w jakiej formie najlepiej dobrać do tego zespół, porównanie znajdziesz w artykule o modelach współpracy IT.
Budujesz scoring kredytowy albo odnawiasz ocenę ryzyka klienta? Porozmawiajmy, dobierzemy zespół i podejście pod Twój portfel i wymogi nadzoru.