Open banking: souhlasy, odvolání přístupu a auditní stopy

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

Open banking je ekosystém, ve které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 vrstvy bank, standardy identity a autorizace (OAuth 2.0, OIDC, FAPI), bezpečnostní požadavky na silné ověření klienta (SCA) a důsledné řízení 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ý.
Dvoukanálová transparentnost: Souhlas se prezentuje v rozhraní TPP (co a proč) a následně potvrzuje v bankovní aplikaci (kdo a s jakými riziky).
Vazba na identitu: Souhlas je vázán na identitu klienta (KYC) a na identitu aplikace TPP (eIDAS certifikáty, registrované klientské ID, podpisy žádostí).
Minimální rozsah: Vyžadovat pouze nezbytné „scope“ – např. přístup jen k běžnému účtu, ne ke všem produktům; pouze čtení, ne iniciování.

Životní cyklus souhlasu: od vytvoření po expiraci

Iniciace v TPP: Uživatel volí účel (agregace, účetnictví, rozpočet) a rozsah. TPP požádá banku o vytvoření „consent resource“.
Přesměrování na banku: Banka autentizuje klienta (SCA) a zobrazí shrnutí přístupu (účty, datové kategorie, platnost).
Udělení a aktivace: Po potvrzení banka vytvoří souhlas s unikátním identifikátorem a vydá tokeny TPP (krátkodobé a střednědobé).
Obnova/reauth: Po uplynutí platnosti nebo při změně rozsahu je vyžadováno opětovné potvrzení (re-consent) přes banku.
Odvolání: Kdykoli přes bankovní aplikaci/TPP portál nebo klientskou podporu; prakticky okamžitě zneplatní tokeny.

Typologie souhlasů podle rizika

Read-only (AISP): Zůstatky, výpisy, kategorizace plateb. Riziko úniku soukromí; doporučuje se krátká platnost a filtrování účtů.
Write/Payment (PISP): Jednorázové či opakované platby, trvalé příkazy. Vyžaduje SCA při každé iniciaci 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 automatickou expirací.

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í, detailní zobrazení, co přesně TPP vidí/dělá.
Na straně TPP: Nastavení účtu musí umožnit zrušení i v aplikaci TPP; po odvolání TPP likviduje lokální tokeny a maže nebo anonymizuje data, která nelze oprávněně držet.
Automatická expirace: „Sunset“ data zabraňuje zapomenutým přístupům; reautentizace je povinná při zásadních změnách.
Efekt na existující data: Odvolání přístupu není automatické smazání již převzatých údajů – TPP musí mít zveřejněnou politiku retenčních dob a způsobu smazání.

Auditní stopy: co a jak logovat

Transakční stopa: Každé přečtení účtu, seznam transakcí, iniciace platby, změna limitů – čas, identifikátor souhlasu, klient, TPP, IP/zařízení.
Autorizace a tokeny: Vydání/obnova tokenu, rozsah, expirace, podpisové údaje žádosti (např. JWS thumbprint).
Změny souhlasu: Vytvoření, modifikace, odvolání, důvod (klient, TPP, banka), auditní osoba/kanál.
Nedovolené pokusy: Zamítnuté volání API, překročení rozsahu, pokusy po expiraci/odvolání.
Nepopiratelnost: Pro klíčové události použít podpisy nebo časové razítka; archivovat logy v nezměnitelném úložišti.

Transparentnost pro uživatele: „privacy UX“

Jasná vysvětlení: Proč žádáme přístup, jaká jsou rizika, jak dlouho platí a jak ho odvolat; bez žargonu.
Selektivní výběr: Uživatel si vybírá konkrétní účty a datové kategorie, ne „vše“.
Notifikace: Potvrzení udělení, připomenutí expirace, upozornění na neobvyklé přístupy.
Historie přístupů: Čitelný deník – kdo, kdy, jaký účel; export pro vlastní audit.

Bezpečnostní minimum pro banky a TPP

SCA a kontextové riziko: Adaptivní ověření při citlivých operacích, geolokační a behaviorální signály.
FAPI/OAuth hardening: Přísné používání mTLS, podepsané žádosti/odpovědi, PKCE, krátká životnost tokenů, token binding ke klientovi.
DLP a izolace: TPP ukládá data odděleně podle souhlasu a účelu, aplikuje retenční lhůty a šifruje v klidu i při přenosu.
Segmentace přístupů: Oddělená prostředí (prod/test), princip nejmenších oprávnění, rotace klíčů, kontrola dodavatelů.

