Úvěrové riziko bývá spojováno s ratingem, pravděpodobností selhání nebo výší ztráty. Před každým takovým výsledkem však stojí konkrétní údaje a rozhodnutí o jejich významu. Je splátka skutečně po splatnosti, nebo byla přiřazena k nesprávné smlouvě? Je uvedený příjem aktuální? Patří dvě firmy do stejné skupiny? Moje dosavadní zkušenost se týká analýzy dat, integračních a statistických systémů a ověřování výstupů. Řízení úvěrového rizika je směr, ve kterém se chci dále rozvíjet; tento text proto představuje návrh analytického přístupu, nikoli tvrzení o mé práci úvěrového specialisty.
Skutečný případ: datová kvalita v Citigroup
Americký Federal Reserve oznámil 10. července 2024 pokutu 60,6 milionu dolarů pro Citigroup. Důvodem byl nedostatečný postup při nápravě datové kvality a nedostatečné kompenzační kontroly v souvislosti s opatřením z roku 2020. To dokládá oficiální zpráva. Nevyvozuji z ní konkrétní chybu v úvěrovém modelu ani dnešní stav banky. Jde o historický příklad, že velký nápravný program sám ještě nedokazuje funkčnost datových kontrol.
Pro vlastní uvažování bych z případu oddělila dvě otázky: co má být dlouhodobě opraveno a jak je mezitím ošetřeno zbývající riziko. Pokud se čeká na nový systém, reporty vznikají dál. Je potřeba vědět, které údaje lze použít bez výhrad, které mají známé omezení a jak se omezení projeví v rozhodnutí. Dočasná kontrola má mít popsaný rozsah, vlastníka a důkaz provedení. Nestačí její existence v prezentaci programu. Tato úvaha je moje, nikoli dodatečné zjištění o Citigroup.
Nejdříve vyjasnit, co údaj znamená
Při přípravě kontroly bych se ptala na definici, rozhodný okamžik a zdroj. Výše úvěru může znamenat původně sjednanou částku, aktuální čerpání nebo celkový příslib. Nesprávné propojení těchto významů může vytvořit zdánlivý rozpor, který není početní chybou. Stejně tak je potřeba rozlišit účetní zůstatek, dostupný limit a zajištěnou část. V datovém slovníku bych proto chtěla nejen název pole a typ, ale i příklad výpočtu a pravidlo pro výjimky. Potom lze smysluplně porovnávat jednotlivé systémy.
Další rozlišení se týká prázdné hodnoty. Prázdné pole může znamenat neznámý údaj, nepoužitelný ukazatel, chybu přenosu nebo údaj čekající na ověření. Nula je naopak konkrétní hodnota. Pokud se vše při importu sjednotí na nulu, získáme technicky úplnou tabulku, ale ztratíme informaci o nejistotě. Za dobrou kontrolu bych nepovažovala jen zákaz prázdných buněk. Chtěla bych vědět, zda systém umí jednotlivé důvody rozlišit a zda uživatel při rozhodování vidí podstatné omezení.
Modelový příklad: stejný ukazatel, jiná jistota
Představme si hypotetické portfolio 1 000 podnikových úvěrů. U 900 je datum posledních finančních výkazů ověřeno, u 70 převzato bez kontroly a u 30 chybí. Celkový průměr ratingu může vypadat stabilně. Než bych jej interpretovala, rozdělila bych soubor podle kvality podkladů. Pokud je dvacet z třiceti chybějících záznamů v jediném odvětví, chybovost 3 % sama problém nevystihuje. Zajímalo by mě, zda právě tato skupina ovlivňuje závěr, a jak velká je její expozice.
Do příkladu přidejme celkovou expozici dvě miliardy Kč. Třicet neúplných záznamů může představovat 60 milionů, ale také 600 milionů. Obě situace mají stejný počet chyb a jinou rozhodovací závažnost. Výsledek bych proto vyjádřila počtem případů, objemem i koncentrací. Neukládala bych automaticky všem chybějícím údajům nejhorší hodnotu; o vhodném odborném zacházení by rozhodl vlastník metodiky. Mým úkolem by bylo zpřístupnit podklady a citlivost výsledku, aby rozhodnutí nebylo založeno na skryté domněnce.
Jak bych propojila odborný a technický pohled
Vybrala bych malý počet záznamů a sledovala je od původního dokumentu přes zpracování až k reportu. U každého přechodu bych zaznamenala identifikátor, čas a použité pravidlo. Pokud nesouhlasí report s dokumentem, chtěla bych najít první místo rozdílu. Může jít o mapování kategorie, opožděnou aktualizaci nebo oprávněné použití jiného období. Technickou správnost by potvrdilo IT, význam pravidla odborný útvar. Analytický popis má umožnit oběma stranám mluvit o stejném případu místo obecného tvrzení, že data nesedí.
U automatické kontroly bych se ptala také na její vlastní limity. Kontrola, že rating není prázdný, nezaručuje aktuálnost ratingu. Kontrola povoleného intervalu nezaručuje správné přiřazení klientovi. Vytvořila bych proto negativní testy: prohozené identifikátory, zastaralý podklad, duplicitní smlouvu a změnu skupinové příslušnosti. U každého případu bych předem napsala očekávanou reakci. Důležité není vyrobit co nejvíce chybových hlášení, ale prokázat, že kontrola odhalí situaci, proti které má chránit, a rozumně zachází s výjimkami.
Oprava pole versus oprava procesu
Jednorázovou opravu bych chtěla doplnit vysvětlením příčiny. Kdo a kdy si má všimnout neaktuálního podkladu? Co se stane, pokud aktualizace nepřijde? Jak se přerušený přenos projeví uživateli? U pravidelných kontrol bych sledovala nejen počet nevyřešených výjimek, ale i jejich stáří, opakování a odpovědnost. Pokud se stejná chyba každý měsíc ručně opravuje, může být výsledný report správný, zatímco proces zůstává křehký. Takovou skutečnost bych popsala samostatně, bez zaměňování kvality výsledku a spolehlivosti postupu.
Pro předání zjištění bych použila konkrétní větu: které údaje se liší, v jaké populaci, jakým porovnáním bylo zjištění podloženo a co zatím nevíme. Dopad bych nepřeháněla: chybný vstup nemusí automaticky změnit úvěrové rozhodnutí. Někdy jej zachytí jiná kontrola nebo pracuje model s odlišným zdrojem. Právě proto bych dohledala skutečného příjemce údaje a ověřila navazující použití. Záznam, který obsahuje omezení závěru, je pro tým důvěryhodnější než silné tvrzení bez znalosti datové cesty.
Od zjištění k opravě
U opravy dat bych požadovala rozlišení mezi jednotlivým záznamem a pravidlem, které jej vytvořilo. Ruční doplnění hodnoty může pomoci konkrétnímu reportu, ale neřeší opakovaný přenos ze stejného zdroje. Navrhla bych proto dohledat nejbližší místo, kde lze chybě zabránit, a zároveň zjistit, které historické výstupy mohla ovlivnit. Rozsah zpětné kontroly bych odvodila od použití údaje, nikoli pouze od počtu chybných řádků. Několik nesprávných expozic může mít větší význam než mnoho drobných technických nesrovnalostí.
Při předání nápravy bych určila, jak poznáme její skutečné dokončení. Nestačí, že nová verze transformace doběhla bez technické chyby. Potřebovala bych srovnání vstupu a výstupu, několik dohledatelných záznamů a kontrolu součtů ve výsledném použití. Zároveň bych zaznamenala, které části portfolia se neopravovaly a proč. Tím vznikne hranice mezi potvrzeným výsledkem a zbývající nejistotou. Při pozdějším sporu o číslo se tým může vrátit ke konkrétnímu rozhodnutí, místo aby znovu skládal význam dat z neúplné paměti účastníků.
U opakovaného reportu bych ověřila také následující běh po opravě. Tím se ukáže, zda se změna udržela při novém vstupu, nebo zda byl správný pouze jednorázově upravený historický výstup.
Shrnutí a doporučení
Datová kvalita je předpoklad pro interpretaci úvěrového rizika, nikoli jeho plná náhrada. Doporučila bych začít definicemi a rozhodným datem, kontrolovat vazby a aktuálnost a hodnotit chyby podle počtu i objemu. U významných výjimek bych požadovala dohledatelný postup řešení a ověření navazujícího dopadu. Svůj přínos vidím v přesném ověření podkladů a srozumitelném spojení odborného a technického pohledu. Tak lze vytvořit pevný základ, na který mohou navázat specialisté na úvěrové riziko a příslušné metodiky.