Open banking: Správa souhlasů, odvolání přístupu a audit datové stopy

Open banking stručně: kdo, co a proč

Open banking je ekosystém, v němž banky (ASPSP) poskytují licencovaným třetím stranám (TPP) přístup k účtům a platebním funkcím klientů na základě výslovného souhlasu. Typickými rolemi jsou AISP (Account Information Service Provider – přístup k výpisům a zůstatkům) a PISP (Payment Initiation Service Provider – iniciování plateb). Architekturu tvoří API bankovních vrstev, standardy identity a autorizace (OAuth 2.0, OIDC, FAPI), bezpečnostní požadavky na silné ověření klienta (SCA) a důsledná správa souhlasů a auditních stop.

Souhlasy: právní a technický základ

Výslovnost a granularita: Souhlas musí být konkrétní (účel, rozsah účtů, typ dat či operací), časově omezený a odvolatelný.
Transparentnost ve dvou kanálech: Souhlas je představen v rozhraní TPP (co a proč) a následně potvrzen v bankovní aplikaci (kdo a s jakými riziky).
Vazba na identitu: Souhlas je vázán na identitu klienta (KYC) a identitu aplikace TPP (certifikáty eIDAS, registrované ID klienta, podpisy požadavků).
Minimální rozsah: Vyžadovat pouze nezbytný „scope“ – např. přístup jen k běžnému účtu, nikoli ke všem produktům; pouze čtení, nikoli iniciování.

Životní cyklus souhlasu: od vytvoření po vypršení platnosti

Iniciace v TPP: Uživatel zvolí účel (agregace, účetnictví, rozpočet) a rozsah. TPP požádá banku o vytvoření „consent resource“.
Přesměrování do banky: Banka ověří klienta (SCA) a zobrazí souhrn přístupu (účty, datové kategorie, platnost).
Udělení a aktivace: Po potvrzení banka vytvoří souhlas s jedinečným identifikátorem a vydá TPP tokeny (krátkodobé a střednědobé).
Obnovení/opětovné ověření: Po uplynutí platnosti nebo při změně rozsahu je vyžadováno nové potvrzení (opětovný souhlas) prostřednictvím banky.
Odvolání: Kdykoli prostřednictvím bankovní aplikace/portálu TPP nebo zákaznické podpory; prakticky okamžitě zneplatní tokeny.

Typologie souhlasů podle rizika

Pouze pro čtení (AISP): Zůstatky, výpisy, kategorizace plateb. Rizikem je únik soukromých údajů; doporučuje se krátká platnost a filtrování účtů.
Zápis/platba (PISP): Jednorázové či opakované platby, trvalé příkazy. Vyžaduje SCA při každém zahájení nebo v rámci schváleného mandátu s limity.
Kontextové souhlasy: Např. ověření příjmu nebo zůstatku pro úvěr – jednorázové, s jasným účelem a automatickým vypršením platnosti.

Odvolání přístupu: mechanismy a očekávání

Na straně banky (ASPSP): Zobrazení seznamu aktivních souhlasů, možnost okamžitého zrušení, podrobné zobrazení toho, co přesně TPP vidí/dělá.
Na straně TPP: Nastavení účtu musí umožňovat zrušení také v aplikaci TPP; po odvolání TPP zneplatní místní tokeny a vymaže nebo anonymizuje data, která není oprávněn uchovávat.
Automatické vypršení platnosti: Datum „sunset“ brání zapomenutým přístupům; při zásadních změnách je povinné opětovné ověření.
Dopad na existující data: Odvolání přístupu neznamená automatické vymazání již získaných údajů – TPP musí mít zveřejněnou politiku doby uchovávání a způsobu výmazu.

Auditní stopy: co a jak zaznamenávat

Transakční stopa: Každé čtení účtu, seznam transakcí, iniciace platby, změna limitů – čas, identifikátor souhlasu, klient, TPP, IP/zařízení.
Autorizace a tokeny: Vydání/obnovení tokenu, rozsah, vypršení platnosti, podpisové údaje požadavku (např. JWS thumbprint).
Změny souhlasu: Vytvoření, úprava, odvolání, důvod (klient, TPP, banka), osoba/kanál provádějící audit.
Nepovolené pokusy: Zamítnutá volání API, překročení rozsahu, pokusy po vypršení platnosti/odvolání.
Nepopiratelnost: U klíčových událostí použít podpisy nebo časová razítka; archivovat logy v neměnném úložišti.

Transparentnost pro uživatele: „privacy UX“

Jasná vysvětlení: Proč žádáme o přístup, jaká jsou rizika, na jak dlouho a jak jej odvolat; bez žargonu.
Selektivní výběr: Uživatel si vybírá konkrétní účty a datové kategorie, nikoli „všechno“.
Upozornění: Potvrzení udělení souhlasu, připomenutí blížícího se vypršení platnosti, upozornění na neobvyklé přístupy.
Historie přístupů: Přehledný deník – kdo, kdy a za jakým účelem; export pro vlastní audit.

Minimální bezpečnostní požadavky pro banky a TPP

SCA a kontextové riziko: Adaptivní ověřování při citlivých operacích, geolokační a behaviorální signály.
Zabezpečení FAPI/OAuth: Důsledné používání mTLS, podepsaných požadavků/odpovědí, PKCE, krátké životnosti tokenů, vazby tokenu na klienta.
DLP a izolace: TPP ukládá data odděleně podle souhlasu a účelu, uplatňuje lhůty uchovávání a šifruje data v klidu i při přenosu.
Segmentace přístupů: Oddělená prostředí (produkční/testovací), princip nejnižších oprávnění, rotace klíčů, kontrola dodavatelů.

