Cyfryzacja procesu kredytowego end-to-end – jak połączyć wniosek, decyzję, dane i obsługę klienta?

Na czym polega cyfryzacja procesu kredytowego end-to-end?

Cyfryzacja procesu kredytowego nie kończy się na zastąpieniu papierowego wniosku formularzem internetowym. Oznacza zaprojektowanie połączonego procesu, w którym informacje przechodzą między systemami bez zbędnego ręcznego przepisywania, a każdy etap ma określonego właściciela, status i reguły obsługi.

Warto rozróżnić trzy poziomy automatyzacji:

• Cyfrowy kanał: klient składa wniosek i dostarcza dokumenty online.
• Automatyzacja operacyjna: systemy walidują dane, uruchamiają integracje, tworzą zadania i przekazują wniosek między etapami.
• Automatyzacja decyzji: wybrane wnioski mogą być rozstrzygane zgodnie z zatwierdzonymi regułami i modelami ryzyka.

To nie są pojęcia zamienne. Bank może znacząco usprawnić obsługę, automatyzując pobieranie danych i obieg dokumentów, a jednocześnie pozostawiając złożone przypadki analitykom. Z drugiej strony nawet szybka decyzja kredytowa przynosi ograniczoną korzyść, jeżeli przygotowanie umowy lub uruchomienie kredytu nadal wymaga ręcznej pracy.

Docelowa architektura powinna obsługiwać zarówno straight-through processing (STP), czyli przetwarzanie bez interwencji pracownika, jak i przypadki wymagające analizy manualnej. Brak dokumentów, niejednoznaczne dane czy awaria integracji powinny prowadzić do zdefiniowanej ścieżki workflow, a nie do obsługi sprawy poza systemem.

Korzyść dla CTO: jasny zakres projektu i możliwość ograniczenia kosztownych przekazań danych między systemami zamiast wdrażania kolejnego odizolowanego narzędzia.

Jakie etapy procesu kredytowego trzeba ze sobą połączyć?

Proces kredytowy obejmuje znacznie więcej niż przyjęcie wniosku i wydanie decyzji. Każde przejście między etapami może powodować opóźnienia, utratę kontekstu lub błędy integracyjne.

Wąskie gardła często powstają między systemami, nie wewnątrz nich. Wniosek może zostać poprawnie zapisany w LOS, ale nie trafić do oceny ryzyka z powodu błędnego mapowania identyfikatora klienta. Decyzja może być gotowa, podczas gdy umowa czeka w osobnym systemie dokumentowym.

Dlatego pierwszym zadaniem architektonicznym powinno być mapowanie przepływów informacji, zależności i odpowiedzialności w całym procesie.

Jak zaprojektować architekturę cyfrowego procesu kredytowego?

Centralnym elementem rozwiązania jest często Loan Origination System (LOS), wspierający przyjmowanie i rozpatrywanie wniosków. W zależności od istniejącej infrastruktury LOS może zarządzać workflow samodzielnie lub współpracować z dedykowanym silnikiem orkiestracji procesów.

Orkiestrator powinien znać aktualny etap wniosku, wymagane działania, terminy, wyniki integracji i warunki przejścia między statusami. Nie powinien natomiast zastępować wszystkich systemów domenowych ani przejmować niekontrolowanie ich danych.

Schemat architektury end-to-end

Jeden wniosek, wiele systemów

Każdy wniosek powinien otrzymać trwały identyfikator biznesowy, który łączy jego historię w kanale klienta, LOS, CRM, silniku decyzyjnym i systemach dokumentowych. Poszczególne aplikacje mogą zachować własne identyfikatory techniczne, ale ich mapowanie musi być jednoznaczne.

Równie ważny jest spójny model statusów. Status „w trakcie analizy” musi mieć określone znaczenie dla klienta, doradcy i zespołu operacyjnego. Wewnętrzne stany techniczne, takie jak oczekiwanie na odpowiedź API, nie muszą być bezpośrednio prezentowane klientowi.

Procesy długotrwałe wymagają obsługi błędów

