Automatyzacja decyzji kredytowych bez utraty kontroli: scoring, reguły i audytowalność

Co warto wiedzieć?

• Nie każda decyzja powinna być automatyczna. Dojrzały proces rozpoznaje sprawy proste oraz te, które wymagają dodatkowych danych lub oceny eksperta. Dobrze zaprojektowana ścieżka manualna decyduje o tym, ile czasu automat naprawdę oszczędza.
• Scoring daje wynik, a reguły określają dalszą ścieżkę wniosku. Sam wynik punktowy nie przesądza, czy sprawa przejdzie automatycznie. Wyjaśnienie decyzji po czasie wymaga zapisania nie tylko wyniku scoringu, ale także zastosowanych reguł i ich wersji.
• Decyzję odtwarza się według warunków obowiązujących w chwili jej wydania. Polityka mogła się od tego czasu zmienić, baza zewnętrzna zwracać inne dane, a model działać w nowej wersji. Dlatego z wnioskiem trzeba powiązać wykorzystane dane, wyniki ocen oraz wersje modeli i reguł.

Automatyzacja decyzji kredytowych nie musi oznaczać utraty kontroli

Najtrudniejszym elementem automatyzacji decyzji kredytowych nie jest uruchomienie silnika, a uporządkowanie tego, co wcześniej było rozproszone po kodzie, systemach i zespołach: jakie dane naprawdę wpływają na ocenę, gdzie zapisane są reguły, kto może je zmienić, kiedy sprawa ma trafić do człowieka i jak później odtworzyć podstawę decyzji.

To właśnie tutaj najłatwiej stracić kontrolę. Pojedynczy wniosek może dostać decyzję w kilka sekund, ale zmiana polityki kredytowej nadal ciągnie się tygodniami, podczas audytu trudno odtworzyć podstawę konkretnego wyniku, a sprawy, których automat nie potrafi rozstrzygnąć, trafiają do kolejki bez jasnego właściciela.

System działa więc szybko na prostej ścieżce — problem zaczyna się, gdy trzeba coś zmienić, obsłużyć wyjątek albo odpowiedzieć audytorowi, compliance czy nadzorowi na pytanie: „dlaczego właśnie taka decyzja?”

W tym artykule pokażę, jak zaprojektować automatyzację decyzji kredytowych tak, żeby przyspieszała proces, ale nie odbierała instytucji kontroli nad regułami, wyjątkami i sposobem, w jaki powstaje decyzja.

Automat nie może decydować o wszystkim

Patrząc na automatyzację przez pryzmat biznesu, KPI i oszczędności, wiele osób zaczyna od pytania: jaki procent decyzji będzie można podejmować bez udziału człowieka?

Nie dziwię się. Tyle że takie uproszczone podejście często generuje problemy, które z czasem zaczynają zjadać potencjalne oszczędności z automatyzacji:

• sprawy nietypowe trafiają do wspólnej kolejki bez jasnego priorytetu,
• analityk nie wie, dlaczego system nie wydał decyzji,
• klient nie dostaje informacji, czego brakuje,
• nie wiadomo, która reguła zatrzymała proces,
• po zmianie polityki trudno wskazać, które wnioski zostały ocenione według jej nowej wersji.

Dlatego w projektach tego typu wolę zacząć od innego pytania: które przypadki jesteśmy w stanie rozstrzygnąć jednoznacznie, a które powinny trafić do człowieka?

Przypadki spełniające jasno określone warunki mogą przechodzić dalej automatycznie. Sprawy nieakceptowalne mogą kończyć się przewidzianym w procesie wynikiem. Pomiędzy nimi pozostaje jednak grupa wniosków, w których brakuje danych, pojawiają się sprzeczne sygnały albo potrzebna jest interpretacja eksperta.

Automatyzacja nie powinna tej grupy ukrywać, ale rozpoznawać ją i kierować do właściwej obsługi.

Ścieżka manualna nie jest więc porażką automatyzacji. W określonych przypadkach stanowi niezbędny element kontrolowanego procesu — zarówno z perspektywy ryzyka, jak i wymagań dotyczących udziału człowieka w zautomatyzowanym podejmowaniu decyzji.

Najtrudniejsze przypadki znajdują się pomiędzy automatem a analitykiem