GDPR a otevřené bankovnictví: dodržování pravidel v praxi

Právní základ: Souhlas klienta pro konkrétní účel; TPP má převážně roli správce (controller) s jasně stanovenými povinnostmi.
Minimalizace dat: Shromažďovat jen to, co je nezbytné; pravidelně kontrolovat nadbytečná pole.
Práva subjektů údajů: Přístup, oprava, výmaz, omezení; TPP musí mít samoobslužný portál nebo proces s krátkými lhůtami.
Uchovávání a výmaz: Po odvolání souhlasu a uplynutí zákonných lhůt TPP údaje maže nebo anonymizuje; v logách zůstávají jen nezbytná metadata.

Prevence podvodů: signály a reakce

Neobvyklý odběr dat: Náhlá vysoká frekvence volání API, přístup v noci/ze zahraničí, vzorkování citlivých polí.
Změna kontextu: Nové zařízení, změna IP autonomního systému, nedávná výměna SIM, odlišný profil prohlížeče.
Reakce: Dočasné pozastavení souhlasu, posílené ověření, upozornění klienta, povinné opětovné udělení souhlasu.

Provozní modely: dashboardy a politiky

Consent Dashboard (banka): Přehled aktivních souhlasů, rychlé odvolání, export historie, upozornění na blížící se vypršení platnosti.
Consent Center (TPP): Zrcadlení stavu podle bank, zobrazení účelů, tlačítka „odvolat“ a „požádat o výmaz“. Propojení s DPO.
Policy-as-code: Technická reprezentace pravidel (maximální platnost, rozsahy, povinná upozornění) uplatňovaná při každém požadavku.

Praktická doporučení pro jednotlivce

Udělujte pouze nezbytné přístupy: Pokud aplikace potřebuje rozpočet, stačí číst data z vybraných účtů; platby povolujte až tehdy, když je skutečně potřebujete.
Krátká platnost: Upřednostňujte souhlasy na týdny až měsíce, nikoli „bez vypršení platnosti“.
Pravidelná kontrola: Jednou měsíčně zkontrolujte v bankovní aplikaci seznam souhlasů a odvolejte ty, které nepoužíváte.
Zabezpečení účtů: Zapněte silné dvoufaktorové ověřování (nikoli SMS), chraňte bankovní aplikaci biometrií a aktualizujte operační systém.

Praktická doporučení pro firmy a TPP

„Scopes s nejnižšími oprávněními“: Oddělené ID klienta pro AISP a PISP, rozdílné politiky uchovávání a izolovaná datová úložiště.
Potvrzení souhlasu: Potvrzení s hashem a časovým razítkem; klient si jej může uložit jako důkaz.
Návrh s prioritou odvolání: Souhlas musí být možné zrušit jedním kliknutím, stejně snadno, jako jej udělit.
Penetrační testy a red teaming: Se zaměřením na obcházení SCA, manipulaci s rozsahem a zneužití tokenů.

KPI a metriky pro řízení rizik

Průměrná délka platnosti souhlasu a podíl souhlasů bez aktivity za posledních 30 dní.
Doba od odvolání do zneplatnění tokenů a doba do potvrzení výmazu dat.
Počet incidentů překročení rozsahu a zamítnutých volání z důvodu překročení scope.
Pokrytí auditními logy (procento událostí s úplným kontextem, integrita logů).

Reakce na incident: co dělat, když se něco pokazí

Okamžité zmrazení souhlasu (banka) a odvolání tokenů (TPP) s upozorněním klienta.
Forenzní extrakce logů s důkazy integrity (podpisy, časová razítka) a vytvoření neměnných kopií.
Oznamovací povinnosti podle GDPR/PSD – v zákonných lhůtách, s popisem dopadu a doporučení pro klienty.
Opatření po incidentu – zkrácení doby platnosti, zpřesnění scope, doplnění posíleného ověřování.

Kontrolní seznam před nasazením do produkce (TPP/banka)

Máme UX souhlasu s jasným účelem, rozsahem a vypršením platnosti; uživatel může souhlas odvolat jedním kliknutím.
Tokeny mají krátkou životnost, jsou vázané na klienta a přenášejí se přes mTLS pomocí podepsaných požadavků.
Zaznamenáváme všechny zásadní události s ochranou proti manipulaci a máme definovanou dobu uchovávání.
Politiky GDPR: minimalizace, uchovávání, přístupová práva – zavedené a otestované.
Procesy odvolání jsou automatizované a otestované pro okrajové případy (klient offline, tokeny po vypršení platnosti).

90denní plán zavedení v organizaci

Dny 1–30: Definice politik souhlasu a rozsahů, návrh UX, výběr standardů (FAPI, OIDC), nastavení logování a neměnného úložiště.
Dny 31–60: Implementace SCA, mTLS, podepsaných požadavků; budování dashboardu souhlasů; integrační testy s pilotní bankou/TPP.
Dny 61–90: Penetrační testy, cvičný incident, úprava politik uchovávání, spuštění provozu s metrikami a pravidelným auditem.

Důvěra stojí na kontrole a dohledatelnosti

Open banking přináší pohodlí a inovace, ale pouze dobře navržené souhlasy, okamžité odvolání přístupu a spolehlivé auditní stopy z této svobody vytvářejí bezpečnou infrastrukturu. Granulární scope, krátká doba platnosti, přísné bezpečnostní standardy a transparentní logování jsou klíčem k tomu, aby si uživatel i regulátor mohli kdykoli ověřit, kdo k čemu přistupoval a na jakém základě.