Wniosek kredytowy może pozostawać otwarty przez kilka dni. Klient dosyła dokumenty, zewnętrzne źródło danych jest chwilowo niedostępne, a analityk prosi o wyjaśnienie. Workflow musi obsługiwać timeouty, kontrolowane ponowienia, terminy zadań, eskalacje i wznowienie procesu.

W operacjach zmieniających stan finansowy niezbędne są mechanizmy idempotencji i uzgadniania statusów. Ponowienie dyspozycji po timeoutcie nie może prowadzić do podwójnego uruchomienia kredytu.

Integracja z istniejącym core bankingiem nie musi oznaczać wymiany platformy. Możliwe podejścia obejmują stabilne API, adaptery i stopniowe wydzielanie funkcji, przy zachowaniu kontroli nad systemem źródłowym.

Jak integrować dane i systemy wykorzystywane w ocenie kredytowej?

Ocena kredytowa wykorzystuje informacje z wielu źródeł: dane podane przez klienta, historię relacji z bankiem, istniejące zobowiązania, dane od uprawnionych dostawców oraz dokumenty opisujące sytuację finansową wnioskodawcy.

Wyzwaniem nie jest samo pobranie informacji. Bank musi wiedzieć, skąd pochodzą dane, kiedy zostały pozyskane, czy są aktualne i czy można je zgodnie z prawem wykorzystać do określonego celu. Bez tych kontroli automatyzacja może jedynie przyspieszyć rozpowszechnianie błędnych informacji.

Jakość danych przed automatyzacją

Warstwa integracyjna powinna sprawdzać pola wymagane, formaty, identyfikatory i duplikaty. Brak danych należy odróżnić od negatywnego wyniku weryfikacji. Jeżeli zewnętrzny dostawca jest niedostępny, system nie powinien automatycznie traktować tego jako niespełnienia kryteriów kredytowych.

Trzeba też określić system of record, czyli źródło prawdy dla poszczególnych kategorii danych. CRM może odpowiadać za część informacji kontaktowych, LOS za status procesu, a core banking za stan uruchomionego produktu. Właściciel danych może być różny w zależności od domeny, ale odpowiedzialność musi być jasna.

Open Banking jako dodatkowe źródło informacji

W odpowiednich przypadkach dane o rachunkach i transakcjach, pozyskiwane przez uprawnione usługi Open Banking, mogą wspierać ocenę sytuacji finansowej klienta. Taka integracja wymaga właściwej podstawy prawnej, uprawnień, bezpiecznych interfejsów oraz kontroli zakresu i jakości danych.

Sam dostęp do informacji finansowych nie oznacza automatycznie prawa do ich wykorzystania w dowolnym celu. Bank musi uwzględnić przeznaczenie danych, obowiązki informacyjne, retencję i zasady dotyczące decyzji kredytowych.

Więcej o warstwach integracyjnych i odpowiedzialności komponentów opisujemy w materiale dotyczącym architektury Open Banking. Adres artykułu należy potwierdzić w CMS przed publikacją.

Jak automatyzować decyzje kredytowe bez utraty kontroli nad ryzykiem?

Automatyzacja procesu kredytowego nie oznacza automatycznego zatwierdzania wszystkich wniosków. Dobrze zaprojektowana architektura oddziela automatyzację czynności operacyjnych, rekomendacje systemów decyzyjnych i formalną decyzję kredytową.

Silnik reguł biznesowych może sprawdzać kompletność wniosku, kryteria produktowe i warunki przekazania sprawy do kolejnego etapu. Scoring oraz modele ryzyka dostarczają danych do oceny. Credit decision engine może stosować zatwierdzone polityki i kierować wniosek do odpowiedniej ścieżki workflow.

Trzy kontrolowane ścieżki obsługi

• Ścieżka automatyczna: dane są kompletne, przypadek spełnia zatwierdzone kryteria i może przejść dalej bez ręcznej interwencji.
• Analiza manualna: analityk ocenia niejednoznaczne dane, wyjątek produktowy lub przypadek wymagający indywidualnej decyzji.
• Uzupełnienie informacji: workflow zatrzymuje się w określonym stanie i umożliwia klientowi dostarczenie brakujących danych.

