Aktuální témata · úvěrové riziko

Riziková data v roce 2026: proč nestačí opravit jeden report

Ing. Petra Hradecká, MBA · Redakční datum: · ≈ 6 min

Aktualizace dohledových materiálů otevírá téma správy dat, jejich rozsahu a návaznosti mezi systémy.

Zrevidováno a rozšířeno 28. října 2026. Příklady popisují doložené události; navržený postup představuje mou vlastní analytickou úvahu.

Riziková data v roce 2026: proč nestačí opravit jeden report

Jedna opravená buňka nemusí znamenat kvalitní data

Chyba v rizikovém reportu často vyvolá rychlou a pochopitelnou reakci: opravit číslo a odeslat správnou verzi. Tím lze obnovit konkrétní výstup, ale nemusí se odstranit mechanismus, který chybu vytvořil. Pokud se stejný údaj používá ve více procesech, může nesrovnalost dál ovlivňovat jiné přehledy. Při analýze bych se proto ptala také na původ, význam, vlastníka a další využití údaje.

Téma roku 2026 bych nespojovala pouze s novým dokumentem nebo technologií. Základní otázka zůstává praktická: dokážeme včas získat a vysvětlit podklady pro důležité rozhodnutí? Nový nástroj může kontrolu usnadnit, nemůže však sám sjednotit obchodní definice ani určit, kdo rozhoduje o sporné výjimce. Tyto souvislosti je potřeba zachytit ještě před prezentací výsledné tabulky.

Ověřený podnět z roku 2026

Basel Committee zveřejnil 6. ledna 2026 newsletter k zavádění principů BCBS 239. Dokument se zabývá přetrvávajícími potížemi v agregaci a reportingu rizikových dat. Výslovně nejde o nové dohledové pokyny. Proto jej nepředstavuji jako nový právní požadavek účinný od ledna; používám jej jako aktuální podnět k vlastní analýze. [1]

Skutečný případ: Citigroup, Spojené státy, červenec 2024

Federal Reserve dne 10. července 2024 uložil Citigroup sankci za nedostatečné plnění nápravného opatření z roku 2020. Uvedl přetrvávající nedostatky v kvalitě dat a neúčinné kompenzační kontroly. To jsou doložená zjištění amerického regulátora, nikoli moje hodnocení současného stavu banky. [2]

Z případu si pro vlastní práci odnáším rozlišení mezi deklarovaným programem nápravy a prokázanou účinností jednotlivých kontrol. Ani rozsáhlý projekt automaticky nevysvětluje, zda jeho výsledek chrání konkrétní rozhodnutí. Počet dokončených úkolů bych proto doplnila otázkou, která rizika přestala vznikat, které výjimky zůstávají a jak se s nimi do dokončení systémové změny zachází.

Modelový příklad: nesprávná skupina klienta

Představme si fiktivní úvěrové portfolio o objemu 12 miliard Kč. Pět smluv za celkem 240 milionů Kč je v jednom přehledu přiřazeno jednotlivým firmám a ve druhém správně společné ekonomické skupině. Oba reporty mohou mít stejnou celkovou částku. Rozdíl se objeví až při pohledu na koncentraci, protože přiřazení mění rozložení, nikoli velikost portfolia.

Oprava pěti řádků v závěrečném souboru může pomoci jedné poradě. Pokud však zdrojová vazba zůstane nesprávná, další den se problém vrátí. Zajímalo by mě, zda se stejná vazba používá pro limity, interní segmentaci a další výstupy. Částky jsou pouze modelové a nedokládají překročení regulatorního limitu; k takovému závěru by chyběl širší právní a datový kontext.

Jak bych popsala datovou cestu

U vybraného kritického údaje bych vytvořila přehled zdrojového pole, transformačních pravidel, rozhodných dat a míst, kde se mění význam. Potřebovala bych odlišit technického správce systému od člověka odpovědného za obchodní definici. Správce může zajistit přenos hodnoty, ale nemusí mít oprávnění rozhodnout, které firmy mají být společně posuzovány.

Do mapy bych zahrnula také ruční úpravy. Nejsou automaticky chybou; nezdokumentovaný zásah však oslabuje opakovatelnost výsledku. Zajímalo by mě, kdo může hodnotu měnit, podle jakého důkazu, s jakým schválením a zda je později možné obnovit původní stav. Ruční oprava by neměla neviditelně nahradit původní údaj ve všech historických výstupech.

Kontrola musí mít vysvětlitelný účel

Každou datovou kontrolu bych spojila s otázkou, kterou chrání. Kontrola prázdné hodnoty ještě neprokazuje správnost neprázdné hodnoty. Kontrola součtu neověřuje rozložení a kontrola formátu neověřuje aktuálnost. U několika důležitých atributů bych raději jasně popsala kombinaci pravidel než prezentovala dlouhý seznam technických testů bez vztahu k rozhodnutí.