W jednym z projektów pracowałem z zespołem nad uporządkowaniem procesu sprzedażowego i oceny ryzyka. Sama wizja automatyzacji nie była skomplikowana: proces zbiera dane, uruchamia ocenę i na podstawie wyniku kieruje wniosek dalej.

Najwięcej pytań pojawiło się jednak nie przy prostej ścieżce automatycznej, ale przy wyjątkach:

• Co zrobić, gdy zewnętrzna baza nie odpowie? Czy wniosek powinien czekać, zostać oceniony na podstawie dostępnych informacji czy od razu trafić do analityka?
• Co zrobić, gdy klient spełnia większość warunków, ale brakuje jednego dokumentu?
• Kto powinien dostać sprawę, jeżeli ocena ryzyka kredytowego jest pozytywna, ale inna ścieżka wykryje sygnał wymagający dodatkowej weryfikacji?
• Co zobaczy analityk po otwarciu takiego wniosku? Sam status „do weryfikacji” czy także informację, która ocena zatrzymała sprawę, jakich danych brakuje i co system zdążył już sprawdzić?

To wcale nie są marginalne przypadki, które można dopracować po uruchomieniu automatyzacji. Sposób ich obsługi decyduje o tym, czy proces rzeczywiście przyspiesza pracę, czy tylko przenosi ją do innej kolejki.

Zadaniem dobrze zaprojektowanej ścieżki manualnej jest przekazanie analitykowi całego kontekstu zebranego wcześniej przez system. Człowiek nie powinien zaczynać oceny od odtwarzania historii sprawy, ale od razu wiedzieć:

• dlaczego automat nie podjął decyzji,
• jakie kontrole zostały już wykonane,
• jaki był ich wynik,
• czego jeszcze brakuje,
• jaka czynność jest od niego oczekiwana.

W takim modelu automat nie zastępuje człowieka, ale przygotowuje dla niego sprawę i zdejmuje z niego pracę, która nie wymaga eksperckiej oceny. Proste sprawy nie czekają w tej samej kolejce co wyjątki, analityk szybciej przechodzi do właściwej oceny, a operacje nie muszą prowadzić małego śledztwa za każdym razem, gdy wniosek utknie.

Jedna decyzja może składać się z kilku różnych ocen

Kiedy mówimy „decyzja kredytowa”, łatwo wyobrazić sobie jeden algorytm, który analizuje dane i zwraca wynik: pozytywny albo negatywny. W bardziej złożonych procesach na decyzję może jednak składać się kilka odrębnych ocen, dotyczących na przykład:

• AML,
• ryzyka nadużyć,
• ryzyka kredytowego,
• przedmiotu finansowania.

Każdy z tych obszarów może korzystać z innych danych i odpowiadać na inne pytanie. Ich wyniki są następnie uwzględniane przy ustalaniu dalszej ścieżki wniosku lub decyzji końcowej. Jednym ze sposobów uporządkowania takiego procesu jest zapisywanie wyników poszczególnych ocen jako decyzji cząstkowych, a następnie uwzględnianie ich przy podejmowaniu decyzji zbiorczej.

Dlaczego to rozdzielenie jest ważne?

Ponieważ sam wynik końcowy mówi niewiele. Informacja „wniosek zatrzymany” nie wyjaśnia, czy przyczyną jest profil ryzyka klienta, brak danych, wynik kontroli AML czy problem z oceną przedmiotu.

Jeżeli zapisujemy decyzje cząstkowe, możemy wskazać:

• która ścieżka zakończyła się pozytywnie,
• która zatrzymała proces,
• czy potrzebne są dodatkowe dane,
• czy sprawa wymaga oceny eksperta,
• jak poszczególne wyniki wpłynęły na decyzję zbiorczą.

Dobrze zaprojektowany proces powinien pozwalać ustalić, jakie dane otrzymał system, które reguły zastosował, jakie były wyniki poszczególnych ocen i dlaczego decyzja końcowa była właśnie taka. Ogranicza to czas poświęcany na odtwarzanie przebiegu sprawy, ułatwia obsługę wyjątków i pozwala szybciej wyjaśnić decyzję.

Scoring daje wynik, ale to reguły mówią, co z nim zrobić

Scoring i silnik reguł są czasami traktowane jak dwa określenia tego samego mechanizmu, co łatwo prowadzi do nieporozumień. Model scoringowy może na podstawie dostępnych danych wyliczyć ocenę punktową lub poziom ryzyka, ale sam wynik nie przesądza jeszcze o dalszym przebiegu procesu.

