Szablon danych dla onboardingu klientów KYC
Szablon danych dla onboardingu klientów KYC
To ogólny szablon danych do process mining dla procesu Onboarding klientów KYC. Aby uzyskać dokładniejsze wskazówki, skorzystaj z szablonów dla konkretnych systemów.
Wybierz konkretny system- Elastyczny punkt wyjścia do pracy z dowolnym systemem obsługującym onboarding KYC.
- Wskazuje dane potrzebne do skutecznego odkrywania i analizy procesu.
- Uniwersalny schemat, z którego można skorzystać przed przejściem do szczegółów konkretnego systemu.
Atrybuty onboardingu klientów KYC
| Nazwa | Opis | ||
|---|---|---|---|
| Czas rozpoczęcia zdarzenia EventStartTime | Znacznik czasu wskazujący, kiedy rozpoczęło się lub wystąpiło dane działanie. | ||
| Opis Czas rozpoczęcia zdarzenia to dokładna data i godzina rozpoczęcia działania. Obok case ID i nazwy działania jest jednym z trzech podstawowych elementów process mining. Dane ze znacznikami czasu pozwalają uporządkować zdarzenia w każdym przypadku chronologicznie, co jest niezbędne do odtworzenia rzeczywistego przebiegu procesu. Ten atrybut stanowi podstawę wszystkich analiz czasu. Służy do obliczania czasu trwania działań, jeśli dostępny jest również czas ich zakończenia, czasu oczekiwania między działaniami oraz całkowitego czasu realizacji onboardingu. Analiza tych wartości pomaga wykrywać wąskie gardła, mierzyć dotrzymywanie SLA i monitorować ogólną efektywność procesu. Dlaczego to ważne Pozwala ustalić kolejność zdarzeń, niezbędną do odkrycia modelu procesu i obliczenia wszystkich czasowych wskaźników efektywności. Skąd pobrać Znajduje się w dziennikach zdarzeń, śladach audytowych wniosków lub tabelach transakcji. Może mieć nazwę „Timestamp”, „Creation Date” lub „Start Time”. Przykłady 2023-01-15T09:00:00Z2023-03-20T14:35:10Z2023-05-10T11:21:05Z | |||
| Identyfikator wniosku CustomerApplicationId | Unikalny identyfikator wniosku o onboarding klienta, używany jako case ID w analizie procesu. | ||
| Opis Identyfikator wniosku klienta to unikalny klucz przypisywany każdemu nowemu wnioskowi o onboarding od chwili jego złożenia aż do zakończenia lub przerwania. Łączy wszystkie działania, zdarzenia i dane dotyczące jednej ścieżki onboardingu, dlatego jest najważniejszym atrybutem w process mining. Identyfikator ten pozwala odtworzyć cały proces dla każdego klienta. Umożliwia śledzenie postępów wniosku, obliczenie całkowitego czasu realizacji i porównanie jego przebiegu z innymi. Warianty procesu, wąskie gardła i wskaźniki efektywności analizuje się dla każdego wniosku osobno. Jest to możliwe tylko wtedy, gdy ten atrybut zostanie prawidłowo zidentyfikowany i użyty jako case ID. Dlaczego to ważne Pozwala połączyć wszystkie powiązane zdarzenia w jeden proces od początku do końca i stanowi podstawę każdej analizy process mining. Skąd pobrać Zazwyczaj znajduje się w nagłówku lub głównej tabeli wniosku klienta albo systemu zarządzania sprawami. Przykłady APP-2023-00123KYC-987654ONB-C-456-7890 | |||
| Nazwa działania ActivityName | Nazwa konkretnego zdarzenia biznesowego lub zadania wykonanego w procesie onboardingu klienta. | ||
| Opis Nazwa działania opisuje konkretny krok lub kamień milowy na ścieżce onboardingu klienta, na przykład „Złożono wniosek”, „Rozpoczęto weryfikację zgodności” lub „Zatwierdzono wniosek”. Każde działanie oznacza konkretną czynność użytkownika lub systemu, która przesuwa wniosek dalej w procesie. Ten atrybut ma podstawowe znaczenie przy tworzeniu mapy procesu, która stanowi centrum process mining. Analiza kolejności i częstotliwości działań pozwala zrozumieć rzeczywisty przebieg procesu, rozpoznać typowe ścieżki, wykryć odstępstwa oraz wskazać miejsca, w których praca jest powtarzana. Jasne i spójne nazwy działań pomagają zbudować czytelny i użyteczny model procesu. Dlaczego to ważne Określa kolejne kroki procesu, dzięki czemu można przedstawić i analizować jego przebieg, wąskie gardła oraz różnice między wariantami. Skąd pobrać Występuje w dziennikach zdarzeń, śladach audytowych lub tabelach transakcji rejestrujących kroki procesu biznesowego. Przykłady Wstępna weryfikacja zakończonaPoproszono o dokumentyPrzeprowadzono ocenę ryzykaZatwierdzono wniosek | |||
| Czas ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane zostały ostatnio odświeżone lub pobrane z systemu źródłowego. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub odświeżenia danych. Nie jest częścią procesu biznesowego, ale stanowi ważne metadane wykorzystywane do walidacji i nadzoru nad danymi. Informuje, jak aktualne są analizowane dane. W analizie procesu znajomość czasu ostatniej aktualizacji danych pozwala ocenić aktualność uzyskanych wniosków. Ułatwia użytkownikom zaufanie do danych, ponieważ pokazuje, na ile są bieżące, i zapobiega błędnym wnioskom opartym na nieaktualnych informacjach. Przy stałym monitorowaniu można wykorzystać ten atrybut do ustawiania alertów o opóźnionym lub nieudanym odświeżeniu danych, co pomaga utrzymać wiarygodność dashboardów process mining. Dlaczego to ważne Zapewnia przejrzystość danych, pokazując aktualność zbioru, która ma zasadnicze znaczenie dla trafności i dokładności analizy. Skąd pobrać Powstaje podczas procesu ekstrakcji, transformacji i ładowania danych (ETL). Często znajduje się w metadanych zbioru danych. Przykłady 2023-10-27T02:00:00Z2023-10-26T02:00:00Z2023-10-25T02:00:00Z | |||
| System źródłowy SourceSystem | Wskazuje system, z którego pochodzą dane o zdarzeniu. | ||
| Opis Atrybut „System źródłowy” określa aplikację lub platformę, która wygenerowała dane dotyczące danego działania. W złożonym środowisku proces KYC może obejmować kilka systemów, na przykład CRM do składania wniosków, dedykowaną platformę KYC do oceny ryzyka i centralny system bankowy do tworzenia kont. Analiza procesu według systemu źródłowego pomaga zrozumieć wykorzystywane rozwiązania technologiczne i ich wpływ na proces. Może ujawnić problemy z integracją, opóźnienia w przepływie danych między systemami lub różnice w sposobie rejestrowania informacji. Taki widok przydaje się zespołom IT i zespołom zajmującym się ulepszaniem procesów, które chcą usprawnić architekturę systemów obsługujących onboarding. Dlaczego to ważne Pokazuje, w którym systemie odbywa się każdy krok procesu, co pomaga wykrywać nieefektywności na styku systemów i problemy z integracją danych. Skąd pobrać Często występuje w wyciągach danych lub dziennikach zdarzeń, zwłaszcza w środowiskach z wieloma zintegrowanymi systemami. Przykłady CRM_System_AKYC_Platform_BCoreBanking_Sys_C | |||
| Czas zakończenia zdarzenia EventEndTime | Znacznik czasu wskazujący, kiedy zakończyło się dane działanie. | ||
| Opis Czas zakończenia zdarzenia to dokładna data i godzina zakończenia działania. W połączeniu z czasem jego rozpoczęcia pozwala precyzyjnie obliczyć czas realizacji każdego zadania. Nie wszystkie systemy udostępniają zarówno czas rozpoczęcia, jak i zakończenia. Niektóre zapisują tylko jeden znacznik czasu, oznaczający zakończenie. Czas zakończenia jest bardzo przydatny w analizie efektywności. Umożliwia tworzenie szczegółowych wskaźników, takich jak „Średni czas weryfikacji zgodności”, ponieważ pozwala odróżnić czas aktywnej pracy pracownika od czasu oczekiwania zadania w kolejce. Taki poziom szczegółowości pomaga dokładnie wykrywać wąskie gardła i kierować działania usprawniające na dostępność zasobów lub przekazywanie zadań. Dlaczego to ważne Umożliwia precyzyjne obliczenie czasu realizacji działań i odróżnienie aktywnej pracy od bezczynnego oczekiwania. Skąd pobrać Występuje w dziennikach zdarzeń lub tabelach transakcji, obok czasu rozpoczęcia. Może mieć nazwę „End Time”, „Completion Date” lub „Modified On”. Przykłady 2023-01-15T17:30:00Z2023-03-21T10:15:20Z2023-05-10T11:55:00Z | |||
| Dział użytkownika UserDepartment | Dział lub zespół biznesowy odpowiedzialny za wykonanie działania. | ||
| Opis Dział użytkownika wskazuje jednostkę organizacyjną lub zespół, do którego należy osoba wykonująca działanie, na przykład „Zgodność”, „Onboarding klientów” lub „Operacje”. Zapewnia szerszy kontekst organizacyjny niż sam identyfikator użytkownika. Analiza procesu z perspektywy działów pomaga zrozumieć współpracę między różnymi obszarami i wykrywać problemy występujące w całej organizacji. Ułatwia pokazanie przekazywania zadań między zespołami, które często powoduje opóźnienia i nieefektywność. Informacje te pomagają usprawnić strukturę zespołów, doprecyzować zakresy odpowiedzialności i poprawić komunikację, aby onboarding przebiegał sprawniej. Dlaczego to ważne Umożliwia analizę efektywności procesu i przekazywania zadań między zespołami, wskazując możliwości usprawnienia współpracy między działami. Skąd pobrać Często dostępny w danych profilu użytkownika powiązanych z jego identyfikatorem. Może też być zapisany bezpośrednio w transakcji. Przykłady ComplianceObsługa klientaOperacje KYC | |||
| Identyfikator użytkownika UserId | Identyfikator lub nazwa pracownika albo agenta automatycznego, który wykonał działanie. | ||
| Opis Identyfikator użytkownika wskazuje osobę lub bota systemowego odpowiedzialnego za wykonanie danego działania w procesie. Może to być specjalista ds. zgodności, pracownik wprowadzający dane lub automatyczny silnik oceny ryzyka. Spójne identyfikowanie użytkowników jest niezbędne do prawidłowej analizy zasobów. Ten atrybut pozwala spojrzeć na proces z perspektywy osób, które go realizują. Jest niezbędny do analizy rozkładu obciążenia, efektywności poszczególnych osób i zespołów oraz alokacji zasobów. Filtrowanie mapy procesu według identyfikatora użytkownika pozwala menedżerom sprawdzić, jak poszczególni pracownicy wykonują zadania, wskazać potrzeby szkoleniowe i zadbać o równomierny podział pracy. Ułatwia też analizę współpracy i pokazuje, jak zadania są przekazywane między osobami. Dlaczego to ważne Umożliwia analizę obciążenia pracą, efektywności zasobów i sposobów współpracy, co ułatwia zarządzanie zasobami i planowanie szkoleń. Skąd pobrać Dostępny w śladach audytowych systemu lub dziennikach transakcji, często powiązany z użytkownikiem, który utworzył lub ostatnio zmodyfikował rekord. Przykłady john.doeSYSTEM_AUTOuser12345 | |||
| Poziom ryzyka RiskLevel | Obliczona klasyfikacja ryzyka wniosku klienta, na przykład niska, średnia lub wysoka. | ||
| Opis Poziom ryzyka to jeden z ważnych wyników procesu KYC. Klasyfikuje klientów na podstawie takich czynników jak branża, lokalizacja i wzorce transakcji. Od tej klasyfikacji zależy zakres kontroli i należytej staranności wymagany przy rozpatrywaniu wniosku. W process mining ten atrybut jest przydatny do analizy zgodności i wariantów procesu. Proces dla klienta wysokiego ryzyka powinien z założenia różnić się od procesu dla klienta niskiego ryzyka i obejmować dokładniejszą weryfikację. Porównanie rzeczywistego przebiegu dla różnych poziomów ryzyka z wymaganymi procedurami pozwala sprawdzić zgodność z wewnętrznymi zasadami i przepisami. Można dzięki temu odpowiedzieć na pytania: „Czy klienci wysokiego ryzyka zawsze przechodzą wzmożoną weryfikację?” lub „Czy poświęcamy zbyt dużo czasu klientom niskiego ryzyka?”. Dlaczego to ważne Jest niezbędny do zarządzania zgodnością i ryzykiem. Pozwala sprawdzić, czy zakres należytej staranności jest odpowiednio dostosowany do profilu ryzyka. Skąd pobrać Obliczany przez silnik oceny ryzyka lub przypisywany ręcznie przez specjalistę ds. zgodności. Przechowywany w głównym rekordzie klienta lub wniosku. Przykłady NiskiŚredniWysokiPEP | |||
| Status wniosku ApplicationStatus | Końcowy wynik lub bieżący stan wniosku o onboarding klienta. | ||
| Opis Status wniosku określa jego ostateczny wynik, na przykład „Zatwierdzony”, „Odrzucony” lub „Wycofany”. Pokazuje rezultat biznesowy procesu i jest ważnym wymiarem pomiaru efektywności. Ten atrybut jest niezbędny do analizy wyników. Pozwala porównywać ścieżki procesu prowadzące do zatwierdzenia z tymi, które kończą się odrzuceniem. Analitycy mogą dzięki niemu wykrywać wzorce związane z wysokim odsetkiem odrzuceń, obliczać KPI, takie jak „Odsetek odrzuconych wniosków”, oraz tworzyć analizę lejka onboardingu, aby sprawdzić, na którym etapie wnioskodawcy rezygnują. Zrozumienie przyczyn niepowodzeń to pierwszy krok do usprawnienia procesu i zwiększenia odsetka zatwierdzeń. Dlaczego to ważne Określa wynik biznesowy każdej sprawy, umożliwiając analizę przyczyn odrzucania wniosków i sposobów na zwiększenie odsetka zatwierdzeń. Skąd pobrać Zazwyczaj znajduje się w głównej tabeli spraw lub wniosków i wskazuje końcowy stan rekordu. Przykłady ZatwierdzonyOdrzuconyW tokuWycofany przez klienta | |||
| Typ klienta CustomerType | Kategoria klienta, na przykład osoba fizyczna lub firma. | ||
| Opis Typ klienta przypisuje wnioskodawcę do określonej kategorii, na przykład „Osoba fizyczna”, „Firma”, „Trust” lub „Organizacja non-profit”. Wymagania dotyczące onboardingu i złożoność procesu mogą znacznie różnić się w zależności od typu klienta. To ważny atrybut segmentacji. Filtrowanie mapy procesu i KPI według typu klienta pozwala wykryć istotne różnice. Na przykład onboarding firmy zwykle obejmuje bardziej złożone kroki, takie jak weryfikacja beneficjentów rzeczywistych, które nie są wymagane w przypadku osoby fizycznej. Analiza pomaga usprawnić każdy wariant procesu z myślą o danym segmencie i lepiej dopasować działania usprawniające. Dlaczego to ważne Pozwala podzielić proces na segmenty, aby porównywać i usprawniać onboarding różnych typów klientów. Skąd pobrać Zazwyczaj rejestrowany na początku procesu składania wniosku i przechowywany w głównej tabeli klienta lub wniosku. Przykłady Osoba fizycznaFirmaTrustMała firma | |||
| Czy wykonano automatycznie IsAutomated | Flaga wskazująca, czy działanie wykonał automatycznie system, czy ręcznie użytkownik. | ||
| Opis Ten atrybut logiczny odróżnia zadania wykonywane przez oprogramowanie lub boty od tych realizowanych przez użytkowników. Do działań automatycznych mogą należeć wstępna walidacja danych, sprawdzanie list sankcyjnych lub wysyłanie standardowych komunikatów. Analiza tego atrybutu pomaga ocenić skuteczność automatyzacji. Porównanie szybkości i wyników działań automatycznych z ręcznymi pozwala wskazać kolejne możliwości automatyzacji, które mogą ograniczyć koszty i czas realizacji. Ułatwia też monitorowanie działania systemów automatycznych i sprawdzanie, czy funkcjonują zgodnie z oczekiwaniami w całym procesie. Dlaczego to ważne Pomaga mierzyć wpływ i efektywność automatyzacji procesu oraz wskazywać możliwości dalszych usprawnień z użyciem RPA lub innych rozwiązań systemowych. Skąd pobrać Może być osobnym polem w dzienniku zdarzeń albo być wyznaczany na podstawie identyfikatora użytkownika, na przykład gdy ma on wartość „SYSTEM” lub „BOT”. Przykłady truefalse | |||
| Identyfikator klienta CustomerId | Unikalny identyfikator klienta obejmujący onboardingiem. | ||
| Opis Identyfikator klienta jest unikalnym oznaczeniem, które pozostaje takie samo w przypadku wielu interakcji lub wniosków. Identyfikator wniosku klienta śledzi jedną ścieżkę onboardingu, natomiast identyfikator klienta może łączyć wiele prób onboardingu lub inne procesy dotyczące tej samej osoby. Ten atrybut pozwala analizować proces z perspektywy klienta, a nie pojedynczej sprawy. Przydaje się do rozpoznawania klientów składających kolejne wnioski, analizy długoterminowej relacji z klientem lub łączenia onboardingu z innymi procesami, takimi jak „Wniosek o kredyt” czy „Obsługa konta”. Nie jest niezbędny do analizy pojedynczego procesu, ale wzbogaca dane potrzebne do bardziej złożonego, obiektowego process mining. Dlaczego to ważne Pozwala analizować proces z perspektywy klienta, łącząc wiele prób onboardingu lub różne procesy dotyczące tej samej osoby. Skąd pobrać Zazwyczaj znajduje się w centralnym systemie danych podstawowych klientów i jest powiązany z rekordem wniosku. Przykłady CUST-1005678943210AENT-4590 | |||
| Kanał złożenia wniosku ApplicationChannel | Kanał, za pośrednictwem którego klient złożył wniosek. | ||
| Opis Ten atrybut wskazuje sposób złożenia wniosku przez klienta, na przykład „Portal internetowy”, „Aplikacja mobilna” lub „W oddziale”. W zależności od kanału mogą się różnić zarówno sposób zbierania danych, jak i doświadczenia klientów. Analiza procesu według kanału pozwala ocenić efektywność poszczególnych punktów kontaktu z klientem. Można dzięki niej odpowiedzieć na pytania: „Czy wnioski z aplikacji mobilnej są przetwarzane szybciej niż te złożone przez internet?” lub „Czy wnioski składane w oddziale częściej wymagają poprawek?”. Takie informacje pomagają usprawnić ścieżkę klienta we wszystkich kanałach i lepiej przydzielać zasoby. Dlaczego to ważne Umożliwia porównanie efektywności procesu i doświadczeń klientów w różnych kanałach składania wniosków, takich jak internet, urządzenia mobilne i obsługa osobista. Skąd pobrać Zazwyczaj rejestrowany na samym początku procesu, podczas tworzenia wniosku. Przykłady Portal internetowyAplikacja mobilnaW oddziale | |||
| Kraj klienta CustomerCountry | Kraj zamieszkania lub rejestracji klienta. | ||
| Opis Kraj klienta określa lokalizację geograficzną wnioskodawcy. Jest to ważna informacja w procesach KYC, ponieważ przepisy i czynniki ryzyka mogą znacznie różnić się w zależności od kraju. Analiza geograficzna dostarcza dodatkowych informacji. Przebieg onboardingu może zależeć od lokalnych wymogów prawnych. Filtrowanie według kraju klienta pozwala sprawdzić, czy warianty procesu dla poszczególnych jurysdykcji są realizowane prawidłowo. Można też wykryć różnice w efektywności, na przykład dłuższy czas realizacji wniosków z krajów wysokiego ryzyka, co może wynikać z wymogów wzmożonej weryfikacji. Dlaczego to ważne Umożliwia analizę różnic w przebiegu i efektywności procesu w zależności od lokalizacji, co ma znaczenie dla zgodności z lokalnymi przepisami. Skąd pobrać Pobierany od klienta podczas składania wniosku i zapisywany w rekordzie klienta lub wniosku. Przykłady USAGBRSGPDEU | |||
| Powód odrzucenia RejectionReason | Konkretna przyczyna podana przy odrzuceniu wniosku klienta. | ||
| Opis Gdy status wniosku to „Odrzucony”, powód odrzucenia wskazuje konkretną przyczynę, na przykład „Niekompletna dokumentacja”, „Wysoki profil ryzyka” lub „Zgodność z listą sankcyjną”. Ten atrybut dostarcza ważnego kontekstu dla nieudanych spraw. Analiza powodów odrzucenia stanowi podstawę dashboardu „Analiza odrzuconych wniosków”. Pomaga ustalić najczęstsze przyczyny niepowodzeń w procesie onboardingu. Klasyfikacja i zliczenie tych przyczyn pozwalają ustalić priorytety działań usprawniających. Jeśli na przykład częstym powodem jest niekompletna dokumentacja, firma może doprecyzować instrukcje dla klientów lub usprawnić portal do przesyłania dokumentów. Dlaczego to ważne Wskazuje przyczyny niepowodzeń wniosków, co pozwala wprowadzać ukierunkowane usprawnienia, ograniczać odsetek odrzuceń i poprawiać doświadczenia klientów. Skąd pobrać Zazwyczaj przechowywany w głównej tabeli wniosków lub spraw. Często uzupełniany po ustawieniu statusu „Odrzucony”. Przykłady Nieudana weryfikacja tożsamościNiekompletna dokumentacjaWysokie ryzykoDopasowanie do listy PEP | |||
| Termin SLA SlaTargetDate | Data, do której należy zakończyć proces onboardingu klienta. | ||
| Opis Termin SLA to data, do której należy zakończyć onboarding klienta. Wyznaczają go zwykle wewnętrzne zasady lub zobowiązania umowne. Służy jako punkt odniesienia przy pomiarze terminowości. Ten atrybut stanowi podstawę dashboardu „Monitorowanie realizacji SLA”. Porównanie rzeczywistej daty zakończenia wniosku z terminem SLA pozwala obliczyć wskaźnik dotrzymywania SLA. Analiza spraw, w których przekroczono termin, pomaga wskazać konkretne działania lub działy powodujące opóźnienia. Dzięki temu można lepiej zarządzać kolejkami zadań i przydziałem zasobów, ograniczać przypadki naruszenia SLA i poprawiać satysfakcję klientów. Dlaczego to ważne Stanowi punkt odniesienia do pomiaru realizacji SLA i wskazywania spraw zagrożonych opóźnieniem. Skąd pobrać Często obliczany i zapisywany w głównym rekordzie wniosku podczas tworzenia sprawy, na podstawie typu wniosku lub innych kryteriów. Przykłady 2023-01-30T23:59:59Z2023-04-15T23:59:59Z2023-06-01T23:59:59Z | |||
Czynności w procesie onboardingu klientów KYC
| Działanie | Opis | ||
|---|---|---|---|
| Odrzucono wniosek | Oznacza ostateczną decyzję o odrzuceniu wniosku klienta i zakończeniu procesu wdrożenia. To negatywny wynik procesu, który warto analizować. | ||
| Dlaczego to ważne To ważne zdarzenie oznaczające niepowodzenie. Analiza tego, kiedy i dlaczego dochodzi do odrzuceń, pomaga usprawniać proces i rozumieć trudności napotykane przez klientów. Skąd pobrać Zdarzenie jest rejestrowane jako końcowa zmiana statusu wniosku, na przykład na „Odrzucony” lub „Niezaakceptowany”. Rejestrowanie Ustal znacznik czasu ustawienia końcowego statusu wniosku na „Odrzucony” lub inny status oznaczający niepowodzenie. Typ zdarzenia inferred | |||
| Poproszono o dodatkowe informacje | Oznacza zdarzenie, w którym osoba weryfikująca potrzebuje dodatkowych informacji lub dokumentów od klienta, aby kontynuować pracę. Powoduje to powrót do wcześniejszego etapu i wstrzymuje wewnętrzną obsługę sprawy. | ||
| Dlaczego to ważne To jedna z głównych przyczyn nieefektywności procesu i wydłużenia czasu realizacji. Częste występowanie tej czynności może wskazywać na problemy z początkowym zbieraniem danych. Skąd pobrać Zwykle jest rejestrowana jawnie, ponieważ wiąże się z wysłaniem powiadomienia do klienta i pozostawia ślad w dziennikach komunikacji lub audytu. Rejestrowanie Użyj znacznika czasu zdarzenia „Prośba o informacje”, konkretnej zmiany statusu lub zarejestrowanej wiadomości do klienta. Typ zdarzenia explicit | |||
| Przeprowadzono ocenę ryzyka | Ta czynność oznacza uruchomienie silnika decyzyjnego lub ręczną ocenę punktową ryzyka związanego z wnioskiem klienta. Zebrane informacje służą do określenia poziomu ryzyka klienta. | ||
| Dlaczego to ważne Wynik oceny ryzyka często wyznacza dalszą ścieżkę procesu, na przykład automatyczną obsługę lub ręczną kontrolę zgodności. Skąd pobrać Jako podstawowa funkcja procesu ocena ryzyka jest często rejestrowana jako jawne zdarzenie w chwili uruchomienia zestawu reguł lub uzupełnienia pola z oceną ryzyka. Rejestrowanie Użyj znacznika czasu z dziennika uruchomienia silnika oceny ryzyka lub ścieżki audytowej pola z oceną ryzyka. Typ zdarzenia explicit | |||
| Rozpoczęto kontrolę zgodności | Ta czynność oznacza rozpoczęcie ręcznej weryfikacji przez dział zgodności. Zwykle dotyczy wniosków wysokiego ryzyka lub oznaczonych do kontroli i wiąże się z przekazaniem sprawy wyspecjalizowanemu zespołowi. | ||
| Dlaczego to ważne Śledzenie tej czynności pomaga wykrywać wąskie gardła w procesie kontroli zgodności. Czas do jej zakończenia stanowi istotną część całkowitego czasu realizacji. Skąd pobrać Zdarzenie często ustala się na podstawie zmiany statusu sprawy lub wpisu w dzienniku audytowym wskazującego, że sprawę przypisano do kolejki pracownika działu zgodności. Rejestrowanie Ustal znacznik czasu zmiany statusu wniosku na „Oczekiwanie na kontrolę zgodności” lub przypisania go do kolejki działu zgodności. Typ zdarzenia inferred | |||
| Zakończono wdrożenie klienta | To ostatnia czynność w procesie. Oznacza, że wdrożenie klienta zostało zakończone, a sprawa administracyjnie zamknięta. Klient może już korzystać z usług. | ||
| Dlaczego to ważne To końcowe zdarzenie w sprawach zakończonych pomyślnie. Całkowity czas do jego wystąpienia odpowiada czasowi wdrożenia klienta. Skąd pobrać Zdarzenie ustala się na podstawie końcowego statusu sprawy w systemie źródłowym, na przykład „Wdrożony” lub „Zamknięty, zatwierdzony”. Rejestrowanie Użyj znacznika czasu końcowego zamknięcia sprawy lub zmiany statusu na końcowy „Zakończono”. Typ zdarzenia inferred | |||
| Zatwierdzono wniosek | Ta czynność oznacza ostateczną decyzję biznesową o zatwierdzeniu wniosku klienta i rozpoczęciu jego wdrożenia. To ważny etap potwierdzający pomyślne zakończenie procesu KYC. | ||
| Dlaczego to ważne To zdarzenie oznacza pomyślny wynik i kończy proces podejmowania decyzji. Umożliwia analizę odsetka zatwierdzeń i czasu potrzebnego na podjęcie decyzji. Skąd pobrać Zdarzenie jest zwykle rejestrowane w systemie zarządzania sprawami jako osobna, końcowa zmiana statusu w cyklu życia wniosku. Rejestrowanie Ustal znacznik czasu ustawienia końcowego statusu wniosku na „Zatwierdzony” lub inny status oznaczający pomyślne zakończenie. Typ zdarzenia inferred | |||
| Złożenie wniosku | Ta czynność rozpoczyna proces wdrożenia klienta. Jest rejestrowana, gdy system formalnie otrzymuje nowy wniosek klienta, przez portal dla klientów lub po wprowadzeniu danych przez pracownika. | ||
| Dlaczego to ważne To główne zdarzenie rozpoczynające proces. Analiza liczby i czasu składania wniosków pomaga zrozumieć zapotrzebowanie i dostępne moce przerobowe. Skąd pobrać Zdarzenie jest zwykle rejestrowane w dzienniku tworzenia wniosków lub jako pierwszy wpis w ścieżce audytowej systemu zarządzania sprawami. Rejestrowanie Użyj znacznika czasu utworzenia wniosku lub rekordu sprawy. Typ zdarzenia explicit | |||
| Otrzymano dokumenty | Ta czynność oznacza, że klient dostarczył wymagane dokumenty tożsamości i dokumenty uzupełniające. Są one już dostępne w systemie do weryfikacji. | ||
| Dlaczego to ważne To zdarzenie ma znaczenie przy mierzeniu czasu odpowiedzi klienta i wykrywaniu opóźnień spowodowanych przez wnioskodawcę. Skąd pobrać Zwykle jest rejestrowane jako osobne, jawne zdarzenie w dzienniku zarządzania dokumentami lub ścieżce audytowej sprawy przy każdym przesłaniu dokumentu. Rejestrowanie Użyj znacznika czasu utworzenia lub przesłania załączników powiązanych ze sprawą. Typ zdarzenia explicit | |||
| Poproszono o dokumenty | Ta czynność ma miejsce, gdy system lub pracownik stwierdza, że do dalszej weryfikacji potrzebne są konkretne dokumenty od klienta. Oznacza formalne wysłanie prośby o informacje do wnioskodawcy. | ||
| Dlaczego to ważne Śledzenie tej czynności pomaga zrozumieć opóźnienia wynikające z przebiegu procesu. Czas między tym zdarzeniem a otrzymaniem dokumentów to czas oczekiwania na klienta. Skąd pobrać Zdarzenie można odczytać z dzienników komunikacji generowanych przez system, wiadomości e-mail lub zmiany statusu wskazującej, że sprawa oczekuje na dokumenty. Rejestrowanie Użyj znacznika czasu wysłania wiadomości do klienta lub zmiany statusu na „Oczekiwanie na dokumenty”. Typ zdarzenia explicit | |||
| Przeprowadzono weryfikację tożsamości | Oznacza automatyczne lub ręczne sprawdzenie tożsamości klienta na podstawie zewnętrznych lub wewnętrznych źródeł danych. To jeden z podstawowych etapów weryfikacji KYC. | ||
| Dlaczego to ważne Ta czynność ma znaczenie dla zgodności i zapobiegania oszustwom. Niepowodzenie na tym etapie może prowadzić do odrzucenia wniosku lub dalszego postępowania wyjaśniającego. Skąd pobrać Często jest rejestrowana jako jawne zdarzenie w chwili wywołania API zewnętrznej usługi weryfikacyjnej i otrzymania odpowiedzi. Rejestrowanie Użyj znacznika czasu z dziennika wywołania usługi weryfikacji tożsamości oraz odpowiadającej mu odpowiedzi o powodzeniu lub niepowodzeniu. Typ zdarzenia explicit | |||
| Rozpoczęto weryfikację danych zewnętrznych | Oznacza rozpoczęcie automatycznej lub ręcznej weryfikacji, na przykład kontroli AML, PEP lub historii kredytowej. Często wiąże się z uruchomieniem usług zewnętrznych dostawców. | ||
| Dlaczego to ważne Weryfikacja danych zewnętrznych może powodować znaczne opóźnienia. Rejestrowanie jej rozpoczęcia pozwala zmierzyć czas oczekiwania na wyniki od zewnętrznych dostawców. Skąd pobrać Zdarzenie jest często rejestrowane jawnie, gdy system uruchamia weryfikację, lub ustalane na podstawie zmiany statusu, na przykład na „Oczekiwanie na weryfikację danych zewnętrznych”. Rejestrowanie Użyj znacznika czasu wywołania API usługi weryfikacji danych zewnętrznych lub wpisu w dzienniku wskazującego rozpoczęcie kontroli. Typ zdarzenia explicit | |||
| Utworzono konto | Po zatwierdzeniu wniosku ta czynność oznacza techniczne utworzenie konta klienta w systemie bankowości podstawowej lub systemie zarządzania użytkownikami. Klient przestaje być wnioskodawcą i staje się aktywnym użytkownikiem. | ||
| Dlaczego to ważne Pozwala ocenić sprawność przekazania sprawy z procesu decyzyjnego do systemów technicznego udostępniania usług. Skąd pobrać Często jest rejestrowana jako jawne zdarzenie przez system wdrożeniowy po otrzymaniu potwierdzenia z systemu podrzędnego lub ustalana na podstawie daty utworzenia konta w systemie podstawowym. Rejestrowanie Użyj znacznika czasu utworzenia konta z systemu podstawowego lub zdarzenia potwierdzającego zarejestrowanego w systemie wdrożeniowym. Typ zdarzenia explicit | |||
| Wstępna weryfikacja zakończona | Oznacza wstępną, często zautomatyzowaną kontrolę wniosku pod kątem kompletności danych, podstawowych kryteriów kwalifikacji lub wstępnych trafień na listach sankcyjnych. Ten etap pozwala szybko odrzucić wnioski niekompletne lub niespełniające podstawowych wymagań. | ||
| Dlaczego to ważne Ta czynność pomaga ocenić jakość otrzymywanych wniosków. Wysoki odsetek niepowodzeń może wskazywać na problemy z formularzem lub instrukcjami. Skąd pobrać Zwykle jest rejestrowana jako zautomatyzowany etap w historii workflow albo ustalana na podstawie wczesnej zmiany statusu, na przykład z „Nowy” na „Wstępna weryfikacja zakończona”. Rejestrowanie Ustal znacznik czasu zakończenia wstępnej weryfikacji lub reguły walidacji. Często wskazuje go zmiana statusu. Typ zdarzenia inferred | |||
| Zakończono kontrolę zgodności | Oznacza zakończenie ręcznej weryfikacji przez dział zgodności. Pracownik działu podjął decyzję o zatwierdzeniu lub odrzuceniu wniosku albo o konieczności podjęcia dalszych działań. | ||
| Dlaczego to ważne Ten etap kończy ważną i często długotrwałą część procesu. Analiza czasu do jego zakończenia pomaga ocenić sprawność pracy zespołu ds. zgodności. Skąd pobrać Czynność często ustala się na podstawie zmiany statusu sprawy z „Oczekiwanie na kontrolę zgodności” na kolejny status, na przykład „Zgodność zatwierdzona”. Rejestrowanie Użyj znacznika czasu oznaczenia zadania kontroli zgodności jako „Zakończone” lub aktualizacji statusu sprawy odzwierciedlającej wynik weryfikacji. Typ zdarzenia inferred | |||
| Zakończono weryfikację dokumentów | Ta czynność oznacza, że pracownik lub narzędzie automatyczne zakończyło weryfikację dokumentów przesłanych przez klienta. Sprawdzono ich autentyczność, ważność i kompletność. | ||
| Dlaczego to ważne Weryfikacja dokumentów często zajmuje znaczną część całego czasu obsługi wniosku. Analiza tego etapu pomaga określić potrzeby dotyczące zasobów lub szkoleń. Skąd pobrać Zdarzenie często ustala się na podstawie zmiany statusu dokumentu lub całej sprawy, na przykład na „Dokumenty zweryfikowane” albo „Weryfikacja zakończona”. Rejestrowanie Ustal znacznik czasu zakończenia ręcznej weryfikacji lub zmiany statusu sprawy potwierdzającej pomyślną weryfikację dokumentów. Typ zdarzenia inferred | |||
Instrukcje ekstrakcji danych
Metody ekstrakcji zależą od systemu. Szczegółowe instrukcje znajdą Państwo w
naszym przewodniku ETL lub wybierz konkretny proces i system.
Jak zacząć?
Aby rozpocząć ekstrakcję danych, wybierz poniżej instrukcję dla konkretnego systemu albo skorzystaj z tego uniwersalnego szablonu.
Usprawnij onboarding KYC i zwiększ efektywność
Działa z dowolnym systemem. W ciągu kilku dni można uzyskać wnioski z danych i poprawić zgodność.
Nie trzeba podawać danych karty. Szybko można ocenić korzyści.