Czternaście modułów. Trzy pierścienie. Jeden rejestr.

GATE służy do określenia, kto lub jaki podmiot podlega przeglądowi, co rzeczywiście zarejestrowano i który warunek pozostaje otwarty. Sam w sobie nie potwierdza kompletnego programu KYC/KYB, procesu UBO ani ogólnie dostępnej usługi onboardingowej.

Obecna powierzchnia: hostowane odczyty KYC i danych podmiotów; przegląd jest za flagą funkcji; rejestracja UBO nie występuje w zweryfikowanym stanie.

• Zaobserwowane hostowane powierzchnie UI/odczytu KYC i danych podmiotów
• Ścieżka przeglądu znajduje się za flagą funkcji i nie jest zakładana dla każdego tenanta
• Rejestracji UBO nie ma w zweryfikowanym stanie; pozostaje wymaganiem do walidacji
• Projektowany do przekazywania zarejestrowanego kontekstu tożsamości do screeningu, polityk i obsługi spraw
• Step-up, ponowna weryfikacja i obsługa dowodów dokumentowych wymagają konfiguracji dla konkretnej ścieżki

PULSE ma łączyć dostępne sygnały ryzyka z decyzją, którą można zakwestionować. W zweryfikowanym stanie uczciwą propozycją jest eksploracyjny interfejs z częściowym uzasadnieniem — nie kompletny scoring w czasie rzeczywistym, uniwersalne wyjaśnienie ani dowiedzione wyniki fraudowe.

Obecna powierzchnia: Decision Explorer z częściowym uzasadnieniem; wskaźnik ML jest stubem, a nie deklaracją aktywnego modelu.

• Zaobserwowany Decision Explorer i częściowe powierzchnie UI/odczytu uzasadnienia
• Wzorzec decyzji rules-first; każde użycie modelu jest opcjonalne i wymaga odrębnej walidacji
• Obecny wskaźnik ML jest stubem i nie może być przedstawiany jako aktywny model
• Projektowane działania obejmują akceptację, step-up, przegląd i wstrzymanie, gdy zostały skonfigurowane
• Brakujące dane wejściowe, progi lub wersje pozostają jawne zamiast być wywnioskowywane

SWITCH uwidacznia proponowaną trasę, wstrzymany ruch i dostępny kontekst ścieżki. Ograniczone ćwiczenie może sprawdzić wzorzec kontroli, lecz rzeczywiste połączenia z PSP, jakość routingu, odporność i poziomy usług wymagają odrębnego potwierdzenia.

Obecna powierzchnia: częściowa konfiguracja routingu i odczyty śladu ścieżki płatności; nie wynika z niej rzeczywisty dostawca ani automatyczny failover.

• Zaobserwowane częściowe powierzchnie UI/odczytu konfiguracji routingu
• Zaobserwowane odczyty śladu ścieżki płatności dla dostępnych danych testowych
• Projektowane czynniki routingu obejmują stan dostawcy, kwalifikację, geografię, koszt i kontekst ryzyka
• Wypłaty, ponowienia i fallback zależą od podłączonych dostawców oraz zwalidowanej polityki
• Interfejs nie potwierdza ruchu produkcyjnego, redundancji dostawców ani automatycznego failoveru

LEDGER może stanowić mocny punkt odniesienia dla finansów, gdy dostępne są źródło, stan zapisu i kontekst rekoncyliacji. Wynik podatkowy pozostaje obliczeniem zależnym od danych: jurysdykcję, źródło stawki, datę podstawy i przeznaczenie raportu trzeba zwalidować, a nie zakładać.

Obecna powierzchnia: księgi są najsilniejszym zaobserwowanym obszarem; stawki podatkowe są statyczne i trzeba pokazywać datę ich podstawy.

• Zaobserwowane powierzchnie UI/odczytu ksiąg i finansów
• Statyczne stawki podatkowe w zweryfikowanym stanie; zawsze pokazuj właściwą datę podstawy stawki
• Projektowany do zachowywania danych podatkowych, podstawy i wyniku jako datowanej migawki decyzji
• Rekoncyliacja, portfele i eksporty zależą od procesu oraz integracji
• Bez twierdzeń o automatycznym składaniu deklaracji, uniwersalnej poprawności podatku lub niezmiennych księgach

SENTINEL ma odpowiadać, jaka polityka i jakie rozstrzygnięcie wpłynęły na działanie. Zweryfikowana powierzchnia może zademonstrować ten wzorzec kontroli, lecz nie kompletność list sankcyjnych, uniwersalną zasadę czterech oczu, automatyczne egzekwowanie ani zgodność regulacyjną.

Obecna powierzchnia: odczyty screeningu i polityk korzystają z listy DEMO; zakres list i rzeczywiste feedy nie są potwierdzone.

• Zaobserwowane powierzchnie UI/odczytu screeningu i polityk
• Obecnym źródłem screeningu jest lista DEMO i musi być tak oznaczona
• Projektowany kontekst polityki obejmuje warunki geograficzne, produktowe, wiekowe i dotyczące metod płatności
• Wersjonowanie, zatwierdzanie i rollback zależą od skonfigurowanego procesu governance
• Dostarczenie reguł do runtime'u i zewnętrzne feedy screeningowe wymagają integracji oraz walidacji

PRISM może pomóc sprawdzić podczas pilotażu, czy te same zarejestrowane fakty dają użyteczny widok operacyjny i dowodowy. Odtwarzalność zależy od kompletnych danych źródłowych, definicji, wersji i logiki eksportu; obecny interfejs nie dowodzi cyklicznego raportowania produkcyjnego.

Obecna powierzchnia: dashboardy i scorecardy generowane na żądanie; raportowanie cykliczne, monitoring SLA i materiały gotowe dla regulatora nie są potwierdzone.

• Zaobserwowane powierzchnie UI/odczytu dashboardów dla dostępnych danych operacyjnych
• W zweryfikowanym stanie scorecardy generuje się na żądanie, a nie automatycznie według harmonogramu
• Projektowane porównania wymagają uzgodnionej bazy, definicji i okresu raportowego
• Kwestionariusze i eksporty zależą od celu, roli i danych źródłowych
• Nie deklarujemy publicznego monitoringu SLA, raportów gotowych dla regulatora ani wyników KPI klientów