Dopiero reguły określają choćby:

• przy jakim wyniku wniosek może przejść automatycznie,
• kiedy potrzebne są dodatkowe dokumenty,
• kiedy sprawa powinna trafić do analityka,
• jakie znaczenie ma wynik scoringu w połączeniu z pozostałymi ocenami,
• kiedy jedna z decyzji cząstkowych zatrzymuje całość.

W kontrolowanej automatyzacji scoring jest więc jednym z wejść do procesu decyzyjnego, a silnik reguł łączy jego wynik z innymi danymi i warunkami biznesowymi. To właśnie na tej podstawie proces kieruje wniosek dalej, zatrzymuje go albo przekazuje do oceny manualnej.

Dlatego przy automatyzacji nie wystarczy zapisać samego wyniku scoringu. Żeby po czasie wyjaśnić decyzję, trzeba wiedzieć, jakie reguły zadziałały i która ich wersja obowiązywała w momencie oceny wniosku.

Gdy nikt nie wie, gdzie zapisana jest reguła

Skoro to reguły decydują, czy wniosek przejdzie dalej, zostanie zatrzymany albo trafi do analityka, trzeba wiedzieć, gdzie dokładnie są zapisane. Niestety bardzo rzadko odpowiedź brzmi: „w jednym miejscu”.

Zazwyczaj część logiki znajduje się w systemie obsługującym proces, część w integracjach lub scoringu, a inne warunki istnieją tylko w dokumentacji albo wiedzy analityków. Dopóki nic się nie zmienia, taki układ może działać. Problem pojawia się, gdy trzeba zaktualizować jeden warunek albo wyjaśnić decyzję wydaną kilka miesięcy wcześniej.

Nagle trzeba ustalić:

• gdzie dana reguła jest stosowana,
• czy we wszystkich kanałach działa tak samo,
• jaka jej wersja obowiązywała przy konkretnym wniosku,
• jak zmiana wpłynie na resztę procesu.

Dlatego trudniejsze od samego wdrożenia zmiany bywa ustalenie, jaką logikę system rzeczywiście stosuje. Reguły powinny być oddzielone od przebiegu procesu i zarządzane w jednym miejscu. Proces zbiera dane, prowadzi klienta przez kolejne etapy i obsługuje komunikację. Silnik decyzyjny stosuje reguły i kieruje wniosek na odpowiednią ścieżkę.

Reguły można modelować na przykład w notacji DMN i utrzymywać poza kodem procesu. Nie po to, żeby mieć ładny diagram, ale żeby móc sprawdzić, jaka logika obowiązuje, kto ją zmienił i która wersja zadziałała przy konkretnej decyzji.

Zmiana bez kodowania nadal wymaga kontroli

Przeniesienie reguł poza kod ułatwia ich modyfikowanie. To duża wartość, ale również ryzyko: błędny warunek może szybciej trafić do procesu i wpłynąć na kolejne decyzje.

Dlatego każda zmiana nadal powinna mieć właściciela, ocenę wpływu, testy, akceptację i możliwość powrotu do poprzedniej wersji.

W zarządzaniu tym cyklem może pomóc panel administracyjny, który wspiera wersjonowanie, zapisuje historię zmian, pozwala testować reguły na próbce danych i analizować statystyki ich wykonania.

Sam panel nie zapewni jednak kontroli. Pokaże, kto i kiedy wprowadził zmianę, ale nie zdecyduje, kto powinien ją zatwierdzić ani kto odpowiada za jej wpływ na proces. Im łatwiej zmieniać logikę decyzji, tym ważniejsze stają się jasne role i zasady jej publikowania.

Historia decyzji nie może znikać po zmianie reguł

Wersjonowanie reguł i zapisywanie wyników ma wartość tylko wtedy, gdy można je powiązać z konkretnym wnioskiem.

Polityka kredytowa mogła się od tego czasu zmienić, baza zewnętrzna zwracać już inne dane, a model scoringowy działać w nowej wersji.

Audytor nie pyta jednak, jak system oceniłby sprawę dzisiaj. Pytanie brzmi, dlaczego system podjął wtedy właśnie taką decyzję.

Instytucja musi więc zachować informacje potrzebne do odtworzenia podstawy decyzji:

