STRUCT-LEI-CHECKSUM - cyfry kontrolne LEI (ISO 17442) (B_01.01, B_01.02, B_01.03, B_02.02, B_03.01, B_03.03, B_04.01, B_06.01)

Oficjalny tekst kontroli (EBA, verbatim)

Ta kontrola nie ma tekstu kontroli W1 EBA ani oficjalnej reguły W2: to produktowe zaostrzenie ponad reguły oficjalne (pomiar, N-13). Oficjalne reguły W2 dla LEI sprawdzają wyłącznie wzorzec formatu; cyfry kontrolne ISO 17442 (ostatnie dwie cyfry kodu) weryfikowane są tylko tutaj, pod tym syntetycznym identyfikatorem STRUCT - nigdy pod kodem oficjalnej reguły W2.

Co sprawdza ta reguła

Kontrola obejmuje te same 9 kolumn typu LEI co STRUCT-LEI-FORMAT (kolumny kluczowe identyfikatorów B_01.01, B_01.02, B_01.03, B_02.02, B_03.01, B_03.03, B_04.01, B_06.01 plus c0060 w B_01.02). Bada wyłącznie komórki, które już PRZESZŁY wzorzec formatu - komórka błędna formatem jest raportowana raz, przez STRUCT-LEI-FORMAT, i nigdy nie jest tu raportowana podwójnie.

Ostatnie dwie cyfry LEI to cyfry kontrolne wg ISO 17442 (mod 97-10, ten sam schemat co w numerach IBAN). Kod 20-znakowy, którego cyfry kontrolne się nie zgadzają, praktycznie zawsze oznacza błąd przepisywania: jeden znak przekręcony, dwa znaki zamienione miejscami albo uszkodzona kopia. Prawdziwy LEI ma poprawne cyfry kontrolne z konstrukcji.

Kontekst warstw: czy LEI rzeczywiście istnieje w bazie GLEIF, sprawdzają kontrole W3 (np. VR_2, VR_12), które nigdy nie blokują. Ta kontrola strukturalna łapie mechaniczne uszkodzenie wcześniej, zanim powstanie paczka.

To kontrola strukturalna w RoI Builderze (warstwa STRUCT, severity: blocking). Nie mapuje się na żadną kontrolę W1a/W1b u ESAs - oficjalna walidacja technicznie nie odrzuca paczki przy przyjęciu z tego powodu. RoI Builder blokuje na niej eksport finalny, więc problem zostaje wychwycony przed złożeniem.

Najczęstsze przyczyny

• LEI przepisano ręcznie i jeden znak wyszedł błędnie.
• Dwa znaki zamieniono miejscami albo zgubiono przy kopiowaniu między arkuszami.
• W prawdziwym wierszu został kod-wypełniacz o kształcie LEI (np. dummy z oficjalnej paczki przykładowej).

Jak to naprawić, krok po kroku

1. Otwórz wskazany szablon i znajdź wiersz - wynik walidacji podaje numer wiersza, wartości klucza i błędną wartość.
2. Wróć do źródła LEI i skopiuj pełny 20-znakowy kod jeszcze raz; wklej go w miejsce wskazanej komórki.
3. Nie "naprawiaj" pojedynczych znaków na oko - kod, który się zgadza, wciąż może być LEI niewłaściwego podmiotu; kopiowanie bije przepisywanie.
4. Uruchom walidację ponownie i potwierdź, że naruszenie zniknęło.

Przykład: błędnie vs poprawnie

Błędnie - kod pasuje do wzorca formatu, ale cyfry kontrolne się nie zgadzają; wynik walidacji wskazuje kolumnę c0010 tego wiersza B_01.02:

c0010 (LEI podmiotu)	c0020 (nazwa podmiotu)
DUMMYLEI123456789012	Bank Testowy A

DUMMYLEI123456789012 to kod-dummy oficjalnej paczki przykładowej - ma kształt LEI, ale nie jest prawdziwym LEI.

Poprawnie - prawdziwy LEI z poprawnymi cyframi kontrolnymi:

c0010 (LEI podmiotu)	c0020 (nazwa podmiotu)
549300Q5EH2NP82EPE32	Bank Testowy A

Przypadek brzegowy - 549300Q5EH2NP82EPE34a NIE jest tu badany: najpierw nie przechodzi wzorca formatu i raportuje go STRUCT-LEI-FORMAT.

Powiązane reguły

• STRUCT-LEI-FORMAT - pierwszy stopień na tych samych kolumnach: wzorzec 20 znaków; badane są tu tylko komórki, które go przechodzą.
• v8826_m - W2 (ostrzeżenie): oficjalne reguły LEI sprawdzają sam format - kod poprawny formatem o złych cyfrach kontrolnych przechodzi v8826_m (N-13).
• VR_12 - W3: istnienie LEI w bazie GLEIF (nigdy nie blokuje).
• VR_2 - W3: ta sama kontrola istnienia dla LEI podmiotu prowadzącego rejestr (B_01.01).