Business analýza ve finančních institucích (banky, pojišťovny apod.) probíhá pod intenzivním dohledem regulatorů. Regulace jako GDPR, PSD2, AML, Basel III či nově DORA zásadně ovlivňují každodenní práci business analytika – od sběru požadavků přes dokumentaci až po komunikaci se stakeholdery. Nedodržení pravidel může vést k závažným důsledkům včetně právních postihů či finančních sankcí. Zde si podrobněji rozebereme specifika práce business analytika ve vysoce regulovaném prostředí finančního sektoru, dopad konkrétních regulací na proces analýzy, osvědčené nástroje a techniky modelování a dokumentace a nejčastější výzvy a chyby, kterým je třeba se vyhnout.
Specifika práce business analytika v regulovaném prostředí
Práce business analytika ve vysoce regulovaném odvětví se vyznačuje nadstandardním důrazem na soulad s legislativou a interními pravidly. Analytik musí často interpretovat složité právní předpisy a přetavit je do konkrétních funkčních požadavků, což není triviální úkol. Regulace bývají nejednoznačné a jejich výklad je náročný; navíc se poměrně často mění, aktualizují či zpřesňují. Business analytik tak čelí obtížnému zadání: definovat požadavky tak, aby výsledné řešení bylo auditovatelné a “compliant” (v souladu s regulacemi)
Současně bývá náročné zajistit si čas klíčových stakeholderů, jako jsou právníci, specialisté na compliance či IT bezpečnost – ti všichni bývají velmi vytížení, ale pro správné pochopení regulatorních dopadů nepostradatelní
V regulovaném prostředí též často probíhá více projektů paralelně pod různými regulacemi, které mohou ovlivňovat různé systémy a oddělení současně
Důsledkem je zvýšená komplexita – analytik musí zohlednit křížové dopady a zajistit, že žádný regulatorní požadavek nezůstane opomenut.
Dalším specifikem je vyšší míra formalizace a dokumentace. Ve finančních institucích je běžné, že veškeré požadavky, rozhodnutí a analýzy jsou pečlivě dokumentovány pro účely pozdější kontroly či auditu. Dokumentace musí být velmi precizní a srozumitelná, aby v případě auditu bylo možné doložit, že systém splňuje všechny relevantní regulatorní požadavky. Business analytik tak často připravuje nejen běžné analytické artefakty (procesní modely, specifikace požadavků), ale i doplňující materiály pro auditory a regulátory – například matice souladu požadavků s konkrétními ustanoveními zákonů. Důležitá je také traceabilita (dohledatelnost) požadavků – tedy schopnost vysledovat původ každého požadavku zpět ke konkrétní regulační normě či interní směrnici. V silně regulovaných odvětvích je robustní traceabilita nezbytná a tvoří základ pro prokázání shody při auditu.
Jinými slovy, týmy musí umět definovat “compliance” požadavky a prokázat, že každý z nich je zohledněn v systému – formální sledovatelnost mezi regulací, požadavkem, implementací a testem je nejefektivnější způsob, jak toho dosáhnout
Pokud by firma nebyla schopna doložit soulad systému s regulacemi, vystavuje se riziku sankcí – v krajním případě mohou pokuty dosahovat i stovek milionů (např. za závažné porušení AML či GDPR pravidel).
Reálným příkladem může být případ Deutsche Bank, která v roce 2023 dostala pokutu 186 milionů dolarů od americké centrální banky za nedostatky v kontrolách praní peněz a byla donucena zlepšit své systémy risk managementu a datové kontroly
Takové incidenty podtrhují význam pečlivé analýzy a důsledné implementace regulatorních požadavků.
V neposlední řadě je specifikem angažovanost více zainteresovaných stran. Kromě obvyklých business stakeholderů a IT architektů vstupují do hry oddělení compliance, právní oddělení, oddělení řízení rizik, případně přímo zástupci regulačních orgánů. Analytik často funguje jako tlumočník mezi světem byznysu/IT a světem regulace – musí porozumět jazyku zákonů a vyhlášek a vysvětlit jejich dopady vývojářům či procesním vlastníkům. Klíčové je proto budování vztahů a pravidelná komunikace se stakeholdery odpovědnými za GRC (Governance, Risk, Compliance). Doporučuje se proaktivně si sjednat schůzky s právníky, compliance specialisty či risk manažery hned v úvodu projektu a konzultovat s nimi regulatorní ekosystém firmy
Tato investice do vztahů a znalostí se vyplatí – pomůže předejít nedorozuměním a zajistí, že požadavky budou kompletní a správně interpretované.
Dopad klíčových regulací na proces analýzy
Regulace ve financích jsou rozsáhlé a každá pokrývá jinou oblast. Níže se zaměříme na vybrané důležité předpisy (GDPR, PSD2, AML, Basel III, DORA) a rozebereme, jak konkrétně ovlivňují sběr požadavků, dokumentaci, komunikaci se stakeholdery a systémovou analýzu.
GDPR: Ochrana osobních údajů a soukromí
GDPR (General Data Protection Regulation, česky Obecné nařízení o ochraně osobních údajů) přinesla od roku 2018 přísná pravidla pro nakládání s osobními údaji. Pro business analytika to znamená, že při sběru požadavků musí vždy zjišťovat, zda se bude zpracovávat osobní data klientů, a pokud ano, jaké dopady to má.
GDPR vyžaduje minimalizaci dat (sbírat jen nezbytné údaje) a jasně definované účely zpracování – tyto informace musejí být reflektovány již v požadavcích. Dále analytik musí zajistit, že systém umožní výkon práv subjektů údajů (právo na výmaz, přenositelnost dat, opravu údajů apod.), což se promítá do funkčních požadavků (např. požadavek na funkci “vymazat uživatelská data” nebo “export dat uživatele”).
Dokumentace u projektů podléhajících GDPR často obsahuje i Data Protection Impact Assessment (DPIA) – analýzu vlivu na ochranu dat, kterou může regulátor vyžádat. Analytik spolupracuje s pověřencem pro ochranu osobních údajů (DPO) na identifikaci rizik a návrhu opatření.
Komunikace se stakeholdery zde zahrnuje zejména právní oddělení a DPO, kteří poskytují výklad GDPR a schvalují navržená opatření.
Systémová analýza musí brát ohled na privacy by design a security by design – už ve fázi návrhu systému je nutné zabudovat prvky ochrany soukromí. To zahrnuje například detailní auditní logy přístupů k citlivým datům, šifrování dat při ukládání i přenosu, striktní řízení přístupových práv a také techniky anonymizace či pseudonymizace osobních údajů.
GDPR rovněž stanovuje povinnost oznamovat bezpečnostní incidenty do 72 hodin, což se projevuje v požadavcích na monitoring a logování – analytik musí pamatovat na to, aby systém uměl detekovat a hlásit případné narušení dat
Reálný příklad: V praxi banky zavedly na základě GDPR např. funkce pro správu souhlasů se zpracováním údajů a mechanismy pro automatizované mazání či archivaci klientských dat po uplynutí zákonných lhůt. GDPR compliance je náročná, ale nezbytná – maximální pokuty totiž činí až 4 % z globálního obratu firmy. Business analytik tedy hraje zásadní roli v tom, aby žádný požadavek na ochranu dat nezapadl a výsledný systém aktivně předcházel únikům dat a porušení soukromí
PSD2: Otevřené bankovnictví a nové služby
PSD2 (Payment Services Directive 2, druhá směrnice EU o platebních službách) vstoupila v platnost v roce 2018 a způsobila revoluci v oblasti plateb a otevřeného bankovnictví. Pro business analytika v bance znamenala PSD2 zcela nové požadavky zejména v oblasti integrací a bezpečnosti. Klíčovým dopadem PSD2 je povinnost bank zpřístupnit rozhraní (API) pro třetí strany (Third Party Providers), aby mohly bezpečně přistupovat k účtům klientů (tzv. otevřené bankovnictví).
Analytik tedy musel sepsat požadavky na vývoj API portálu, definovat, jaké služby budou dostupné (např. načtení zůstatků, historie transakcí, iniciace platby) a za jakých podmínek. To vyžadovalo intenzivní komunikaci s IT architekty a bezpečnostním oddělením, aby API splňovala standardy (formát, autentizaci, kapacitu) a zároveň neohrozila bezpečnost banky. PSD2 také přinesla požadavek na Silné ověření klienta (Strong Customer Authentication, SCA) u elektronických plateb – analytik musel navrhnout změny v procesech přihlašování a autorizace plateb (např. dvoufaktorové ověření) a tyto požadavky sladit s uživatelskou přívětivostí.
Dokumentace musela zahrnovat technické specifikace API, ale i regulatorní technické standardy (RTS) k PSD2, aby všichni zúčastnění rozuměli přesnému znění požadavků.
Stakeholdeři u PSD2 projektů zahrnovali kromě interních týmů i externí partnery (fintech společnosti integrující se na API) a samozřejmě regulátora (ČNB v ČR), který dohlížel na včasnou implementaci. Business analytik zde často fungoval i jako koordinátor mezi bankou a externími vývojáři třetích stran, připomínkujícími funkčnost API.
Systémová analýza v kontextu PSD2 musela pokrýt zvýšené nároky na výkon (API volání v reálném čase), bezpečnost (např. ochrana proti útokům na API) a monitoring.
Praktickým dopadem PSD2 bylo například spuštění řady API portálů českých bank, kde business analytici definovali, jaké datové struktury a služby budou poskytovány, a zajistili implementaci nových autentizačních metod dle PSD2 (např. mobilní aplikace generující jednorázové kódy či push notifikace pro potvrzení plateb)
PSD2 tak rozšířila okruh požadavků – kromě čistě interních byznys potřeb banky musely nově plnit i požadavky inovátorů na trhu, a business analytik se ocitl v centru tohoto procesu jako zprostředkovatel otevřených bankovních služeb.
AML: Povinnosti proti praní peněz
AML (Anti-Money Laundering, předpisy proti praní špinavých peněz) představuje soubor zákonů a regulací (vč. národních zákonů, evropských směrnic a doporučení FATF) ukládajících finančním institucím povinnost předcházet praní peněz a financování terorismu. Pro business analytika to znamená, že požadavky na systém často vycházejí z povinných AML procesů: např. KYC – Know Your Customer (Poznej svého klienta) proces při otvírání účtu, monitoring podezřelých transakcí, screening klientů vůči sankčním seznamům atd.
Sběr požadavků musí zahrnovat vstupy od compliance officerů, kteří definují, jaká data o klientech se musí sbírat (identifikační údaje, účel obchodního vztahu…), jaké kontroly se mají provádět (např. kontrola klienta v databázích politicky exponovaných osob) a jaké reporty je třeba generovat pro oznamování podezřelých aktivit úřadům (v ČR Finanční analytický úřad).
Dokumentace AML požadavků bývá obsáhlá – kromě funkční specifikace systémů (např. systému pro monitoring transakcí) často obsahuje pravidla a scénáře detekce (typologie podezřelých operací), které se implementují buď jako skripty, nebo jsou součástí parametrů specializovaných AML nástrojů.
Business analytik musí pečlivě zdokumentovat rozhodovací logiku, aby bylo zřejmé, proč systém označil určitou transakci za podezřelou (pro potřeby auditu či vyšetřování). Komunikace se stakeholdery zde probíhá hlavně s útvarem Compliance/AML v bance, případně s útvarem Řízení rizik. Často je potřeba ladit požadavky také s dodavateli externích AML systémů nebo s datovými specialisty (pro integraci dat z různých zdrojů – např. registrů klientů, transakčních systémů, seznamů sankcí).
Systémová analýza v oblasti AML klade důraz na datové toky (kam všude data o klientovi putují, jak se vyhodnocují), bezpečnost těchto dat a škálovatelnost – objemy transakcí jsou velké a systém musí reagovat včas. Důležitá je také evidence a audit trail – každý podezřelý případ musí být v systému zaznamenán včetně kroků, které banka podnikla.
Příklad z praxe: Business analytici bank implementovali např. systém, který automaticky zpracovává údaje o klientech (Customer Identification Program) a prověřuje je (Customer Due Diligence) dle rizikového profilu, aby zamezili průniku nezpůsobilých či rizikových osob k finančním službám
Za nedodržení AML povinností hrozí bankám vysoké pokuty – např. britský regulátor v roce 2023 pokutoval Starling Bank částkou ~29 milionů liber za nedostatečné prověřování klientů a transakcí
To vše vytváří tlak na důslednost business analýzy: chybně nebo neúplně zadaný požadavek v oblasti AML může vést k mezeře, kterou zneužijí zločinci, a banka pak nese odpovědnost. Analytik proto musí být obezřetný, konzultovat návrhy kontrol s experty a průběžně se seznamovat s novými typy hrozeb či regulatorními novelami.
Basel III: Kapitálová přiměřenost a rizikové ukazatele
Basel III je mezinárodní regulační rámec pro banky (třetí tzv. Basilejský akord) zaměřený na kapitálovou přiměřenost, likviditu a řízení rizik bank. Byl vyvinut po finanční krizi 2008 s cílem posílit odolnost bankovního sektoru. Pro business analytika pracujícího na projektech v risk managementu či reportingu má Basel III zásadní dopady.
Sběr požadavků zde typicky zahrnuje požadavky na výpočet různých ukazatelů – např. kapitálová přiměřenost (Capital Adequacy Ratio), pákový poměr (Leverage Ratio), ukazatel krytí likvidity (LCR) a další. Tyto metriky mají přesně definované vzorce a metodiky v regulaci, takže analytik musí těmto definicím porozumět a zajistit, že systém bude sbírat potřebná data pro jejich výpočet. Zde často spolupracuje s kvantitativními analytiky nebo regulátory, kteří upřesňují metodiku. Basel III také stanovuje požadavky na reporting – banky musí pravidelně předkládat dozorovým orgánům výkazy o svém kapitálu a rizicích.
Dokumentace požadavků proto musí zahrnovat i definice dat (datový model pro riziková data), business logiku výpočtů a šablony reportů. Business analytik může připravovat například specifikaci transformace dat z transakčních systémů do datového skladu rizik, kde se počítají ukazatele dle Basel III.
Komunikace se stakeholdery: V tomto případě jsou hlavními partnery risk manažeři, finanční oddělení a regulační reporting tým. Je potřeba zajistit, že všichni rozumí požadavkům stejně – což může být výzva, protože terminologie rizik může být složitá. Někdy do procesu vstupuje i interní audit, který kontroluje, zda nastavení odpovídá regulačním pravidlům.
Systémová analýza u Basel III projektů zahrnuje posouzení, zda stávající IT systémy dokáží shromáždit a zpracovat obrovské objemy dat (např. detailní expozice úvěrů, hodnoty zajištění, cash flow) a zda architektura zaručí správnost a aktuálnost výpočtů (požadavek na denní výpočty ukazatele LCR atd.). Někdy je třeba navrhnout datamart či modul speciálně pro Basel III výpočty.
Reálný příklad: Implementace Basel III často vedla k úpravám core banking systémů a datových skladů – např. analytici museli definovat požadavky na nové datové položky typu “rizikově vážená aktiva” nebo “koeficient stabilního financování (NSFR)” a vytvořit procesy, které tato data generují a konsolidují pro regulatorní zprávy. K modelování takových procesů se osvědčily notace jako BPMN – v praxi byly vytvářeny BPMN modely regulatorních procesů pro Basel II/III, AML či KYC, které pomáhají vizualizovat a sdílet tok informací potřebných pro shodu
Vysoká komplexita Basel III rovněž znamená, že chyby v analýze se mohou projevit až při zátěži – např. pokud by nebyly v požadavcích zahrnuty extrémní scénáře likvidity, systém by mohl selhat ve chvíli finanční krize. Proto je u Basel projektů důležité i robustní testování a zpětná traceabilita každého požadavku k příslušnému odstavci regulace.
DORA: Digitální operační odolnost finančních institucí
DORA (Digital Operational Resilience Act) je nová regulace EU (účinná od ledna 2025) zaměřená na digitální odolnost finančního sektoru. Jejím cílem je zajistit, aby banky, pojišťovny a další finanční instituce dokázaly odolat kybernetickým útokům a provozním výpadkům a rychle obnovit provoz
Pro business analytika DORA přináší požadavky zejména v oblastech IT risk managementu a kontinuitního plánování. Již při sběru požadavků je nutné spolu s IT bezpečnostními specialisty identifikovat, jaké kritické informační systémy podléhají této regulaci a jaké hrozby je třeba zvažovat (ransomware, útoky na dodavatele ICT služeb, výpadky datových center apod.). DORA stanovuje povinnost mít robustní rámec řízení ICT rizik, plány odezvy na incidenty a pravidelné testování odolnosti.
Dokumentace proto musí zahrnovat např. BIA (Business Impact Analysis) pro scénáře výpadků – analytik pomáhá dokumentovat, jaké dopady by mělo zastavení určitého systému na byznys, jaká je maximální tolerovaná doba výpadku (RTO) a které procesy je nutné obnovit přednostně. Dále je vyžadován incident management plan – zde analytik může definovat procesy eskalace incidentů (opět často modelované pomocí BPMN).
Komunikace se stakeholdery: DORA přivádí do projektu především odborníky na kybernetickou bezpečnost a provozní rizika, případně zástupce oddělení IT provozu. Business analytik musí sladit jejich požadavky (často velmi technické) s byznys pohledem – například určit, jaké jsou kritické obchodní služby, pro které se musí navrhnout záložní řešení.
Systémová analýza pod DORA zahrnuje posouzení architektury z hlediska single points of failure, závislostí na třetích stranách (cloudových poskytovatelích, outsourcovaných službách) a návrh opatření jako je geo-redundance, zálohování, monitoring anomálií apod. DORA také vyžaduje, aby finanční instituce hodnotily rizika svých dodavatelů ICT – to znamená, že analytik může připravovat požadavky na integrace s dodavateli (např. získávání reportů o jejich dostupnosti, bezpečnostních událostech) nebo definovat metriky pro jejich hodnocení.
Příklad: V reakci na DORA banky zavedly např. pravidelné penetration testy a testy zotavení po havárii – business analytici se podíleli na definici požadavků pro výběr nástrojů, které tyto testy automatizují, a na nastavení metrik reportovaných vedení banky. DORA v podstatě institucionalizuje to, co bylo dříve jen doporučené: finanční firmy musí mít trvale aktualizované plány pro zvládání kybernetických incidentů a provozních krizí
Pro business analytika to znamená neustále spolupracovat s bezpečáky a risk manažery a držit krok s nejnovějšími hrozbami, aby požadavky na odolnost byly vždy o krok napřed před potenciálními útoky.
Nástroje a techniky pro modelování a dokumentaci v regulovaném prostředí
Při analýze ve vysoce regulovaném prostředí se osvědčují určité nástroje a postupy, které pomáhají zachytit komplexní informace a zajistit splnění všech pravidel. Mezi klíčové patří:
- BPMN (Business Process Model and Notation): Notace BPMN je mezinárodní standard pro modelování business procesů. Umožňuje graficky znázornit tok procesu, role zúčastněných stran, vstupy/výstupy a výjimky. Ve finančním sektoru se BPMN velmi rozšířila – využívá se k dokumentaci stovek typů procesů, od běžných operací až po regulatorní procesy jako jsou postupy pro zajištění souladu s GDPR, AML, KYC či Basel III. Její výhodou je srozumitelnost napříč odděleními – BPMN diagram pochopí business uživatel, IT odborník i auditor. Pro business analytika je BPMN užitečná při komunikaci se stakeholdery: místo dlouhého textu lze proces “jak banka vyhodnocuje podezřelou transakci” popsat diagramem. BPMN navíc umožňuje hierarchii detailů – proces lze rozdělit do dílčích subprocesů, což je ideální pro složité regulatorní požadavky, kde hlavní diagram ukazuje přehled a detailní diagramy obsahují konkrétní podmínky a pravidla. Například proces vyřízení stížnosti klienta může v regulovaném prostředí obsahovat větvení podle toho, zda jde o stížnost spadající pod zákon o ochraně spotřebitele nebo pod regulaci MiFID II – BPMN to dokáže názorně vyjádřit. Výstupy v BPMN lze také použít jako součást formální dokumentace pro audit. Pro ilustraci: níže je ukázka, jak může business analytik pracovat s BPMN modelem procesu v bankovním prostředí.
- RACI matice (Responsible, Accountable, Consulted, Informed): RACI je pomůcka pro vyjasnění rolí a odpovědností v projektu nebo procesu. V regulovaném prostředí je obzvlášť důležité přesně určit, kdo je za co zodpovědný – např. kdo schvaluje regulatorní požadavky, kdo je konzultován při změnách, kdo musí být informován o výsledku. RACI matice tabulkovou formou přiřazuje ke každému úkolu či deliverable, kdo je výkonně zodpovědný (Responsible), kdo nese konečnou odpovědnost (Accountable), kdo je konzultován (Consulted) a kdo informován (Informed). Použití RACI pomáhá předejít nejasnostem – např. u požadavku na šifrování databáze bude Accountable vedoucí IT bezpečnosti, Responsible konkrétní administrátor, Consulted právní oddělení (kvůli souladu s GDPR) a Informed třeba interní audit. Výhodou RACI je, že podporuje dodržování compliance – jasně určuje, kdo (například compliance officer) má na starosti kontrolu souladu daného výstupu s regulací Pomáhá to také při auditu, kdy je možné prokázat, že za každý klíčový aspekt (např. schválení metodiky výpočtu kapitálové přiměřenosti) byla odpovědná kompetentní osoba. Business analytik často RACI matici využívá při plánování analýzy: stanoví se, kdo schvaluje dokumenty, kdo dodá vstupy (např. data o rizicích), koho je nutno zapojit do konzultací (např. externí regulatorní poradce) atd. Tím se předchází mezerám v komunikaci – ve vysoce regulovaných projektech se nesmí stát, že by někdo opomněl zapojit právní oddělení nebo že by nebylo jasné, kdo má finální slovo při konfliktních požadavcích.
- Matice sledovatelnosti požadavků (Requirements Traceability Matrix, RTM): Jak již bylo zmíněno, dohledatelnost požadavků ke zdroji je kritická. Matice sledovatelnosti je nástroj (často v Excelu nebo specializovaném systému), kde se ke každému business požadavku přiřadí odpovídající funkční/technické požadavky, návrhové prvky, testovací scénáře a také reference na regulatorní ustanovení. Cílem je mít přehlednou mapu: např. požadavek “ověření klienta proti sankčnímu seznamu” bude propojen s legislativou AML paragraf XY, bude mít implementační ticket v Jira ID 123, a test case číslo 45. Tato matice umožňuje týmu ověřit, že žádný požadavek nebyl opomenut a že každé regulační kritérium má odpovídající realizaci v systému. V regulovaném prostředí je RTM zároveň jedním z dokumentů, které mohou být předloženy auditorům či regulátorovi – dokládá splnění povinností. Benefit pro analytika: RTM usnadňuje řízení změn. Když dojde k novelizaci zákona, lze snadno vysledovat, kterých požadavků a částí systému se změna dotkne. Robustní traceability praktiky jsou považovány za esenciální součást analýzy v regulovaných odvětvích. Mnohé týmy rozšiřují základní RTM o další dimenze – například o rizika (jaké riziko hrozí při nesplnění daného požadavku), o datum účinnosti regulace, o odpovědnou osobu (RACI) apod. Důležité je, že matice není jednorázový dokument, ale živý artefakt po celou dobu projektu. Business analytik by měl její aktualizaci zahrnout do svého procesu – třeba při každém přidání nového požadavku ověřit, zda je správně zmapován na regulatorní položky. Kvalitně vedená traceability matice významně snižuje riziko nesouladu a pomáhá odhalit případné mezery ještě předtím, než je odhalí audit.
Business analýza v prostředí bank, pojišťoven a dalších finančních institucí klade na analytiky vysoké nároky, ale zároveň přináší i vysokou přidanou hodnotu. Regulace mohou na první pohled působit jako omezení, avšak správně uchopeny mohou vést k lepším procesům, vyšší důvěryhodnosti pro klienty a celkově robustnějšímu businessu. Klíčové je, aby business analytik kombinoval expertízu v doméně regulací s metodickou pečlivostí – důsledně mapoval požadavky, komunikoval s relevantními experty a využíval vhodné nástroje k modelování a dokumentaci. Jak ukazují příklady z praxe, chyby v regulované analýze mohou být drahé. Naopak, dobře zvládnutá analýza pomůže firmě nejen splnit zákonné povinnosti, ale často i zefektivnit vnitřní fungování. Pro business analytiky je proto oblast regulací výzvou, ale také příležitostí stát se nepostradatelnými strážci souladu a kvality řešení. S rostoucí regulací finančního sektoru bude význam této role nadále stoupat – buďme tedy připraveni a vybaveni znalostmi i nástroji, abychom v této roli obstáli.