Projekt nápravy může mít přehledný harmonogram, splněné milníky a novou aplikaci. Přesto nemusí být jasné, zda se snížilo původní riziko. V datové oblasti bych se proto ptala na rozdíl mezi dodaným řešením a ověřeným výsledkem. Nové pravidlo kontroly, aktualizovaná dokumentace nebo školení jsou potřebné výstupy. Samy však neprokazují, že chyba přestala vznikat nebo že ji banka umí včas zachytit.
Doložený případ: dohledové kroky vůči Citi
Americký OCC v říjnu 2020 zasáhl vůči Citibank kvůli nedostatkům v řízení rizik a dat. Dne 10. července 2024 oznámil další opatření a pokutu 75 milionů dolarů; zmiňoval nedostatečný postup nápravy a sledování dopadu datových problémů na regulatorní reporting. Téhož dne Federal Reserve oznámil pokutu 60,6 milionu dolarů pro Citigroup kvůli nedostatkům nápravy datové kvality a kompenzačních kontrol. Jde o související, ale odlišné kroky vůči bance a její holdingové společnosti.
Z veřejných oznámení nevyvozuji současný stav všech programů Citi ani konkrétní technickou příčinu jednotlivých chyb. Pro svou úvahu používám doložený rozdíl mezi probíhající transformací a požadavkem na dostatečně účinnou nápravu. Navržený kontrolní postup níže je můj modelový přístup, nikoli rekonstrukce interního projektu této banky.
Nejdřív přesně popsat nedostatek
Začala bych vymezením problému ve formě, kterou lze znovu ověřit. Místo formulace „zlepšit datovou kvalitu“ bych chtěla vědět, které údaje, procesy a výstupy jsou dotčené, jak se odchylka pozná a k jakému rozhodnutí mohou být chybné podklady použity. Takový popis umožňuje domluvit cíl mezi odborným útvarem, datovým týmem, IT a kontrolní funkcí.
Oddělila bych také opravu minulosti od změny procesu. Opravený report může odstranit jeden následek. Změna validačního pravidla může zachytit další výskyt. Úprava zdrojového zadání může bránit vzniku problému. Každá vrstva má jiný účel a důkaz. Pokud projekt dodá pouze jednu, neměla by její existence zakrýt nevyřešené části.
Modelový příklad: nový skript a staré riziko
Představme si smyšlený měsíční report s deseti tisíci záznamy. U dvou set chybí rozhodné datum ocenění zajištění. Tým doplní data do posledního výstupu a zavede skript, který prázdné hodnoty každý měsíc najde. Jde o zlepšení, ale dosud není prokázáno, že záznamy s chybějícím datem neovlivní rozhodování dříve, než měsíční kontrola proběhne.
Navrhla bych ověřit další cyklus od zdroje. Pokud chybí datum u padesáti nových záznamů, minulá populace byla opravena, ale mechanismus vzniku zůstává. Kdyby navíc skript kontroloval pouze skutečně prázdné pole, mohl by přehlížet náhradní hodnotu 1. ledna 1900. Počet prázdných polí by klesl na nulu a interpretace by přesto byla nesprávná. Čísla jsou ilustrativní, nikoli údaje Citi.
Úspěch bych definovala kombinací podmínek. Opravené historické záznamy mají doložený zdroj data, nově vznikající záznamy procházejí kontrolou úplnosti a platnosti, výjimka se dostane ke konkrétnímu vlastníkovi a použití nejistého údaje je řízené. Ověření by mělo zahrnout správné hodnoty i případy, které systém musí odmítnout nebo označit. Bez negativního testu nemusíme poznat, že kontrola vůbec nepracuje.
Jak bych nastavila důkazy účinnosti
Pro každé opatření bych vytvořila stručné propojení: původní zjištění, příčina, navržená změna, očekávaný účinek a způsob ověření. Příčinu bych označila za potvrzenou jen tehdy, když pro ni existuje důkaz. Pokud jde zatím o hypotézu, patří do plánu její ověření. Jinak hrozí, že pečlivě otestujeme řešení problému, který jsme nesprávně pochopili.
Podklady pro uzavření bych sbírala ze skutečného pracovního toku. Testovací prostředí prokáže určitou vlastnost programu; provozní vzorek ukáže, zda kontrola běží ve správném okamžiku a kdo reaguje. Oba důkazy jsou užitečné, ale odpovídají na jinou otázku. Při předání bych proto vždy uvedla prostředí, verzi, rozhodné období a omezení vzorku.
Nezávislé prověření bych nepovažovala za opakování prezentace projektu. Ověřující osoba by měla dostat zadání, data a kritéria v podobě umožňující vlastní kontrolu. Pokud je důkazem jen obrazovka se zeleným stavem, chtěla bych dohledat, z čeho stav vznikl. Vlastník opatření a jeho ověřovatel mohou spolupracovat, ale jejich závěry by neměly být zaměnitelné.
Co měřit a čemu se vyhnout
Vedle počtu chyb bych sledovala dobu do jejich odhalení, dobu odstranění a podíl opakovaných případů. Metriku bych vztáhla k relevantnímu objemu a segmentu. Sto výjimek v milionu záznamů znamená něco jiného než sto ze dvou set. Ani malá četnost nevylučuje závažnost, pokud se chyba týká významné expozice nebo podkladu pro důležité rozhodnutí.
Vyhnula bych se motivaci, která podporuje jen pokles vykázaných výjimek. Náhlé zlepšení může vzniknout odstraněním filtru, změnou definice nebo vyřazením obtížných záznamů. Při výrazném pohybu bych ověřila jmenovatel i pravidla výpočtu. Užitečné je ponechat vedle hlavního ukazatele přehled vyloučených položek a neuzavřených nejistot. Zlepšení tak lze vysvětlit, ne pouze oznámit.
Kompenzační kontrola není zapomenutá dočasnost
Pokud trvalé řešení vyžaduje čas, chtěla bych rozumět dočasné ochraně. Kdo kontrolu provádí, jaký má rozsah, kdy selže a jak poznáme její vynechání? Ruční odsouhlasení může být přiměřené v omezeném rozsahu, ale jeho účinnost závisí na kapacitě a znalostech konkrétních lidí. Dovolená, změna týmu nebo zvýšení objemu nesmějí zůstat neprověřeným předpokladem.
Ke každému dočasnému postupu bych přiřadila datum přehodnocení a podmínku ukončení. Jinak může z nouzového řešení vzniknout trvalá součást procesu bez jasné odpovědnosti. Přechod na automatizaci bych ověřila souběžným porovnáním výsledků na vhodném vzorku, ne prostým vypnutím ruční kontroly ve chvíli instalace nového nástroje.
Ověření předání a udržitelnosti
Samostatnou otázkou by pro mě bylo, zda proces funguje po odchodu projektového týmu. Předání obsahuje přístup k podkladům, popis výjimek, zastupitelnost a způsob eskalace. Nový pracovník by měl dokázat kontrolu provést bez neformální pomoci autora skriptu. Pokud to nejde, považovala bych závislost za otevřené omezení, nikoli za nepodstatný detail dokumentace.
Při následné kontrole bych vybrala jiné období a část populace, než použil realizační tým při původním ověření. Nešlo by o náhodnou snahu hledat další chyby, ale o prověření přenositelnosti výsledku. Sezonní objem, změna produktu nebo nový zdroj mohou odhalit předpoklad, který první čistý soubor vůbec nezatížil. Rozsah bych přitom volila podle původního rizika, ne podle pohodlné dostupnosti dat.
Výsledný závěr by rozlišoval dokončení implementace, ověřenou účinnost a zbývající omezení. Pokud je doložena jen první část, lze ji poctivě oznámit jako postup projektu. Označení celého rizika za uzavřené by však podle mého návrhu vyžadovalo samostatný důkaz a odpovědné rozhodnutí. Přesnost tohoto rozlišení chrání vedení před přehnaně optimistickou informací.
Shrnutí a doporučení
Dokončený úkol a účinná náprava jsou rozdílné závěry. Doporučila bych uzavírat opatření až po doložení účinku na původní riziko, ověření relevantních výjimek a potvrzení provozní odpovědnosti. U rozsáhlejší změny bych požadovala také sledování přes více cyklů, aby jednorázově čistý soubor nezastoupil stabilně fungující proces.
Můj přínos bych viděla v propojení zadání, datových důkazů a srozumitelného závěru. Nejdůležitější otázka zní: co nyní banka skutečně umí lépe a jak to víme? Pokud odpověď obsahuje jen počet školení, dokumentů nebo hotových programových úprav, vrátila bych se k ověřitelnému výsledku pro konkrétní výstup a jeho uživatele.