GATE — Weryfikacja.
Kto może wejść do ekosystemu. GATE udostępnia hostowane KYC i powierzchnie stron oraz ma łączyć weryfikację, screening i przegląd — zależnie od dostawcy, flagi, danych i zakresu integracji.
Za co odpowiada GATE
- Hostowane KYC i odczyt stron; tiering KYB, dyrektorzy i własność są celem projektowym, natomiast UBO nie ma w zweryfikowanym UI
- Hostowana weryfikacja white-label i osadzenie API-led, każde zależne od wybranego dostawcy i integracji
- Pola dokumentów, pochodzenia, notatek recenzenta i uzasadnienia tylko tam, gdzie proces je zapisuje
- Projektowane triggery step-up i re-weryfikacji, zależne od skonfigurowanych reguł i dostępnych zdarzeń
Architektura docelowa łączy weryfikację GATE ze screeningiem SENTINEL, sprawami DOCKET i dowodami VAULT. W zweryfikowanym statusie kolejka przeglądu KYC jest za flagą, UBO nie występuje, screening używa oznaczonego źródła demonstracyjnego, a przekazanie i zakres audytu trzeba sprawdzić zamiast zakładać.
Projektowany przepływ decyzji onboardingowej
Utwórz stronę (party)
Skonfigurowana rejestracja lub wniosek KYB może utworzyć osobę lub firmę z faktycznie dostarczonymi danymi i dokumentami; obecnego UI nie wolno przedstawiać jako rejestrującego UBO.
Przydziel tier
Projektowana polityka może nadać tier weryfikacji na podstawie aktywności i ryzyka. Uzasadnienie zapisuj tylko tam, gdzie silnik udostępnia takie pole.
Screening
SENTINEL może dostarczyć wyniki screeningu po integracji zatwierdzonego dostawcy lub źródła list. Zweryfikowane źródło jest oznaczoną listą demonstracyjną, nie kompletnym pokryciem sankcji, PEP czy adverse media.
Zastosuj politykę
Skonfigurowane reguły geograficzne, wiekowe i produktowe mogą zostać ocenione na dostępnych, zweryfikowanych danych; zakres zależy od polityki i źródła.
Decyzja
Akceptacja, przegląd, step-up lub blokada mogą trafić do Decision Record z wyłącznie zapisanymi polami uzasadnienia oraz do DOCKET, jeśli integracja jest włączona.
Praca z kolejką przeglądu KYC
Compliance Console → Weryfikacja → Kolejka przeglądu jest w zweryfikowanym statusie ścieżką projektowaną i za flagą, a nie powszechnie dostępnym kompletnym procesem. Po włączeniu sprawdź, które dokumenty, dane wyekstrahowane, wyniki screeningu, pola SLA i akcje są obecne. Uzasadnienie nadpisania zapisuj tylko wtedy, gdy proces rzeczywiście je rejestruje i przechowuje.
Ponowna weryfikacja i EDD
Wskaźniki ryzyka można projektować jako triggery EDD, ponownego screeningu lub re-weryfikacji. Dostępność, harmonogram i pola przyczyn zależą od skonfigurowanych reguł, danych dostawcy i kolejki za flagą; widoczna akcja nie dowodzi kompletnego procesu end-to-end.
Używaj wyłącznie dowodów, metadanych, notatek, uzasadnień i pochodzenia faktycznie przechwyconych przez proces. W zweryfikowanym GATE nie ma UBO, a kolejka przeglądu jest za flagą, więc pakiet może być niekompletny dla celu KYB bez dodatkowych, zweryfikowanych rekordów.
Przepływ hostowany vs API-only
Zaobserwowana powierzchnia hostowanego KYC może wspierać brandowaną ścieżkę tam, gdzie ją skonfigurowano. Implementacja API-led może przenieść większą część doświadczenia do Twojego produktu, ale zakres dostawcy, przejścia stanów, retencję, dowody i wysiłek integracyjny trzeba ustalić i sprawdzić; żadna ścieżka nie jest uniwersalnie najszybsza ani kompletna.
Chcesz cały podręcznik jako PDF? Zostaw nam swój e-mail, a prześlemy go.
Poproś o podręcznik