Odmowa jest odrębnym wynikiem biznesowym i wymaga obsługi zgodnej z właściwymi przepisami oraz zasadami komunikacji z klientem. Awaria integracji nie może zostać po cichu zamieniona na negatywną decyzję kredytową.

Każda decyzja lub rekomendacja powinna być powiązana z wersją zastosowanych reguł, wykorzystanymi danymi, wynikami modeli i ścieżką zatwierdzenia. Umożliwia to odtworzenie przebiegu sprawy, analizę incydentów i kontrolowane zmiany polityki kredytowej.

Gdzie może pomóc AI?

AI może wspierać klasyfikację dokumentów, ekstrakcję informacji, wykrywanie braków i priorytetyzację spraw do analizy. Każde zastosowanie wymaga oceny jakości wyników, bezpieczeństwa danych i skutków potencjalnych błędów.

Systemy AI wykorzystywane do oceny zdolności kredytowej lub ustalania scoringu osób fizycznych mogą podlegać szczególnym wymaganiom AI Act. Zależnie od przypadku architektura może wymagać dodatkowych kontroli ryzyka, dokumentacji, nadzoru człowieka i audytowalności.

AI nie powinno być traktowane jako automatyczny zamiennik zarządzania ryzykiem kredytowym. Szybszy wynik modelu ma wartość tylko wtedy, gdy bank potrafi go zweryfikować, monitorować i odpowiednio wyjaśnić jego rolę w procesie.

Jak połączyć proces kredytowy z obsługą klienta?

Klient nie powinien znać granic między LOS, CRM, systemem dokumentowym i core bankingiem. Powinien otrzymywać spójne informacje o statusie, czytelne powiadomienia i możliwość kontynuowania wniosku w dostępnym kanale bez wielokrotnego podawania tych samych danych.

Kluczowe jest rozdzielenie statusu biznesowego od technicznego. Komunikat „oczekujemy na dokument” powinien wynikać z rzeczywistego stanu workflow, a nie z lokalnej interpretacji aplikacji mobilnej. Doradca musi widzieć ten sam kontekst sprawy co system operacyjny, w zakresie wynikającym z jego uprawnień.

CRM nie musi przechowywać pełnej kopii procesu. Może korzystać z odpowiedniego widoku danych i statusów udostępnianego przez LOS lub warstwę integracyjną. Ważne, aby wskazać źródło autorytatywnego statusu i kontrolować opóźnienia synchronizacji.

Powiadomienia powinny być wyzwalane przez potwierdzone zdarzenia biznesowe, a nie przez samą próbę wywołania API. Informacja „kredyt uruchomiony” powinna zostać wysłana dopiero po potwierdzeniu odpowiedniego stanu przez właściwy system.

Po zakończeniu procesu niezbędne dane muszą trafić do obsługi posprzedażowej. Bez tego klient może posiadać aktywny produkt, podczas gdy konsultant nie ma kontekstu jego uruchomienia.

Efekt biznesowy: mniej ręcznych zapytań o status, mniej ponownego wprowadzania danych i bardziej spójna obsługa w różnych kanałach.

Jak zapewnić bezpieczeństwo, zgodność i audytowalność procesu kredytowego?

Proces kredytowy obejmuje dane osobowe i finansowe, a jego wynik może istotnie wpływać na sytuację klienta. Bezpieczeństwo i zgodność regulacyjna muszą być częścią projektu architektury, a nie zadaniem realizowanym dopiero przed wdrożeniem produkcyjnym.

Kontrola dostępu i ochrona danych

Uprawnienia powinny wynikać z ról biznesowych i uzasadnionych potrzeb operacyjnych. Architektura powinna obejmować odpowiednie uwierzytelnianie, autoryzację, szyfrowanie transmisji i danych, zasady retencji oraz monitorowanie dostępu do informacji wrażliwych.

Projektowanie API musi uwzględniać ryzyka takie jak nieprawidłowa autoryzacja dostępu do obiektów, nadmierne ujawnianie danych czy błędne zarządzanie uprawnieniami. Każdy system powinien otrzymywać tylko informacje potrzebne do realizacji swojej funkcji.

Ślad audytowy decyzji