• wykorzystane dane i ich źródła,
• odpowiedzi z zewnętrznych baz danych,
• wyniki poszczególnych ocen,
• wersję modelu scoringowego lub ryzyka,
• wersję zastosowanych reguł decyzyjnych.

Bez takiej ścieżki audytu decyzji zespoły muszą przeglądać logi w kilku systemach i szukać osób, które jeszcze pamiętają, jak proces działał pół roku wcześniej.

Nie oznacza to, że każdy powinien mieć dostęp do pełnej logiki decyzyjnej. Szczegóły modelu scoringowego i reguł nadal wymagają ochrony.

Osoba uprawniona powinna jednak móc wrócić do konkretnego wniosku i odtworzyć sposób podjęcia decyzji bez uruchamiania małego śledztwa.

Klient powinien wiedzieć, co dzieje się z jego wnioskiem

Projektując automatyzację, łatwo skupić się na silniku decyzyjnym, regułach biznesowych i integracjach. Tymczasem po drugiej stronie procesu ktoś czeka na odpowiedź i raczej nie interesuje go, która ścieżka decyzyjna się zatrzymała.

On chce wiedzieć, co dzieje się z jego wnioskiem i czy musi coś zrobić.

Jeżeli automat nie może dokończyć oceny, proces powinien przełożyć przyczynę na jasny komunikat: brakuje dokumentu, potrzebne jest dodatkowe potwierdzenie, sprawę przejął analityk albo proces czeka na odpowiedź z zewnętrznej bazy danych.

Pracownicy rozmawiający z klientem potrzebują tego samego kontekstu. Ogólny status „w trakcie weryfikacji” daje im bardzo niewiele do pracy.

Kontrolowana automatyzacja nie kończy się więc na umiejętności wyjaśnienia decyzji audytorowi. Powinna też sprawiać, że klienci i obsługujący ich pracownicy rozumieją, na jakim etapie jest sprawa.

Jeśli automatyzacja przyspiesza prostą ścieżkę, ale zostawia wyjątki bez jasnego statusu i właściciela, rozwiązuje tylko połowę problemu.

Od doświadczeń projektowych do Altkom Loan Origination

Opisane wyżej sytuacje, wyzwania i pytania nie pochodzą z jednego projektu ani jednego zespołu. Powracały w rozmowach o procesach kredytowych, integracjach, ocenie ryzyka, obsłudze wyjątków i zmianach polityki.

Z czasem złożyły się w spójny obraz: instytucje finansowe chcą automatyzować więcej, ale nie kosztem utraty kontroli nad logiką decyzyjną ani nad tym, co dzieje się dalej z wnioskiem.

Doświadczenie zebrane w zespołach Altkom Software zostało wykorzystane w Altkom Loan Origination. Rozwiązanie wykorzystuje mechanizmy opisane w tym artykule jako część szerszego procesu originacji kredytowej.

• Ocena ryzyka może działać jako jeden z podprocesów, wykorzystując dane z wniosku i źródeł zewnętrznych oraz uruchamiając odpowiednie ścieżki oceny. Ich wyniki wpływają następnie na dalszy krok: automatyczne przejście do kolejnego etapu, wstrzymanie wniosku albo skierowanie go do oceny manualnej.
• Reguły decyzyjne są oddzielone od przebiegu procesu i mogą być zarządzane w silniku decyzyjnym, między innymi z wykorzystaniem notacji DMN. Panel administracyjny wspiera wersjonowanie reguł, ich testowanie, historię zmian i statystyki wykonania.

W ten sposób Altkom Loan Origination rozdziela elementy, które często bywają mieszane: dane i wyniki ocen, logikę decyzyjną oraz proces odpowiedzialny za statusy, komunikację i zadania.

Dzięki temu zmiana reguły nie musi oznaczać przebudowy całego procesu, wyjątek ma określoną dalszą ścieżkę, a ścieżkę audytu decyzji dla konkretnego wniosku można później odtworzyć.

ALO nie zastępuje polityki ryzyka instytucji ani nie decyduje, które sprawy powinny być automatyzowane. Dostarcza jednak mechanizmy potrzebne do świadomego zarządzania automatyzacją decyzji kredytowych: od konfigurowania i testowania reguł biznesowych, przez obsługę wyjątków i ocenę manualną, po odtworzenie podstawy decyzji po czasie.