Při vyhodnocení výjimek bych rozlišila oprávněné zvláštní případy, skutečné chyby a dosud nevyjasněné situace. Neznámá příčina potřebuje vlastníka a termín prověření. Pokud se výjimka jen přesune do jiné kategorie, počet otevřených chyb sice klesne, ale spolehlivost podkladu se nemusí změnit. Metrika proto musí ukazovat i stáří a význam neuzavřených případů.

Prokázat opravu i její dosah

Nápravu bych ověřovala návratem k původnímu záznamu a následným průchodem všech dotčených výstupů. Nestačilo by mi nové číslo v jednom souboru. Chtěla bych vidět, že zdrojová definice, transformační pravidlo a kontrola výjimek dávají dohromady vysvětlitelný výsledek. Současně bych ověřila, zda změna nerozbila správné případy s jiným datem nebo typem klienta.

Pokud systémová oprava trvá déle, navrhla bych dočasný dohledatelný postup. Musí být jasné, jaké riziko pokrývá, co nepokrývá a kdy skončí. Dlouhodobá náhrada bez kontroly se může stát dalším neřízeným zdrojem dat. Při předání vedení bych proto oddělila současnou ochranu rozhodnutí od cílového řešení a nepředstírala, že jde o totéž.

Shrnutí a doporučení

Kvalitní riziková data potřebují správný význam, úplný přenos, jasné vlastnictví a kontrolu využití. Doporučila bych začít u několika údajů, které mají největší dopad na rozhodování, zdokumentovat jejich cestu a ověřit nápravu přes více výstupů. Úspěch bych neposuzovala pouze podle počtu uzavřených úkolů nebo zeleného celkového skóre.

Moje analytická úloha by spočívala v propojování odborné definice, technického zpracování a konkrétního důkazu. U tématu rizikových dat bych chtěla být přesná i v práci se zdroji: newsletter, dohledový průvodce a závazné pravidlo nejsou stejné typy dokumentu. Správná klasifikace zdroje pomáhá formulovat přiměřený závěr a předcházet nedorozumění při jeho předávání.

Jak bych zabránila opravě pouze na papíře

U modelového přiřazení klientů do skupin bych po nápravě vybrala nové i historické záznamy. Ověřila bych, zda při běžném zpracování vzniká správný výsledek bez dodatečného ručního zásahu. Význam má také čas kontroly. Pokud se správná hodnota objeví až po odeslání reportu, může být technický úkol hotový, ale původní riziko pro rozhodování zůstává. Kritérium úspěchu proto musí odpovídat skutečnému okamžiku použití údaje.

Další otázkou by byla udržitelnost vlastnictví. Odpovědnost napsaná u jména člověka nestačí, pokud nemá pravomoc požadovat opravu ve zdroji nebo potřebnou kapacitu pro výjimky. Zajímalo by mě, jak se problém řeší při jeho nepřítomnosti a kdy se eskaluje. Zápis role, zastupitelnosti a rozhodovací hranice může předejít tomu, že se opakovaná nesrovnalost ztratí mezi dvěma týmy, které ji oba považují za cizí.

U přehledu pro vedení bych vedle chyb zobrazila významná omezení analýzy. Například kontrola vztahů mezi firmami může pokrývat jen část portfolia nebo jen určitý zdroj vazeb. Pokud je tento rozsah skrytý, zelená barva snadno vytváří širší důvěru, než důkazy opravňují. Výsledkem má být přiměřená jistota o definované oblasti, nikoli neurčitý příslib bezchybných dat v celé instituci.

Nakonec bych předem stanovila, jak se kontrola aktualizuje při změně zdroje, produktu nebo definice. Jednou správně vytvořené pravidlo nemusí zůstat správné navždy. Připojení kontroly ke konkrétnímu vlastníkovi změny pomáhá zachovat její význam a současně omezuje zbytečná hlášení. Tím se prevence stává součástí běžné práce, místo aby po každé změně začínalo nové ruční pátrání po původu rozdílu.

U datového pravidla bych rozlišovala správnost definice a správnost provedení. Kontrola může bezchybně počítat ukazatel, který neodpovídá rozhodovací potřebě. Proto bych do přezkumu zapojila vlastníka významu údaje i technického vlastníka zpracování. Společně by potvrdili, že sledovaný výsledek zachovává obchodní smysl od původního zdroje až po konečné použití v reportu.

Zdroje a další čtení

  1. BCBS: Implementation of BCBS 239, 6 January 2026
  2. Federal Reserve: Citigroup enforcement, 10 July 2024

← Všechny články

← Všechny články