Dla każdego wniosku bank powinien móc ustalić, jakie dane wykorzystano, którą wersję reguł lub modelu uruchomiono, kto wykonał czynność manualną i co wydarzyło się na poszczególnych etapach. Rejestry audytowe wymagają odpowiedniej ochrony, a okresy przechowywania powinny wynikać z obowiązujących wymagań.

RODO, DORA, AI Act i wymagania kredytowe

RODO określa zasady zgodnego z prawem przetwarzania danych osobowych, w tym przepisy dotyczące decyzji opartych wyłącznie na zautomatyzowanym przetwarzaniu, jeżeli wywołują skutki prawne lub podobnie istotnie wpływają na osobę. W określonych sytuacjach zastosowanie mają dodatkowe zabezpieczenia i prawa osoby, której dane dotyczą.

DORA ustanawia wymagania dotyczące odporności operacyjnej ICT dla podmiotów finansowych objętych zakresem regulacji. AI Act może nakładać dodatkowe obowiązki na określone systemy AI służące ocenie zdolności kredytowej lub ustalaniu scoringu osób fizycznych. Należy też uwzględnić właściwe regulacje kredytowe i wytyczne nadzorcze, w tym odpowiednie wytyczne EBA.

Dokładny zakres obowiązków zależy od produktu, rynku, instytucji i sposobu podejmowania decyzji. Wdrożenie produkcyjne wymaga współpracy z zespołami prawnymi, compliance i ryzyka kredytowego.

Jak wdrażać automatyzację procesu kredytowego etapami?

Jednoczesna przebudowa wszystkich produktów kredytowych, kanałów i systemów zwiększa złożoność projektu. Bezpieczniejszym podejściem jest wybór ograniczonego zakresu, dostarczenie kompletnego przepływu i rozszerzanie rozwiązania po potwierdzeniu rezultatów.

1. Zmapuj obecny proces. Zidentyfikuj ścieżki wniosków, ręczne przekazania danych, źródła informacji i miejsca, w których status staje się niejednoznaczny.
2. Wybierz pierwszy produkt. Określ zakres z jasnymi regułami kwalifikacji i znanymi wymaganiami integracyjnymi.
3. Zdefiniuj model procesu. Ustal identyfikatory wniosków, statusy, odpowiedzialność za dane, reguły przejść i obsługę wyjątków.
4. Zbuduj integracje. Połącz kanał klienta, LOS, CRM, źródła danych, decision engine, DMS i core banking przez kontrolowane interfejsy.
5. Automatyzuj czynności powtarzalne. Rozpocznij od walidacji, pobierania danych, routingu i dokumentów. Zakres automatycznych decyzji określ oddzielnie.
6. Przetestuj proces end-to-end. Uwzględnij braki danych, timeouty, ponowienia, odmowy, analizę manualną i błędy uruchomienia kredytu.
7. Rozszerzaj wdrożenie etapami. Kolejne produkty uruchamiaj po potwierdzeniu stabilności operacyjnej i efektów biznesowych.

Jak obsługiwać ścieżkę automatyczną, wyjątki i błędy integracyjne?

Ścieżka automatyczna: LOS nadaje identyfikator wniosku, pobiera uprawnione dane, weryfikuje kompletność i przekazuje odpowiednie informacje do silnika decyzyjnego. Jeżeli sprawa spełnia zatwierdzone kryteria automatycznego przetwarzania, system przygotowuje dokumenty i inicjuje kolejne etapy. Dyspozycja uruchomienia kredytu trafia do core bankingu dopiero po spełnieniu wymaganych warunków.

Brak danych: workflow przechodzi do zdefiniowanego stanu oczekiwania. Klient otrzymuje informację o wymaganych dokumentach, a po ich dostarczeniu walidacja jest wznawiana bez ponownego zakładania sprawy.

Analiza manualna: wniosek trafia do analityka wraz z kontekstem, wynikami wykonanych kontroli i listą nierozwiązanych kwestii. Analityk nie powinien rozpoczynać oceny od początku.

Odmowa: system zapisuje właściwy wynik, zachowuje wymagane informacje audytowe i uruchamia komunikację zgodną z obowiązującymi wymaganiami.