GDPR a otevřené bankovnictví: soulad v praxi

Právní základ: Souhlas klienta pro konkrétní účel; pro TPP převážně role správce údajů (controller) s jasnými povinnostmi.
Data minimization: Sbírat jen to, co je nezbytné; pravidelně auditovat 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.
Retence a výmaz: Po odvolání souhlasu a uplynutí zákonných lhůt TPP data maže nebo anonymizuje; v logách zůstávají pouze nezbytná metadata.

Anti-fraud: signály a reakce

Neobvyklý odběr dat: Náhlé vysoké frekvence volání API, přístupy v noci/z ciziny, sampling citlivých polí.
Změna kontextu: Nové zařízení, změna IP autonomního systému, čerstvá výměna SIM karty, odlišný prohlížečový profil.
Reakce: Dočasné pozastavení souhlasu, step-up autentizace, notifikace klienta, povinný re-consent.

Provozní modely: dashboardy a politiky

Consent Dashboard (banka): Přehled aktivních souhlasů, rychlé odvolání, export historie, notifikace o blížící se expiraci.
Consent Center (TPP): Zrcadlení stavu podle bank, zobrazení účelů, tlačítka „odvolat“ a „požádat o výmaz“. Propojení na DPO.
Policy-as-code: Technická reprezentace pravidel (max. platnost, rozsahy, nutné notifikace) aplikovaná při každé žádosti.

Praktická doporučení pro jednotlivce

Udělujte pouze nezbytné přístupy: Pokud aplikace potřebuje rozpočet, stačí čtení z vybraných účtů; platby povolujte až při skutečné potřebě.
Krátká platnost: Preferujte souhlasy na týdny až měsíce, ne „bez expirace“.
Pravidelná kontrola: Jednou měsíčně zkontrolujte v bankovní aplikaci seznam souhlasů a odeberte nepoužívané.
Bezpečnost účtů: Zapněte silné 2FA (nikoli SMS), chraňte bankovní aplikaci biometricky a aktualizujte operační systém.

Praktická doporučení pro firmy a TPP

„Least privilege scopes“: Oddělené klientské ID pro AISP a PISP, rozdílné retenční politiky a izolované datové sklady.
Consent receipts: Potvrzení s hashem a časovým razítkem; klient si ho může uložit jako důkaz.
Revocation-first design: Zrušení souhlasu musí být jedním klikem, stejně snadno dostupné jako jeho udělení.
Penetrační testy a red teaming: Se zaměřením na obejití SCA, manipulaci se scope a zneužití tokenů.

KPI a metriky pro řízení rizika

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

Incident response: co když se něco pokazí

Okamžité zmražení souhlasu (banka) a revokace tokenů (TPP) s notifikací klienta.
Forenzní extrakce logů s důkazy integrity (podpisy, časová razítka) a vytvoření immutable kopií.
Oznamovací povinnosti podle GDPR/PSD – ve stanovených lhůtách, s popisem dopadu a doporučeními pro klienty.
Post-incident opatření – zkrácení platností, zpřesnění scope, doplnění step-up autentizace.

Kontrolní seznam před produkcí (TPP/banka)

Máme UX souhlasu s jasným účelem, rozsahem a expirací; uživatel může odvolat jedním klikem.
Tokeny jsou krátkodobé, vázané na klienta a přenášené přes mTLS se signed requests.
Logujeme všechny zásadní události s ochranou proti manipulaci a máme definovaný retention.
Politiky GDPR: minimalizace, retence, přístupová práva – implementované a testované.
Revokační toky jsou automatizované a testované na krajní případy (offline klient, expirované tokeny).

90denní plán zavedení v organizaci

Dny 1–30: Definice politik souhlasů 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, signed requests; budování dashboardu souhlasů; integrační testy s pilotní bankou/TPP.
Dny 61–90: Penetrační testy, cvičný incident, úprava retenčních politik, 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 vytvářejí z této svobody bezpečnou infrastrukturu. Granulární scope, krátké platnosti, přísné bezpečnostní standardy a transparentní logování jsou klíčem, díky kterému si uživatel i regulátor mohou kdykoli ověřit, kdo k čemu přistupoval a na jakém základě.