STRUCT-LEI-FORMAT - wartości LEI zgodne ze wzorcem formatu (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 osobnego oficjalnego tekstu kontroli W1 EBA: to mechanika produktowa warstwy strukturalnej (wzorce identyfikatorów, task blueprintu F2.E3.T1). Wzorzec poniżej to dokładnie ten wzorzec formatu LEI, który sprawdzają oficjalne reguły W2 (pomiar, N-13), stosowany tu per komórka:

^[A-Z0-9]{18}[0-9]{2}$

Naruszenie niesie wyłącznie ten syntetyczny identyfikator STRUCT, nigdy kod oficjalnej reguły W2 (N-13).

Co sprawdza ta reguła

Kontrola obejmuje kolumny typu LEI. Pomiar w eba-4.0-errata5: 9 kolumn - kolumny kluczowe identyfikatorów c0010 w B_01.01 i B_01.02, c0020 w B_01.03, B_02.02, B_03.01, B_03.03 i B_04.01, c0040 w B_06.01 - plus kolumna danych c0060 (LEI bezpośredniej jednostki dominującej podmiotu) w B_01.02. Wyborem kolumn steruje typ danych z metadanych.

Każda niepusta komórka musi pasować do wzorca: dokładnie 20 znaków, pierwsze 18 z zakresu A-Z i 0-9, ostatnie 2 to cyfry. Małe litery, spacje, zła długość albo znaki interpunkcyjne nie przechodzą. Pusta komórka jest tu pomijana - pustość kluczowych kolumn LEI to STRUCT-MANDATORY.

Kontekst warstw: u ESAs ten sam wzorzec sprawdzają reguły W2 (ranga ostrzeżenia - np. v8891_m dla klucza B_01.02, v8826_m dla LEI jednostki dominującej). RoI Builder dodatkowo uruchamia wzorzec na blokującej warstwie strukturalnej, żeby zniekształcony identyfikator zatrzymać, zanim powstanie paczka. Cyfry kontrolne to osobna kontrola (STRUCT-LEI-CHECKSUM); istnienie LEI w bazie GLEIF to kontrola W3 (np. VR_12), która nigdy nie blokuje.

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

• Kod ucięty albo za długi po kopiowaniu - LEI musi mieć dokładnie 20 znaków.
• Małe litery (wzorzec przyjmuje tylko wielkie) albo spacje wokół kodu lub w środku.
• Inny identyfikator (numer rejestrowy krajowy, kod wewnętrzny) wklejony do kolumny LEI.

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. Skopiuj 20-znakowy LEI podmiotu ze źródła i wklej do wskazanej komórki; usuń spacje, zamień na wielkie litery.
3. Jeśli identyfikator podmiotu w ogóle nie jest LEI, nie należy do kolumny typu LEI - sprawdź, który wiersz edytujesz.
4. Uruchom walidację ponownie; kod poprawny formatem sprawdza następnie STRUCT-LEI-CHECKSUM.

Przykład: błędnie vs poprawnie

Błędnie - 21 znaków i mała litera na końcu; wynik walidacji wskazuje kolumnę c0010 tego wiersza B_01.02:

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

Poprawnie - 20-znakowy LEI pasujący do wzorca:

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

Poprawnie (przypadek brzegowy) - pusta komórka c0060 (LEI bezpośredniej jednostki dominującej) w B_01.02: ta kontrola formatu pomija puste komórki; pustość kolumn KLUCZOWYCH blokuje STRUCT-MANDATORY.

Powiązane reguły

• STRUCT-LEI-CHECKSUM - drugi stopień na tych samych kolumnach: kod poprawny formatem musi mieć też poprawne cyfry kontrolne ISO 17442.
• v8891_m - W2 (ostrzeżenie): klucz c0010 każdego wiersza B_01.02 musi pasować do tego samego wzorca LEI.
• v8826_m - W2 (ostrzeżenie): wypełniony LEI jednostki dominującej (c0060 w B_01.02) musi pasować do tego samego wzorca.
• VR_12 - W3: LEI wiersza B_01.02 musi mieć rekord w bazie GLEIF (nigdy nie blokuje).