Błąd techniczny: jeżeli core banking nie potwierdzi uruchomienia kredytu, LOS nie oznacza produktu jako aktywnego tylko dlatego, że wysłał dyspozycję. Przed ewentualnym ponowieniem operacji konieczne jest ustalenie rzeczywistego statusu w systemie źródłowym.

Gotowość produkcyjna wymaga testów kontraktowych, integracyjnych, regresyjnych i scenariuszy awaryjnych. Równie ważne są monitoring end-to-end, realistyczny plan wycofania zmian i jasna odpowiedzialność za incydenty.

Jak mierzyć efektywność cyfryzacji procesu kredytowego?

Skuteczność projektu należy oceniać na podstawie rezultatów operacyjnych i biznesowych, a nie liczby zdigitalizowanych ekranów. Wartości bazowe trzeba zmierzyć przed wdrożeniem i utrzymywać spójne definicje KPI w kolejnych etapach.

Wyniki należy analizować osobno dla produktów, kanałów i segmentów klientów. Prosty wniosek klienta posiadającego już relację z bankiem nie powinien być porównywany bezpośrednio ze złożoną sprawą wymagającą indywidualnej oceny.

Szybkość procesu trzeba zestawiać z jakością decyzji i wynikami ryzyka. Krótszy czas do decyzji nie jest sukcesem, jeżeli pogarsza się jakość danych, rośnie liczba korekt lub słabną mechanizmy kontrolne.

Najczęstsze błędy przy cyfryzacji procesu kredytowego

Najdroższym błędem jest optymalizacja jednego etapu bez mierzenia wpływu na całą ścieżkę. Szybsza walidacja formularza nie poprawi time-to-disbursement, jeżeli wniosek nadal czeka na ręczne przygotowanie umowy albo niepotwierdzony status transakcji w core bankingu.

Jak Edge One Solutions wspiera cyfryzację procesów kredytowych?

Cyfryzacja kredytów end-to-end wymaga współpracy IT, ryzyka kredytowego, compliance, operacji i obsługi klienta. Każdy zespół odpowiada za inny fragment procesu, ale wartość biznesowa zależy od jakości połączeń między nimi.

Edge One Solutions wspiera rozwój backendu, integracje API, modernizację istniejących systemów, automatyzację testów i dostarczanie kompetencji inżynierskich. Praktyczne zastosowanie tych kompetencji pokazują projekty realizowane dla Banku Pekao.

Case study: Cyfrowy proces kredytowy dla klientów biznesowych Banku Pekao

W projekcie dotyczącym kredytów dla klientów biznesowych Edge One Solutions wspierało rozwój procesu online obejmującego symulację finansowania, złożenie wniosku, podpisanie umowy i uruchomienie kredytu.

Zakres prac obejmował frontend, backend oraz integracje z narzędziami zarządzania procesami biznesowymi. Wykorzystano m.in. Java, architekturę Domain-Driven Design, Kafka do przetwarzania zdarzeń, Swagger/OpenAPI do dokumentowania interfejsów i IBM BPM do obsługi złożonego workflow.

Istotą projektu było połączenie aplikacji klienta, logiki biznesowej, systemów bankowych i zarządzania procesem w spójną ścieżkę online.

Zobacz case study: Online Credit Process for Business Customers – Bank Pekao.

Case study: Rozwój kanału online dla kredytów hipotecznych Banku Pekao

W innym projekcie Edge One Solutions dostarczyło specjalistów IT wspierających rozwój cyfrowego kanału sprzedaży kredytów hipotecznych. Prace obejmowały przygotowanie MVP, rozwój funkcji omnikanałowych, obsługę różnych źródeł dochodu i wielu wnioskodawców, automatyzację analiz oraz integrację z systemem HIPOSFERA.

Projekt pokazuje znaczenie etapowego rozwoju rozwiązania: najpierw weryfikacji założeń w MVP, a następnie rozbudowy funkcji i integracji z istniejącą infrastrukturą bankową.

Zobacz case study: Rozwój kanału online dla kredytów hipotecznych Banku Pekao.