Tyto analytické poznámky se věnují oblasti, v níž chci dále rozvíjet své znalosti. Příklady jsou modelové a nepopisují kontroly, které bych sama prováděla.
Nejdřív definice, potom dotaz
Před analýzou je třeba určit jednotku záznamu: klient, smlouva, čerpání či zajištění. Spojení tabulek bez této znalosti může znásobit částky. Důležité je také rozhodné datum a způsob zachycení uzavřených nebo převedených smluv.
Výjimka není automaticky chyba
Kontroly mohou hledat chybějící identifikátory, neobvyklá data schválení, duplicity nebo nesoulad součtů. Každý výstup potřebuje vysvětlení a porovnání s pravidlem. Nulová sazba může být legitimní podmínka produktu; chybějící sazba je jiný problém.
Modelový příklad
Po připojení zajištění se celková expozice zdvojnásobí, protože jedna smlouva má dva předměty zajištění. Správný postup oddělí agregaci úvěrů od agregace zajištění a ověří počty před i po spojení. Reprodukovatelný dotaz pak usnadní opakování kontroly.
Jak připravit reprodukovatelnou analýzu
Nejprve bych uchovala popis vstupních souborů a základní kontrolní součty. Následuje ověření typů polí, měn a identifikátorů. Teprve potom má smysl vytvářet výjimkové dotazy. Tento postup umožní poznat, zda neobvyklý výsledek pochází z portfolia, nebo z chyby při načtení a spojování dat.
Každý test by měl mít jednoduchou slovní definici. Například „najdi smlouvy, u nichž datum čerpání předchází evidovanému schválení“ je srozumitelnější než samotný kód. Výstup pak potřebuje komentář, jak se zachází s chybějícími hodnotami, historickými migracemi a časovými pásmy, pokud jsou pro případ významné.
Od výsledku dotazu k ověřenému případu
U zdvojené expozice po připojení zajištění bych porovnala počet řádků a počet jedinečných smluv v každém kroku. Tím lze oddělit oprávněný vztah jedna ku více od nežádoucího násobení součtů. Opravený výsledek je vhodné znovu porovnat se zdrojovým přehledem, nikoli jen s původním chybným dotazem.
Datový test je dobrý nástroj pro hledání podezřelých případů. K odbornému závěru ale potřebuje kontext spisu a metodiky. Proto bych výstup doplnila stavem prověření: vysvětleno, potvrzená odchylka, čeká na podklady. Tým pak nemusí znovu rozplétat, co je zatím jen pracovní seznam.
Otázky pro další ověření
Které konkrétní podklady podporují závěr? Jaké jiné vysvětlení ještě připadá v úvahu? Co by mohlo hodnocení změnit? Tyto otázky pomáhají udržet analýzu otevřenou věcnému ověření a jasně vymezit její dosah.
Skutečný případ: kvalita dat jako dohledové téma
Americký OCC 7. října 2020 uložil Citibank pokutu 400 milionů dolarů za širší nedostatky v řízení rizik, správě dat a kontrolách. Tento zveřejněný případ nepřipisuji jedné chybě SQL; ukazuje, že práce s daty patří do řízení instituce, ne pouze do technické podpory.
Pro mě je důležité nepřevést takovou zprávu na jednoduchý závěr, že stačí přidat několik validačních dotazů. Analytický test může odhalit odchylku, ale potřebuje vlastníka pravidla, správnou populaci a dohodnutou reakci. Pokud odpovědnost není jasná, stejný seznam výjimek se může opakovaně rozesílat, aniž by někdo rozhodl, zda jde o chybu, známé omezení nebo důvod upravit pracovní postup.
Modelový výpočet: vztah jedna smlouva a dvě zajištění
Následující příklad je umělý. Tabulka úvěrů obsahuje tři smlouvy s expozicemi 10, 20 a 30 milionů Kč. Součet je 60 milionů. První smlouva má dvě zajištění, ostatní po jednom. Po prostém propojení úvěrů se zajištěním vzniknou čtyři řádky a součet úvěrové částky bude 70 milionů. Rozdíl 10 milionů nevznikl novým obchodem, ale násobením stejné hodnoty při spojení.
Opravu bych nezačala odebráním náhodného řádku. Takový krok by mohl zároveň ztratit jedno platné zajištění. Oddělila bych dvě otázky: kolik činí celková expozice a jaké zajištění se k ní vztahuje. Expozici bych agregovala na úrovni smlouvy před připojením zajištění. Zajištění bych zpracovala samostatně podle odpovídajícího pravidla a teprve poté oba výsledky spojila pro prezentaci.
Kontrolní tabulka by pro každý krok ukazovala počet řádků, počet jedinečných smluv a součet úvěrové částky. Před spojením by uváděla tři smlouvy a 60 milionů, po spojení čtyři řádky a stále tři smlouvy. Tento rozdíl není sám o sobě závadou. Rozhodující je, zda výpočet respektuje význam řádku. Správná technická vazba ještě nezaručuje správnou ekonomickou agregaci.
Jak bych navrhla sadu testů
Začala bych slovním popisem každé otázky. Jeden test ověří jedinečnost klíče, druhý úplnost povinného údaje a třetí návaznost na nezávislý součet. Pro každý bych určila očekávaný výsledek, chování při prázdné hodnotě a známé oprávněné výjimky. Test, který jen vypíše všechno neobvyklé, může vytvořit velký objem práce bez schopnosti odlišit skutečně závažné případy.
Prioritu bych stanovila podle možného dopadu. Chybějící interní poznámka a chybně přiřazená měna nejsou rovnocenné problémy. Před automatizací bych ručně ověřila malý soubor známých správných a nesprávných příkladů. Patřila by mezi ně i smlouva s nulovou expozicí, více čerpáními a historickou změnou identifikátoru. Díky tomu bych věděla, zda test odhaluje zamýšlenou chybu, nebo pouze neobvyklou strukturu dat.
Co bych předala odbornému týmu
Výstup bych rozdělila na potvrzené chyby, vysvětlené výjimky a otevřené případy. U každého by byla vazba na pravidlo, rozhodné datum a konkrétní záznam. Nesnažila bych se z počtu výjimek bez dalšího odvodit kvalitu celého úvěrového procesu. Výběr může být cílený, některé záznamy mohou souviset s migrací a stejná příčina může způsobit stovky technicky podobných řádků.
Při opakované kontrole bych sledovala vznik i zánik výjimek. Pokles počtu nemusí znamenat nápravu, pokud systém začal problematické případy vynechávat. Proto bych uchovala definici populace a porovnala změnu pravidel mezi běhy. Zajímal by mě také čas do vysvětlení a počet případů vrácených k doplnění. Tyto informace pomáhají odhalit, kde se analýza zadrhává mezi datovým týmem a vlastníkem procesu.
Co udělat, když pravidlo nelze jednoznačně určit
Někdy test odhalí spíš nejasnost zadání než nesprávný záznam. Například datum schválení může znamenat první rozhodnutí, potvrzení dodatku nebo poslední obnovu limitu. Nevybrala bych jeden význam jen proto, že se s ním dotaz píše snadněji. Připravila bych ukázku rozdílu a vyžádala potvrzení vlastníka. Do té doby by výstup zůstal seznamem k objasnění, nikoli potvrzeným porušením pravidla.
Také bych kontrolovala náklady následného ověřování. Pokud test produkuje stovky legitimních výjimek, potřebuje přesnější definici nebo další rozlišení. Vysvětlitelná úprava pravidla může zvýšit použitelnost bez snížení přísnosti. Nešlo by o odstranění nepohodlných případů z výsledku, ale o rozdělení různých situací podle jejich skutečného významu. Každá taková změna by měla mít zaznamenaný důvod a dopad na porovnání s předchozím během.
Shrnutí a doporučení
Doporučila bych budovat méně, ale lépe vysvětlených testů. Každý má mít smysl, ověřený příklad, vlastníka a navazující rozhodnutí. Největší analytická hodnota často není v komplikovaném dotazu, ale ve správné definici jednotky záznamu a v odsouhlasení kontrolních součtů. Teprve reprodukovatelný a odborně vysvětlený výsledek se může stát důvěryhodným podkladem pro další práci.
Zdroje a odkazy
- OCC — Citibank enforcement announcement, 7 October 2020
- ECB — Guide on effective risk data aggregation and risk reporting, 2024
Zahraniční případ slouží k analytickému poučení; jeho právní rámec ani opatření nepřenáším automaticky na české banky. Modelové situace a navržený postup nejsou tvrzením o mých vlastních kontrolách.