Szablon danych do onboardingu klientów KYC
Szablon danych do onboardingu klientów KYC
- Zalecane atrybuty do zebrania
- Działania, które warto śledzić
- Wskazówki dotyczące ekstrakcji danych
Atrybuty onboardingu klientów KYC
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas zdarzenia
EventTime
|
Znacznik czasu wskazujący, kiedy wystąpiło konkretne działanie lub zdarzenie. | ||
|
Opis
Czas zdarzenia określa dokładną datę i godzinę zarejestrowania działania. Ten znacznik czasu porządkuje zdarzenia chronologicznie i pozwala odtworzyć historię sprawy. Atrybut ten jest niezbędny do wszystkich analiz czasowych w process mining. Służy do obliczania czasu między działaniami, w tym czasu obsługi i oczekiwania, mierzenia całkowitego czasu obsługi sprawy, analizowania wyników procesu w czasie oraz sprawdzania zgodności z umowami SLA. Bez dokładnych znaczników czasu nie można ocenić sprawności procesu ani zidentyfikować opóźnień.
Dlaczego to ważne
Znacznik czasu każdego działania jest niezbędny do obliczania mierników czasu, odtworzenia kolejności procesu i analizy wąskich gardeł.
Skąd pobrać
To standardowe pole w dzienniku zdarzeń lub tabeli ścieżki audytu, często nazwane „Timestamp”, „EventDate” lub „CreationDate”.
Przykłady
2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
|
|||
|
Nazwa działania
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło w procesie wdrożenia klienta KYC. | ||
|
Opis
Nazwa działania opisuje pojedynczy krok lub zdarzenie w procesie wdrożenia klienta, na przykład „Złożono wniosek”, „Rozpoczęto weryfikację przez analityka” lub „Zakończono weryfikację, wynik bez zastrzeżeń”. Działania te tworzą węzły mapy procesu i szczegółowo przedstawiają cały workflow. Analiza działań stanowi podstawę process mining. Śledzenie ich kolejności i częstotliwości pozwala analitykom odkryć rzeczywisty przebieg procesu, wskazać najczęstsze ścieżki, wykryć odstępstwa od standardowej procedury oraz znaleźć etapy powodujące opóźnienia lub konieczność ponownej pracy. Ten atrybut jest niezbędny do tworzenia map procesów i obliczania mierników dla poszczególnych działań.
Dlaczego to ważne
Ten atrybut określa poszczególne kroki procesu. Jest niezbędny do odkrywania i wizualizacji jego przebiegu oraz identyfikowania wąskich gardeł.
Skąd pobrać
Te informacje znajdują się zwykle w dziennikach zdarzeń lub tabelach ścieżki audytu, często przy zmianach statusu w rekordzie sprawy.
Przykłady
Wykryto potencjalne dopasowanieRozpoczęto weryfikację przez analitykaPotwierdzono fałszywe dopasowanieZatwierdzono wniosek
|
|||
|
Wniosek klienta
CustomerApplication
|
Unikalny identyfikator wniosku o wdrożenie pojedynczego klienta, używany jako główny identyfikator sprawy. | ||
|
Opis
Wniosek klienta to główny identyfikator sprawy, który łączy wszystkie zdarzenia i działania związane z wdrożeniem danego klienta. Umożliwia pełne, chronologiczne śledzenie przebiegu procesu KYC, od złożenia wniosku po ostateczną decyzję. W analizie process mining ten atrybut jest podstawą do odtworzenia całego przebiegu obsługi każdego wniosku. Pozwala wizualizować przepływy procesu, obliczać łączny czas obsługi i identyfikować warianty. Analiza spraw pogrupowanych według tego identyfikatora pokazuje możliwe ścieżki obsługi wniosku, wąskie gardła i różnice w sprawności poszczególnych procesów wdrożenia.
Dlaczego to ważne
To podstawowy identyfikator sprawy, który łączy wszystkie powiązane działania i umożliwia analizę całego procesu wdrożenia klienta.
Skąd pobrać
Ten identyfikator jest zwykle kluczem głównym w głównej tabeli wniosków lub zarządzania sprawami w systemie Refinitiv World-Check albo zintegrowanym systemie CRM.
Przykłady
APP-2023-00123APP-2023-00124APP-2023-00125
|
|||
|
Czas zakończenia zdarzenia
EventEndTime
|
Znacznik czasu wskazujący, kiedy zakończyło się konkretne działanie lub zdarzenie. | ||
|
Opis
Czas zakończenia zdarzenia wskazuje, kiedy działanie dobiegło końca. Wiele zdarzeń można modelować jako chwilowe, gdy czas rozpoczęcia jest równy czasowi zakończenia. Niektóre działania mają jednak mierzalny czas trwania, na przykład „Rozpoczęto weryfikację przez analityka” i „Zakończono weryfikację przez analityka”. Zapis czasu rozpoczęcia i zakończenia pozwala dokładnie zmierzyć czas realizacji. W analizie procesu czas zakończenia jest niezbędny do obliczenia dokładnego czasu realizacji działania, bez czasu oczekiwania uwzględnianego w całkowitym czasie obsługi. Pozwala odróżnić czas aktywnej pracy nad sprawą od czasu, gdy sprawa czeka w kolejce. Ma to znaczenie przy optymalizacji zasobów i analizie sprawności.
Dlaczego to ważne
Pozwala dokładnie obliczyć czas realizacji działania i oddzielić aktywną pracę od oczekiwania, co zwiększa precyzję analizy wyników.
Skąd pobrać
W przypadku działań o określonym czasie trwania dane mogą być zapisane w osobnym polu, na przykład „CompletionDate” lub „EndDate”, w dzienniku zdarzeń albo tabelach ścieżki audytu.
Przykłady
2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
|
|||
|
Dział
DepartmentName
|
Dział lub zespół funkcyjny odpowiedzialny za wykonanie działania. | ||
|
Opis
Ten atrybut określa jednostkę biznesową lub zespół, do którego należy użytkownik, na przykład „Wdrożenia”, „Zgodność” lub „Kontrola jakości”. Umożliwia analizę na poziomie organizacyjnym, a nie tylko indywidualnym. Analiza według działów pomaga wykrywać wąskie gardła między zespołami i mierzyć czas przekazywania spraw. Pokazuje przepływ pracy między zespołami oraz miejsca, w których pojawiają się opóźnienia. Ułatwia usprawnianie współpracy między działami i poprawę sprawności całego procesu.
Dlaczego to ważne
Umożliwia analizę wyników procesu według działów i pomaga wykrywać opóźnienia przy przekazywaniu spraw między zespołami.
Skąd pobrać
Informacje te mogą być zapisane w profilu użytkownika w systemie lub w powiązanym systemie HR. Może być konieczne połączenie ich z danymi o zdarzeniach za pomocą identyfikatora użytkownika.
Przykłady
Zespół ds. wdrożeńWeryfikacja zgodnościKadra kierownicza wyższego szczebla
|
|||
|
Identyfikator osoby weryfikującej
ReviewerId
|
Identyfikator użytkownika, analityka lub agenta automatycznego, który wykonał działanie. | ||
|
Opis
Identyfikator osoby weryfikującej, czyli użytkownika, wskazuje, kto wykonał dane zadanie w procesie KYC. Może to być analityk ds. zgodności, specjalista ds. wdrożeń lub konto systemowe obsługujące działania automatyczne. Śledzenie tych informacji pokazuje rozkład obciążenia pracą i wyniki poszczególnych osób. Atrybut ten jest niezbędny do analizy wykorzystania zasobów. Pomaga porównywać wyniki użytkowników i zespołów, określać potrzeby szkoleniowe oraz równoważyć obciążenie pracą. Ułatwia też analizę przekazywania spraw, sieci współpracy i wykorzystania zasobów zespołu ds. zgodności.
Dlaczego to ważne
Umożliwia analizę rozkładu obciążenia pracą, wyników użytkowników i przekazywania spraw między działami, co pomaga lepiej wykorzystywać zasoby.
Skąd pobrać
Informacje te znajdują się zwykle w dziennikach zdarzeń lub ścieżkach audytu, często w polach „UserID”, „PerformedBy” lub „Owner”.
Przykłady
analityk_jdoesystem_automatycznej_weryfikacjikierownik_bsmith
|
|||
|
Poziom ryzyka
RiskLevel
|
Obliczona klasyfikacja ryzyka wniosku klienta, na przykład niskie, średnie lub wysokie. | ||
|
Opis
Poziom ryzyka to ważna informacja w procesach KYC, która określa wymagany zakres analizy due diligence. Często ustala się go na podstawie takich czynników jak typ klienta, lokalizacja geograficzna i charakter działalności. Klasyfikacja może znacząco wpływać na przebieg obsługi wniosku. W analizie procesu istotne jest grupowanie spraw według poziomu ryzyka. Pomaga to wyjaśnić różnice w czasie obsługi i przebiegu procesu. Na przykład wnioski wysokiego ryzyka mogą wymagać większej liczby etapów i dłuższej obsługi. Atrybut ten jest ważny w dashboardach „Odsetek i przyczyny odrzucenia wniosków” oraz „Czas rozpoczęcia weryfikacji” i pozwala ocenić wpływ ryzyka na wyniki i sprawność procesu.
Dlaczego to ważne
Podział procesu według poziomu ryzyka pomaga ustalić, dlaczego obsługa niektórych spraw trwa dłużej lub przebiega inaczej, a także analizować odsetek odrzuceń.
Skąd pobrać
To podstawowe pole w rekordzie wniosku klienta lub sprawy. Należy sprawdzić moduł zarządzania sprawami w Refinitiv World-Check.
Przykłady
NiskieŚrednieWysokie
|
|||
|
Termin realizacji SLA
SlaTargetDate
|
Termin, do którego należy zakończyć proces wdrożenia klienta. | ||
|
Opis
Termin realizacji SLA to data, do której należy zakończyć obsługę sprawy, zgodnie z umową o poziomie usług z klientem lub wewnętrznymi zasadami. Stanowi punkt odniesienia do pomiaru rzeczywistego czasu realizacji. Atrybut ten jest podstawą dashboardu „Realizacja SLA i analiza przekroczeń”. Pozwala obliczyć, czy sprawę zakończono w terminie. Analiza przekroczeń SLA pomaga wykrywać problemy systemowe powodujące opóźnienia oraz podejmować działania naprawcze, aby poprawić terminowość i zapewnić zgodność z wymaganiami.
Dlaczego to ważne
To punkt odniesienia przy pomiarze terminowości. Jest niezbędny do obliczania odsetka realizacji SLA i analizy przekroczeń.
Skąd pobrać
Termin jest często obliczany na podstawie daty złożenia wniosku i reguł biznesowych. Może być zapisany w polu rekordu sprawy.
Przykłady
2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
|
|||
|
Czy działanie jest automatyczne
IsAutomated
|
Wskazuje, czy działanie wykonał system (true), czy człowiek (false). | ||
|
Opis
Ten atrybut logiczny odróżnia zadania wykonywane automatycznie przez system od działań ręcznych użytkowników. Na przykład „Wykonano automatyczny screening” będzie oznaczone jako działanie automatyczne, a „Rozpoczęto analizę przez analityka” jako ręczne. To rozróżnienie jest niezbędne do analizy automatyzacji. Pozwala mierzyć jej wpływ na efektywność procesu, wskazywać zadania ręczne, które można zautomatyzować, oraz analizować współpracę ludzi z systemami. Ułatwia też oddzielne mierzenie czasu przetwarzania przez system i czasu obsługi ręcznej.
Dlaczego to ważne
Odróżnia działania systemu od działań człowieka. Dzięki temu można mierzyć wpływ automatyzacji i wskazywać kolejne możliwości jej zastosowania.
Skąd pobrać
Wartość zwykle ustala się na podstawie nazwy działania lub identyfikatora użytkownika przypisanego do zdarzenia, na przykład gdy użytkownikiem jest konto „systemowe”.
Przykłady
truefalse
|
|||
|
Czy wystąpiła ponowna praca
IsRework
|
Wskazuje, czy działanie wykonano w tej samej sprawie po raz drugi lub kolejny. | ||
|
Opis
IsRework to obliczany atrybut logiczny, który wskazuje powtórzenie działania w tej samej sprawie dotyczącej wniosku klienta. Jeśli na przykład działanie „Przeprowadzono ocenę ryzyka” wystąpi w jednej sprawie więcej niż raz, kolejne wystąpienia zostaną oznaczone jako ponowna praca. Atrybut pomaga wykrywać nieefektywne działania, pętle i niepotrzebne powtórzenia. Zasila dashboard „Powtórna ocena ryzyka i efektywność” oraz KPI „Wskaźnik powtórnej oceny ryzyka”. Analiza ponownej pracy pozwala wykryć problemy z jakością, jasnością informacji lub podejmowaniem decyzji, które prowadzą do niepotrzebnego wysiłku i wydłużają czas realizacji.
Dlaczego to ważne
Wskazuje powtarzające się działania i nieefektywne fragmenty procesu. Analiza pętli ponownej pracy pomaga poprawić jakość i skrócić czas realizacji.
Skąd pobrać
Wartość oblicza się podczas transformacji danych. Analizowana jest kolejność działań w każdej sprawie, a każde kolejne wystąpienie danego działania zostaje oznaczone.
Przykłady
truefalse
|
|||
|
Data ostatniej aktualizacji danych
LastDataUpdate
|
Znacznik czasu ostatniego odświeżenia danych dotyczących tego zdarzenia lub pobrania ich z systemu źródłowego. | ||
|
Opis
Ten atrybut informuje o aktualności danych. Zapisuje datę i godzinę ostatniego pobrania danych z Refinitiv World-Check. Pozwala ocenić, jak aktualne są dashboardy i analizy process mining. Dzięki temu użytkownicy wiedzą, czy analizują dane zbliżone do bieżących, czy migawkę z określonego momentu. Atrybut ma znaczenie dla zarządzania danymi i określania oczekiwań użytkowników co do aktualności przedstawionych wniosków.
Dlaczego to ważne
Informuje o aktualności danych, dzięki czemu użytkownicy wiedzą, na jakich danych opiera się analiza procesu.
Skąd pobrać
Ten znacznik czasu jest generowany i dodawany podczas pobierania danych w procesie ETL.
Przykłady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Identyfikator dopasowania
MatchId
|
Unikalny identyfikator potencjalnego dopasowania wykrytego podczas weryfikacji w World-Check. | ||
|
Opis
Gdy automatyczny screening wykryje potencjalne dopasowanie do list sankcyjnych, list PEP lub niekorzystnych informacji medialnych, często generowany jest identyfikator Match ID, który pozwala śledzić konkretne trafienie. Łączy on sprawę klienta z rekordem w bazie World-Check, który wywołał alert. Ten atrybut przydaje się do szczegółowej analizy zgodności. Analitycy mogą sprawdzić charakter dopasowań, śledzić sposób rozpatrywania alertów, na przykład potwierdzenie fałszywego trafienia lub rzeczywistego dopasowania, oraz ustalić, które alerty pojawiają się najczęściej lub najdłużej czekają na rozpatrzenie. Atrybut pozwala dokładniej analizować działanie „Wykryto potencjalne dopasowanie”.
Dlaczego to ważne
Łączy wyniki screeningu z konkretnymi rekordami, dzięki czemu można dokładniej analizować czas rozpatrywania dopasowań i rodzaje alertów.
Skąd pobrać
Ten identyfikator powinien być generowany przez silnik screeningowy World-Check i zapisywany w sprawie klienta po wykryciu potencjalnego dopasowania.
Przykłady
WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
|
|||
|
Identyfikator klienta
CustomerId
|
Unikalny identyfikator klienta obejmowanego procesem wdrożenia. | ||
|
Opis
Identyfikator klienta to unikalny identyfikator profilu klienta. Różni się od identyfikatora wniosku klienta, ponieważ jeden klient może składać wiele wniosków. Atrybut ten łączy proces wdrożenia z głównym rekordem klienta. W analizie identyfikator klienta pozwala śledzić kolejne wnioski tej samej osoby lub firmy. Można go też użyć do wzbogacenia danych o procesie o inne informacje z systemu CRM lub systemu danych podstawowych. Dzięki temu można analizować pełniejszy przebieg relacji z klientem, a nie tylko pojedynczy proces wdrożenia.
Dlaczego to ważne
Łączy sprawę wdrożeniową z konkretnym klientem, umożliwiając analizę kolejnych wniosków i uzupełnienie danych o informacje z głównego rekordu klienta.
Skąd pobrać
To ważne pole w rekordzie wniosku lub sprawy, które łączy go z głównymi danymi klienta.
Przykłady
CUST-98765CUST-98766CUST-98767
|
|||
|
Kanał złożenia wniosku
ApplicationChannel
|
Kanał, za pośrednictwem którego złożono wniosek klienta, na przykład portal internetowy, oddział lub aplikacja mobilna. | ||
|
Opis
Kanał złożenia wniosku wskazuje, skąd wpłynął wniosek klienta. Poszczególne kanały mogą różnić się kompletnością i jakością danych oraz profilem klientów, co wpływa na dalszy przebieg procesu. Atrybut ten jest niezbędny w dashboardzie „Liczba obsłużonych wniosków według kanału”. Analiza liczby wniosków, czasu obsługi i wyników dla poszczególnych kanałów pozwala ustalić, które działają najsprawniej, a które wymagają usprawnień. Wnioski z analizy pomagają podejmować decyzje o przydziale zasobów i inwestycjach w kanały.
Dlaczego to ważne
Pomaga analizować wyniki i sprawność poszczególnych kanałów składania wniosków, wspierając decyzje dotyczące technologii i obsługi klienta.
Skąd pobrać
Informacja jest zwykle zbierana na początku procesu i zapisywana jako atrybut w rekordzie wniosku.
Przykłady
Portal internetowyAplikacja mobilnaOddziałOpiekun klienta
|
|||
|
Kraj klienta
CustomerCountry
|
Kraj zamieszkania klienta lub kraj rejestracji jego firmy. | ||
|
Opis
Ten atrybut wskazuje lokalizację geograficzną klienta. Kraj ma duże znaczenie dla oceny ryzyka i wymagań regulacyjnych w procesach KYC. Przepisy różnią się w zależności od jurysdykcji, co może wpływać na przebieg i czas procesu. Analiza procesu według kraju pozwala porównywać wyniki w różnych regionach, wykrywać lokalne wąskie gardła i sprawdzać zgodność z miejscowymi przepisami. Ujęcie geograficzne może ujawnić istotne różnice operacyjne.
Dlaczego to ważne
Umożliwia analizę geograficzną procesu i pomaga wykrywać regionalne różnice w wynikach, ryzyku oraz wymaganiach dotyczących zgodności.
Skąd pobrać
To standardowe pole w profilu klienta lub formularzu wniosku.
Przykłady
USAGBRSGPDEU
|
|||
|
Naruszono SLA
SlaBreached
|
Wartość logiczna wskazująca, czy sprawę onboardingu zakończono po terminie określonym w SLA. | ||
|
Opis
Ten atrybut obliczany wskazuje, czy w danej sprawie doszło do naruszenia umowy o gwarantowanym poziomie usług. Wartość ustala się przez porównanie znacznika czasu ostatniego działania kończącego sprawę, na przykład „Zatwierdzono wniosek” lub „Odrzucono wniosek”, z polem „SlaTargetDate”. Na tej fladze opierają się dashboard „Analiza realizacji SLA i jego naruszeń” oraz KPI „Wskaźnik realizacji SLA”. Ułatwia ona analizę, ponieważ pozwala szybko odfiltrować wszystkie sprawy z naruszonym SLA. Analiza przebiegu tych spraw pomaga ustalić przyczyny opóźnień i lepiej ukierunkować działania usprawniające.
Dlaczego to ważne
Bezpośrednio mierzy zgodność z umowami o gwarantowanym poziomie usług. Ułatwia filtrowanie opóźnionych spraw i analizę ich przyczyn.
Skąd pobrać
Wartość oblicza się podczas transformacji danych, porównując znacznik czasu ostatniego działania w sprawie z polem SlaTargetDate.
Przykłady
truefalse
|
|||
|
Przyczyna odrzucenia
RejectionReason
|
Konkretna przyczyna podana przy odrzuceniu wniosku klienta. | ||
|
Opis
Gdy wniosek zostaje odrzucony, przyczyna odrzucenia wyjaśnia podjętą decyzję. Może to być na przykład „Dopasowanie do listy sankcyjnej”, „Niekompletna dokumentacja” lub „Wysoki profil ryzyka”. Informacje te dostarczają uporządkowanych danych o jakości otrzymywanych wniosków i skuteczności procesu weryfikacji. Atrybut ten jest podstawą dashboardu „Odsetek i przyczyny odrzucenia wniosków”. Analiza przyczyn pomaga znaleźć źródła odrzuceń, usprawnić proces, poprawić komunikację z wnioskodawcami i ograniczyć nieuzasadnione odrzucenia. Uzupełnia ilościowy KPI dotyczący odsetka odrzuceń o kontekst jakościowy.
Dlaczego to ważne
Wskazuje przyczyny odrzucania wniosków, co pomaga znaleźć obszary do poprawy w procesie wdrożenia klienta i ograniczyć odsetek odrzuceń.
Skąd pobrać
Informacja jest zapisywana przy zdarzeniu „Odrzucono wniosek”, prawdopodobnie w polu rekordu sprawy lub wniosku.
Przykłady
Dopasowanie do PEPTrafienie na liście sankcyjnejNiepowodzenie weryfikacji dokumentówNegatywne informacje w mediach
|
|||
|
System źródłowy
SourceSystem
|
System, z którego pobrano dane o zdarzeniach, w tym przypadku Refinitiv World-Check. | ||
|
Opis
Ten atrybut wskazuje źródło danych o procesie. Przy pobieraniu danych z jednego systemu jego wartość może być stała. Nabiera znaczenia, gdy łączy się dane z kilku systemów, na przykład CRM i World-Check, aby uzyskać pełny obraz procesu. W analizie pomaga zarządzać danymi, rozwiązywać problemy i rozumieć ich kontekst. Działania zapisane w głównym systemie weryfikacyjnym mogą mieć inne właściwości lub poziom szczegółowości niż dane z systemu pomocniczego. Atrybut zapewnia przejrzystość i możliwość audytu pochodzenia danych.
Dlaczego to ważne
Wskazuje źródło danych, co ma znaczenie dla zarządzania danymi, ich weryfikacji i łączenia informacji z wielu źródeł.
Skąd pobrać
Często jest to stała wartość dodawana podczas procesu pobierania, przekształcania i ładowania danych (ETL), aby oznaczyć zbiór danych.
Przykłady
Refinitiv World-CheckWorldCheckOne
|
|||
|
Typ klienta
CustomerType
|
Klasyfikacja klienta, na przykład osoba fizyczna, spółka lub trust. | ||
|
Opis
Typ klienta określa kategorię podmiotu obejmowanego procesem wdrożenia. Różne typy klientów często wiążą się z innymi wymaganiami, profilami ryzyka i obowiązkami regulacyjnymi. Na przykład wdrożenie spółki jest zwykle bardziej złożone niż wdrożenie osoby fizycznej. Atrybut ten służy do segmentacji, zwłaszcza w dashboardzie „Wyniki procesu KYC według typu klienta”. Pozwala porównywać sprawność procesu, czas obsługi i odsetek odrzuceń w różnych segmentach klientów. Dzięki temu można dostosować i usprawnić proces wdrożenia dla poszczególnych typów klientów.
Dlaczego to ważne
Umożliwia porównanie wyników w różnych segmentach klientów i pomaga dostosować oraz usprawnić proces wdrożenia dla każdego typu.
Skąd pobrać
To podstawowy atrybut zapisany w rekordzie klienta lub wniosku w systemie źródłowym.
Przykłady
Osoba fizycznaSpółkaOrganizacja non-profitTrust
|
|||
Działania w procesie onboardingu klientów KYC
| Działanie | Opis | ||
|---|---|---|---|
|
Aktywowano konto
|
Konto klienta zostaje utworzone i aktywowane w systemie podstawowym, co kończy proces wdrożenia. Następuje to po ostatecznym zatwierdzeniu wniosku i oznacza, że konto jest gotowe do użycia. | ||
|
Dlaczego to ważne
To ostatni etap procesu, który przynosi klientowi korzyść. Czas od złożenia wniosku do aktywacji konta jest ważnym miernikiem sprawności operacyjnej i zadowolenia klienta.
Skąd pobrać
To zdarzenie nie jest rejestrowane w World-Check. Zapisuje się je w podstawowym systemie bankowym lub systemie obsługi kont klientów, a następnie łączy z danymi za pomocą identyfikatora wniosku klienta.
Rejestrowanie
Zdarzenie rejestrowane w podstawowym systemie obsługi kont po aktywacji konta.
Typ zdarzenia
explicit
|
|||
|
Odrzucono wniosek
|
Wniosek klienta zostaje formalnie odrzucony, często z powodu wyniku „Wykryto dopasowanie” w World-Check lub innych czynników ryzyka. To końcowy negatywny wynik procesu wdrożenia klienta. | ||
|
Dlaczego to ważne
To główny punkt końcowy niepowodzenia procesu. Analiza odrzuconych wniosków, zwłaszcza przyczyn i poprzedzających je działań, pomaga ulepszać procesy i ograniczać nieuzasadnione odrzucenia.
Skąd pobrać
Ta ostateczna decyzja biznesowa jest zapisywana w nadrzędnym systemie CRM lub systemie obsługi wniosków, a nie w samym World-Check. Dane należy pobrać z tego systemu.
Rejestrowanie
Zdarzenie rejestrowane w systemie źródłowym, często wraz z kodem przyczyny odrzucenia.
Typ zdarzenia
explicit
|
|||
|
Potwierdzono prawdziwe dopasowanie
|
Analityk potwierdza, że potencjalne dopasowanie dotyczy weryfikowanego klienta, i identyfikuje możliwe ryzyko. To ważny etap, który zwykle prowadzi do rozszerzonej analizy due diligence lub odrzucenia wniosku. | ||
|
Dlaczego to ważne
To istotny wynik działań ograniczających ryzyko i przełomowy moment w procesie. Bezpośrednio wpływa na ostateczną decyzję dotyczącą wniosku klienta i ma duże znaczenie dla raportowania oraz analizy zgodności.
Skąd pobrać
Analityk jawnie oznacza konkretne dopasowanie jako „Prawdziwe dopasowanie” lub „Potwierdzone dopasowanie”. Zdarzenie jest zapisywane w ścieżce audytu sprawy.
Rejestrowanie
Zdarzenie jest rejestrowane, gdy analityk formalnie potwierdza dopasowanie w systemie.
Typ zdarzenia
explicit
|
|||
|
Rozpoczęto weryfikację przez analityka
|
Analityk ds. zgodności rozpoczyna ręczną analizę potencjalnych dopasowań dotyczących wniosku klienta. Porównuje szczegóły dopasowań z danymi klienta, aby ustalić, czy są istotne. | ||
|
Dlaczego to ważne
To początek ręcznej weryfikacji zgodności, która często staje się wąskim gardłem. Pomiar czasu od wykrycia potencjalnego dopasowania do tego etapu pokazuje opóźnienia w kolejce, a czas samej weryfikacji pozwala ocenić wydajność analityków.
Skąd pobrać
Zdarzenie można wywnioskować, gdy analityk przejmuje sprawę z kolejki weryfikacyjnej lub ją otwiera. System może też zapisać je bezpośrednio w ścieżce audytu, gdy status sprawy zmieni się na „W trakcie weryfikacji” lub sprawa zostanie przypisana konkretnemu użytkownikowi.
Rejestrowanie
Zdarzenie można wywnioskować ze zmiany statusu sprawy na „W trakcie weryfikacji” lub przypisania jej analitykowi.
Typ zdarzenia
inferred
|
|||
|
Utworzono zlecenie kontroli
|
W systemie Refinitiv World-Check zostaje formalnie utworzona nowa sprawa kontroli dotycząca wniosku klienta. Zdarzenie jest wywoływane przez żądanie API lub ręczny wpis z systemu źródłowego i oznacza rozpoczęcie kontroli ryzyka. | ||
|
Dlaczego to ważne
To oficjalny początek podprocesu weryfikacji. Czas między złożeniem wniosku a tym działaniem pokazuje opóźnienia przy przekazywaniu spraw między systemem biznesowym a działem ds. zgodności.
Skąd pobrać
Informacja jest zapisywana w dziennikach zarządzania sprawami World-Check lub ścieżce audytu. Wykorzystuje się zdarzenie utworzenia sprawy i jego znacznik czasu dla danego identyfikatora sprawy lub podmiotu.
Rejestrowanie
Zdarzenie jest rejestrowane automatycznie po utworzeniu nowej sprawy do weryfikacji w systemie.
Typ zdarzenia
explicit
|
|||
|
Zakończono weryfikację, wykryto dopasowanie
|
Sprawa weryfikacyjna zostaje oficjalnie zamknięta z wynikiem „Wykryto dopasowanie”, co oznacza potwierdzenie ryzyka. Decyzja uruchamia inny dalszy proces, na przykład rozszerzoną analizę due diligence lub odrzucenie wniosku. | ||
|
Dlaczego to ważne
To główny punkt końcowy niepomyślnej ścieżki weryfikacji. Analiza takich spraw pomaga zrozumieć profile ryzyka i skuteczność mechanizmów kontrolnych.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany końcowego statusu sprawy na „Wykryto dopasowanie”, „Zidentyfikowano ryzyko” lub „Zamknięto, wynik pozytywny”. Wykorzystuje się znacznik czasu tej zmiany.
Rejestrowanie
Zdarzenie wynika ze znacznika czasu końcowego statusu sprawy potwierdzającego dopasowanie.
Typ zdarzenia
inferred
|
|||
|
Zakończono weryfikację, wynik bez zastrzeżeń
|
Sprawa weryfikacyjna zostaje oficjalnie zamknięta z wynikiem „Bez zastrzeżeń”, co oznacza, że nie wykryto prawdziwych dopasowań. Decyzja jest przekazywana do systemu źródłowego, dzięki czemu proces wdrożenia klienta może być kontynuowany. | ||
|
Dlaczego to ważne
To pomyślne zakończenie standardowej ścieżki weryfikacji. Ten etap służy do pomiaru czasu obsługi standardowych wniosków o niskim poziomie ryzyka.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany końcowego statusu sprawy na „Bez zastrzeżeń”, „Zakończono” lub „Zamknięto, brak dopasowania”. Wykorzystuje się znacznik czasu tej zmiany.
Rejestrowanie
Zdarzenie wynika ze znacznika czasu końcowego statusu sprawy wskazującego wynik bez zastrzeżeń.
Typ zdarzenia
inferred
|
|||
|
Złożono wniosek
|
Ta czynność rozpoczyna proces onboardingu KYC, gdy klient składa wniosek. Zdarzenie jest zwykle rejestrowane w systemie CRM lub podstawowym systemie obsługi wniosków, który następnie uruchamia kontrolę w Refinitiv World-Check. | ||
|
Dlaczego to ważne
To główne zdarzenie rozpoczynające cały proces onboardingu klienta. Pomiar czasu od tego momentu do zakończenia procesu pozwala określić całkowity czas onboardingu, istotny przy ocenie doświadczeń klientów i realizacji SLA.
Skąd pobrać
To zdarzenie nie jest rejestrowane bezpośrednio w World-Check. Należy pobrać je z wcześniejszego systemu, na przykład CRM lub platformy do zarządzania kontami klientów, a następnie powiązać z identyfikatorem wniosku klienta.
Rejestrowanie
Zdarzenie zarejestrowane w systemie źródłowym w chwili złożenia wniosku.
Typ zdarzenia
explicit
|
|||
|
Poproszono o dodatkowe informacje
|
Analityk stwierdza, że do rozstrzygnięcia potencjalnego dopasowania potrzebne są dodatkowe informacje, i prosi o nie jednostkę biznesową. Sprawa pozostaje w oczekiwaniu do czasu otrzymania tych informacji. | ||
|
Dlaczego to ważne
Częste występowanie tego działania może wskazywać na niską jakość danych przekazywanych do weryfikacji. Powoduje ono znaczne opóźnienia, ponieważ wymaga współpracy z innymi zespołami, i wydłuża całkowity czas obsługi spraw.
Skąd pobrać
Może to być jawne działanie użytkownika zapisane w notatkach do sprawy lub dzienniku audytu. Można je też wywnioskować ze zmiany statusu sprawy na „Oczekuje na informacje” lub „RFI”.
Rejestrowanie
Zdarzenie jest rejestrowane, gdy analityk używa funkcji oznaczającej, że do sprawy potrzebne są dodatkowe informacje.
Typ zdarzenia
explicit
|
|||
|
Potwierdzono fałszywe dopasowanie
|
Analityk stwierdza, że potencjalne dopasowanie nie dotyczy weryfikowanego klienta. Dopasowanie zostaje odrzucone, a weryfikacja danego alertu zakończona. | ||
|
Dlaczego to ważne
To częsty wynik weryfikacji. Pomiar czasu potrzebnego na rozstrzygnięcie fałszywych dopasowań pozwala ocenić wydajność analityków i trafność automatycznej weryfikacji.
Skąd pobrać
Analityk jawnie oznacza konkretne dopasowanie jako „Fałszywe dopasowanie” lub „Brak dopasowania”. Działanie jest zwykle zapisywane w historii sprawy.
Rejestrowanie
Zdarzenie jest rejestrowane, gdy analityk formalnie odrzuca potencjalne dopasowanie w systemie.
Typ zdarzenia
explicit
|
|||
|
Przekazano sprawę do eskalacji
|
Analityk pierwszej linii przekazuje złożoną sprawę lub sprawę wysokiego ryzyka starszemu analitykowi albo kierownikowi, aby uzyskać ostateczną decyzję. To ważny punkt przekazania sprawy w zespole ds. zgodności. | ||
|
Dlaczego to ważne
Eskalacje często tworzą wąskie gardła i wydłużają czas obsługi spraw. Analiza ich częstotliwości i przyczyn może wskazać potrzeby szkoleniowe młodszych analityków lub niejasności w zasadach weryfikacji.
Skąd pobrać
Eskalacja jest zapisywana jako jawne działanie w workflow sprawy lub ścieżce audytu. Można ją też wywnioskować ze zmiany przypisanego użytkownika, zwłaszcza gdy sprawę przejmuje osoba z wyższymi uprawnieniami.
Rejestrowanie
Zdarzenie jest rejestrowane po użyciu przycisku „Eskaluj” lub wybraniu odpowiedniego działania w workflow sprawy.
Typ zdarzenia
explicit
|
|||
|
Przeprowadzono automatyczną weryfikację
|
System World-Check automatycznie porównuje dane klienta z bazą informacji o ryzyku. W wyniku tego działania systemowego powstaje wstępny zestaw wyników, na przykład potencjalne dopasowania lub status „bez zastrzeżeń”. | ||
|
Dlaczego to ważne
To pierwszy etap procesu weryfikacji, który przynosi wartość. Opóźnienia przed tym etapem mogą wskazywać na problemy z gotowością systemu lub danych, a wynik weryfikacji wpływa na późniejszy nakład pracy ręcznej.
Skąd pobrać
Zdarzenie może być zapisane bezpośrednio w ścieżce audytu sprawy albo wywnioskowane na podstawie znacznika czasu, gdy wstępne wyniki weryfikacji stają się dostępne.
Rejestrowanie
Wpis w dzienniku systemowym utworzony po zakończeniu automatycznego skanowania bazy danych.
Typ zdarzenia
explicit
|
|||
|
Wykryto potencjalne dopasowanie
|
Automatyczna weryfikacja wykryła co najmniej jedno potencjalne dopasowanie wymagające ręcznej oceny analityka. Sprawa przechodzi ze stanu automatycznej weryfikacji do kolejki ręcznej analizy. | ||
|
Dlaczego to ważne
To ważny punkt rozgałęzienia procesu. Sprawy z potencjalnymi dopasowaniami wymagają dłuższej i bardziej złożonej obsługi. Śledzenie tego etapu pomaga planować zasoby i analizować wąskie gardła w zespole weryfikacyjnym.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu sprawy na „Wymaga weryfikacji”, „Potencjalne dopasowanie” lub podobny status w module zarządzania sprawami World-Check.
Rejestrowanie
Zdarzenie wynika ze zmiany statusu sprawy wskazującej, że potrzebna jest ręczna weryfikacja.
Typ zdarzenia
inferred
|
|||
|
Zatwierdzono wniosek
|
Wniosek klienta został w pełni zatwierdzony po pomyślnej weryfikacji KYC i przeprowadzeniu pozostałych wymaganych kontroli. Zdarzenie to zwykle występuje w systemie źródłowym po otrzymaniu wyniku „Bez zastrzeżeń” z World-Check. | ||
|
Dlaczego to ważne
To pomyślny wynik biznesowy procesu wdrożenia klienta. Pomiar czasu od złożenia wniosku do tego etapu pokazuje, ile trwa uzyskanie zgody na przyjęcie nowego klienta.
Skąd pobrać
To zdarzenie nie jest rejestrowane w World-Check. Należy pobrać je z nadrzędnego systemu CRM lub systemu obsługi wniosków, w którym zapada ostateczna decyzja biznesowa.
Rejestrowanie
Zdarzenie rejestrowane w systemie źródłowym po ostatecznym zatwierdzeniu.
Typ zdarzenia
explicit
|
|||
Instrukcje ekstrakcji danych
Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu danych, aby rozpocząć process mining procesu onboardingu klientów KYC. Postępując zgodnie z tymi wskazówkami, można uzyskać przydatne informacje i usprawnić operacje.
Usprawnij onboarding klientów KYC i popraw zgodność
Uprość onboarding klientów i skróć go do 24 godzin.
Nie trzeba podawać danych karty płatniczej. Korzystaj bezpłatnie przez 14 dni.