Představení PSD2 nejen pro vývojáře. Blíží se otevřené bankovnictví? Udělejte si v tom jasno.

Ačkoliv mi připadá, že články o PSD2 se to všude jen hemží, překvapuje mě, že spousta mých známých má problém se v současné situaci vyznat. Naopak mají pocit, že s další novou informací mají o PSD2 větší nejasnost. Pokusím se to tímto textem změnit.

Celý článek

Od léta 2017 jsem pracoval jako architekt a vývojář na různých projektech spojených s PSD2. Jednalo se jak o vystavování openbanking API (server side), tak i o konzumaci API různých bank (client side). Sice neznám detailně všechny právnické předpisy spojené s PSD2, ale zato mám spoustu praktických zkušeností, které by mohli ocenit hlavně vývojáři.

Pojďme si nejprve shrnout obecná fakta. Technické informace najdete až v druhé části Pro vývojáře.

Co je PSD2 (Payment Services Directive)

Lidé často spojují PSD2 a openbanking, ale každý z těchto termínů znamená něco trochu jiného.

PSD2 je směrnice*) EU z roku 2015, která se obecně zabývá platebními službami. Směrnice vznikla, aby sjednotila poskytování platebních služeb v EU a poskytla tak výhody pro její občany. I díky novým technologiím (např. možnosti placení na internetu) totiž vznikly nové obchodní příležitosti, které ale nebyly podchyceny starým právním řádem. Děravý právní řád pak znamená použití práva džungle. A to vůbec není dobré pro koncové uživatele.

*) co to je směrnice a jak se liší od nařízení najdete v části Právnické předpisy a jejich platnost.

Byla tedy vytvořena jednotná EU směrnice, která klade za cíl, že pravidla je nutné nastavit tak, aby v novém (digitálním) prostředí byl ochráněn koncový uživatel. Hodně se mluví o bezpečnosti – směrnice popisuje (ale velmi obecně), jak musí poskytovatelé platebních služeb (tedy obchodníci a banky) zabezpečit svoje systémy a platební procesy.

Zásadním bodem byla ale definice platebních služeb. Předchozí směrnice PSD1 z roku 2007 (resp. s platností od r. 2009) zavedla tuto tehdy novou kategorii:

Provádění platebních transakcí, kdy je souhlas plátce s provedením platební transakce dáván pomocí jakéhokoliv telekomunikačního, digitálního nebo informačně technologického zařízení a platba je provedena ve prospěch provozovatele dané telekomunikační nebo informačně technologické soustavy nebo sítě, který jedná výlučně jako zprostředkovatel mezi uživatelem platebních služeb a dodavatelem zboží nebo služeb. (příloha “Platební služby”, bod 7)

Směrnice PSD2 pak tuto kategorii zrušila a místo ní zavedla dvě nové:

• Služby iniciování platby.
• Služby informování o účtu.

Viz “Příloha I”, body 7 a 8.

Pokud jste už někde viděli zkratky PIS (Payment Initiation Services) nebo AIS (Account Information Services), tak to je přesně ono. Resp. jste mohli potkat PISP a AISP, kde poslední “P” = Provider.

Kromě těchto dvou budeme používat i další zkratku CISP = Card-based Payment Instrument Issuing Service Provider. To jsou ti poskytovatelé platebních služeb, kteří umožňují platit pomocí karet. Ale pozor, v případě PSD2 nemáme na mysli klasické platební karty (debetní, kreditní), ale vlastní karty vydávané např. obchodníky, které ale lze použít k placení v rámci obchodního řetězce.

Openbanking pro Third Party Providers

Směrnice PSD2 umožňuje, aby platební služby byly poskytovány i nebankovními institucemi – tzv. Third Party Providers (TPPs) – které se dnes označují také jako „FinTech“.

No a samozřejmě, aby to bylo technologicky zvládnutelné, tak PSD2 směrnice nařizuje bankovním institucím, aby otevřely svá API. A o tom openbanking je – možnost používat otevřená / dokumentovaná / podporovaná API.

Pokud by totiž směrnice nenařídila bankám otevřít svá API, pak by třetí strany musely používat tzv. screen scraping, nebo modernější mobile API scraping nebo tradičnější proprietární API pro partnery.

Screen scraping

Screen scraping je obecný název pro všechny metody získávání dat jinak než voláním veřejných API. Takže sem spadá volání neveřejných (bankovních) API a třeba i parsování HTML stránek, resp. DOM modelu stránek. Samozřejmě to není podporovaná metoda ze strany banky. Naopak banky (a nejen ony) se brání, pokud někdo chce získávat uživatelská data tímto způsobem – např. i častou změnou neveřejných API.

Aby screen scraping mohl fungovat, pak koncový uživatel musí poskytnout své přístupové údaje třetí straně. A to je jednak nebezpečné, jednak tím uživatel porušuje ujednání s bankou – přístupové údaje nesmí přece nikomu sdělovat!

Takže openbanking nahrazuje screen scraping.

Multibanking

Banky byly nejprve nerady, že musí otevřít svá API třetím stranám. Bály se, že přijdou o své klienty. Pak si ale uvědomily, že samy mají možnost se připojit ke svým konkurentům. A začal závod o to, kdo se dřív napojí na ty ostatní. Tak vznikl pojem multibanking – obsluha bankovních účtů z různých bank v internetovém bankovnictví jedné banky.

Právnické předpisy a jejich platnost

Nejsem sice právník, ale zkusím vám trochu předkousat, co je psáno v paragrafech.

Právní akty EU

Je dobré znát, jakým způsobem může EU vydávat svá nařízení. Detailní popis najdete na wikipedii, nás bude zajímat hlavně rozdíl mezi směrnicí a nařízením:

• Směrnice musí být zakotvena do práva členského státu.
• Nařízení platí bezprostředně v každém státu EU.

RTS pro SCA aneb standard pro bezpečnou autentizaci

Samotná PSD2 směrnice je velmi vágní. Ale přikazuje vypracovat podrobnější technická nařízení – v angličtině regulatory technical standards = RTS. Asi to nejdůležitější nařízení se týká tzv. Silného ověření klienta (strong customer authentication = SCA). V něm se řeší principy komunikace mezi koncovým uživatelem, třetí stranou a bankou – ale pořád je to na abstraktní úrovni – nějaké odkazy na RFC standardy nebo snad swagger (OpenAPI) definice byste tu hledali marně.

SCA říká, že platby musí být autorizovány alespoň dvěma ze tří možných způsobů:

• co uživatel zná – např. heslo nebo bezpečnostní otázka
• co uživatel má – např. telefon, hardwarový klíč
• co uživatel je – sem patří biometrické údaje – otisk prstu, face ID

Jeden by čekal, že vznikne detailní technická specifikace pro celou EU. Bohužel, to se nestalo. Konkrétní specifikace ponechalo EU na členských státech. Zde končí nadějné vyprávění o jednotných standardech. Dnes existuje několik standardů, ale stejně si každá banka může vybrat, jak své řešení naimplementuje – stačí, když splní požadavky právních předpisů. Bod pro banky, prohra pro konzumenty API.

Kdy?

A jak je to s tou platností? Inu, docela složité. PSD2 byla vypracována v roce 2015 a nařídila, aby členské státy použily související předpisy od 13. ledna 2018. Tedy počítalo se, že dva roky budou stačit na vypracování všech potřebných nařízení byla. Ale bohužel nestačily. To nejdůležitější, tj. RTS pro SCA, bylo vypracováno až v listopadu 2017 a definuje tyto milníky:

• 14. března 2019: banky musí vystavit dokumentaci svých API a zajistit testovací provoz pro třetí strany
• 14. září 2019: banky musí spustit svá API v ostrém provozu

Celé je to komplikované tím, že jednotlivé státy musí tyto EU dokumenty mít včleněné do svých zákonů, které ovšem mají také svou platnost. Čeští politici tentokrát nezaspali a směrnici v českém právu ukotvili zákonem č. 370/2017 Sb.

Licence ČNB

Konečné slovo má navíc Česká národní banka. Ta uděluje licence poskytovatelům služeb (AISP, PISP, CISP). Banky mají licenci automaticky. Aby nebankovní instituce dostaly licenci, musí splnit náročné podmínky. V současnosti má licenci v ČR pouze jedna nebankovní instituce.

PSD2 pro vývojáře

Následuje slíbená část, na kterou jistě čekáte.

Openbanking standardy

Jak už jsem psal, EU nestanovuje přesné technické standardy, jak mají banky svá API vystavit. Bankovní asociace v jednotlivých zemích tedy začaly definovat své lokální standardy – rozuměj definice, jak mají API bank vypadat. A tak se stalo, že v současnosti máme:

• v České republice Czech Standard for Open Banking (COBS),
• na Slovensku mají svůj Slovak Banking API Standard (SBA),
• v dalších státech se prosazuje hlavně tzv. Berlin Group Standard.

Každý z těch standardů je jiný. Jiné sady URL, jiné HTTP metody u semanticky stejných API, jiné struktury JSON request/response objektů. Jinak řešená autorizace aktivních operací (plateb). Na druhou stranu lze dohledat spoustu podobností:

• Autorizace přístupu TPP na data koncového uživatele je řešena pomocí OAuth2
• Názvy HTTP headerů, např. PSU-IP-Address, jsou shodné v SBA i Berlin Group standardech
• Názvy některých JSON atributů

Lze vysledovat, že podobnost v názvech JSON atributů je založena na jiných existujících standardech – konkrétně na standardu ISO 20022, který definuje, jak mají banky komunikovat vzájemně mezi sebou.

COBS Standard

Český standard vznikal na půdě České bankovní asociace. Prakticky to dopadlo tak, že do návrhu si každá banka prosadila své zájmy a specifika. S oblibou říkám, že to je podobné, jako když pejsek s kočičkou vařili dort. Multiměnové účty od jedné banky, specifické atributy transakcí od druhé banky, autorizace plateb od třetí banky.

Z formálního hlediska se také nejedná o žádný zázrak. Původní Word už aspoň nahradil export do PDF (v dnešní verzi už fungují i odkazy). Struktura JSON dokumentů je popsána tabulkou, kde úroveň zanoření se označuje pomocí počtu znaků “+”. Docela nešikovné počítat, zda jich tam je osm nebo devět. V prvních verzích byly časté chyby – špatná kardinalita, nekonzistence mezi definicí a příklady.

Příklad definice JSON dokumentu dle COBS

Nejhorší je, že neexistuje žádná oficiální swagger (OpenAPI) definice. Takže aby si každá banka psala vždy svou vlastní.

V současnosti český standard definuje sadu třech API endpointů pro přístup k účtům (AIS) – seznam účtů, detail zůstatku a seznam transakcí pro daný účet:

• GET /my/accounts
• GET /my/accounts/{id}/balance
• GET /my/accounts/{id}/transactions

I zde je vidět nedůslednost autorů – proč tam není “balances”? Jednak by to spíš odpovídalo RESTovým pravidlům, jednak toto API nevrací jeden zůstatek, ale kolekci zůstatků (účetní, blokovaná…).

Pro platby (PIS) je API endpointů více – jednak operace s platbou a dále s její autorizací – to je zřejmě to nejsložitější v celém openbankingu:

Není mi jasné, jak mohli autoři zapomenout na API pro seznam plateb (GET /my/payments). Bez něho je tedy nutné, aby si konzument API “pamatoval” všechny své zadané platby – resp. jejich paymentId.

Autorizace platby je velmi specifická pro každou banku, API jsou navržena volně, navíc není povinné implementovat všechny endpointy. COBS dal volnost bankám, konzumenti API opět prohrávají.

Pro úplnost ještě API pro CISPy – zde se jedná pouze o API, které zjišťuje, zda lze provést platbu z účtu, resp. zda na účtě je dostatek prostředků:

• POST /accounts/balanceCheck

V současnosti se prý pracuje na rozšíření specifikace i pro trvalé platby, hromadné platby a odvolání platby. Prý je to z důvodu, že nedávná aktualizace RTSky vyžaduje povinně vystavení i těchto API.

SBA Standard

Slováci si se standardem dali evidentně více práce, resp. jejich dokument už vypadá jako specifikace. Navíc udělali i technickou specifikaci v Apiary.

Dokonce i popis autorizace plateb dává člověku pocit, že i tuto složitou funkcionalitu může pochopit každý.

Principy komunikace

Představíme si jednoduchý příklad, kdy uživatel chce použít aplikaci pro agregaci účtů – tedy chce vidět své účty z různých bank na jedné obrazovce. Použije k tomu tedy nějakou aplikaci od třetí strany – TPP (anebo banky, která implementovala do svého bankovnictví multibanking).

Příprava na straně Third Party Provider

Ještě předtím, než TPP mohl uživateli nabídnout svou aplikaci, musel získat licenci od centrální banky (u nás ČNB). Dále se TPP musel zaregistrovat u těch bank, na které se chce napojit. A od nich získat aplikační klíče pro svou aplikaci (viz níže).

TPP komunikuje s bankovními API pomocí HTTPS s klientským certifikátem. Používají se eIDAS certifikáty (RTS povoluje typ QWAC i QSEAL). V certifikátu je uloženo číslo licence a typ providera (AISP, PISP, CISP). Tak banka pozná, který TPP s ní komunikuje. Specifikace opět není jednotná napříč Evropou, ale existuje naděje, že by se to mohlo ještě zlepšit.

Protože TPP může provozovat více aplikací, tak je nutné v každém requestu uvést ještě unikátní klíč aplikace. Ten se vygeneruje ve vývojářském portálu banky pro každou aplikaci. Aplikace ho pak posílá jako domluvený HTTP header (např. API-Key, Web-API-Key apod.)

Připojení banky

Uživatel si v agregační aplikaci musí nejprve banku připojit. To znamená, že si vybere jednu ze svých bank – pokud ji má ovšem agregační aplikace na seznamu podporovaných bank.

Výběr banky v agregační aplikaci / multibankingu

V tom okamžiku začíná autentizační proces – kolotoč HTTP přesměrování mezi TPP (frontend) aplikací, bankovním autentizačním serverem, TPP backend aplikací a zpět TPP frontendem aplikace. Celý proces je složitý kvůli tomu, aby citlivé přihlašovací údaje uživatel předal pouze bankovnímu autentizačnímu serveru. TPP aplikace se k přihlašovacím údajům nedostane, pouze v případě úspěšného přihlášení dostane přístupový token s omezenou platností.

Zjednodušené schéma OAuth2 autentizace. Plná verze od připojení banky až po finální přesměrování obsahuje celkem 33 šipek.

Pokud všechno proběhne v pořádku, pak je uživatel na konci procesu přesměrován zpět do agregační aplikace, kde by měl vidět i účty, ke kterým dal svolení.

POZOR: Pokud po vás agregační aplikace chce vaše přihlašovací údaje napřímo, pak pravděpodobně používá screen scraping. Takovou aplikaci bych osobně nepoužíval.

Svolení – consent

Při autentizaci ještě banka po přihlášení žádá uživatele o udělení souhlasu – consentu – pro danou aplikaci a v daném rozsahu (AISP, PISP) ke svým datům. Někdy je možné zvolit i konkrétní účty, ke kterým dáváte svolení k přístupu.

Souhlas pak může uživatel kdykoliv odvolat v domovském internetovém bankovnictví a tím i zneplatnit přístup dané aplikace ke svým účtům.

Příklad obrazovky pro udělení souhlasu – consentu.

Access a refresh token

Při použití OAuth2 protokolu dostane aplikace dvojici tokenů – access_token a refresh_token (OAuth2 Authorization Code Grant). Aplikace si je musí asociovat s daným uživatelem (každý uživatel dostane jiný!).

Access token má krátkodobou platnost (typicky několik minut), ale TPP aplikace ho může použít přímo v hlavičce HTTP requestu při volání bankovních API, např.:

Authorization: Bearer ACCESS_TOKEN_VALUE

Refresh token má dlouhodobou platnost – COBS standard specifikuje jeho délku na 90 dnů od udělení souhlasu. Refresh token slouží pro výměnu nového páru access a refresh tokenů v okamžiku, kdy aplikace potřebuje volat bankovní API, ale platnost původního access tokenu již vypršela.

API Quota

Díky refresh tokenu může tedy aplikace volat bankovní API, dokud platnost tokenu nevyprší. U nás je to zhruba 3 měsíce od udělení uživatelského souhlasu. Za tu dobu si může stahovat seznamy transakcí na účtu (za posledních 90 dnů) a sledovat vývoj zůstatku. Platby si sama autorizovat nemůže, tam se očekává tzv. SCA – silná autorizace.

RTS pro SCA říká, že TPP aplikace si může autonomně (bez přítomnosti uživatele – typicky nějaký scheduler) stahovat data 4x denně. Bohužel ale tato definice je opět nejasná a každá banka si ji vysvětluje jinak. Posuďte sami:

Poskytovatelé služeb informování o účtu mohou získat přístup k informacím o určených platebních účtech a souvisejících platebních transakcích, které mají k dispozici poskytovatelé platebních služeb, kteří vedou účet, pro účely poskytování služeb informování o účtu v kterémkoli z těchto případů:

1. požaduje-li aktivně tyto informace uživatel platebních služeb;
2. pokud uživatel platebních služeb tyto informace aktivně nepožaduje, nejvýše čtyřikrát během 24 hodin, ledaže je mezi poskytovatelem služeb informování o účtu a poskytovatelem platebních služeb, který vede účet, se souhlasem uživatele platebních služeb dohodnuta vyšší četnost.

Háček je také v tom, že banka vlastně nemůže poznat, zda TPP aplikace volá bankovní API autonomně, nebo aktivně na popud uživatele, který se zrovna vrátil do TPP aplikace. Takže banky by správně neměly omezovat TPP aplikace, měly by pouze monitorovat a reportovat. Bohužel se tak neděje a jsem zvědav, jestli se vůči nim někdo ohradí.

Auditní log v domovském bankovnictví

Jak na transakce

Transakce na bankovním účtu přibývají neustále. Není ale zajištěno, že se připisují vzestupně. Může se stát, že je připsána transakce k datu zpětně. Tak se může stát, že i když si TPP aplikace stáhne všechny transakce za minulý týden, tak nemusí být zaúčtované na straně banky ještě všechny.

Další problém je, že TPP aplikace musí volat API na seznam transakcí pro každého uživatele, resp. pro každý jeho účet zvlášť. Pokud se multibanking prosadí, pak to bude znamenat enormní nárůst počtu volání bankovních API. Může se stát, že daný AISP nebude schopen obsloužit více než N klientů, protože prostě nebude schopen provést tolik requestů za den.

Přitom by bylo jednodušší vyměnit polling za pushing – banka by poslala notifikace o nových transakcích danému TPP až v okamžiku jejich uskutečnění, samozřejmě bulkově. Na to ale žádný ze standardů nemyslel.

Připojujeme se na sandboxy

Pokud se chcete připojit na API konkrétní banky a nejste licencovaný AISP/PISP/CISP poskytovatel (což kromě bank a jedné nebankovní instituce v čechách nikdo jiný do dnešního dne není), tak i přesto máte možnost si vyzkoušet připojení k jedné či vícero českých bank.

API sandbox

Banky mají totiž povinnost mít svá API zdokumentovaná a dokonce poskytnout možnost otestovat si jejich volání. Ačkoliv tato povinnost platí pro licencované poskytovatele, tak banky často (ale ne vždy) tuto možnost dávají všem. Typicky mají volně přístupný tzv. API sandbox, kde si vývojář může volání API otestovat.

API sandbox může být jednoduchý bez autentizace (pak ale neotestujete autentizační flow své aplikace), anebo sofistikovaný, kde dokonce můžete zadávat i autorizovat platby.

Například u Equa Bank nepotřebujete vůbec nic a můžete sandbox provolat – zkuste si sami:

$ curl https://api.equa.cz/sandbox/aisp/accounts/2.0.5/my/accounts

Developer portal

U jiných bank je potřeba se nejprve zaregistrovat jako vývojář a získat přístup do developer portálu dané banky. Většinou se jedná o bezbolestnou poloautomatickou proceduru. Jen jednou se mi stalo, že mi banka napsala, že pro registrační účely neakceptuje gmail účty a je potřeba použít nějaký firemní.

Poté, co se zalogujete do portálu, je potřeba zaregistrovat svoji aplikaci a získat pro ni přístupové údaje – pro OAuth2 to je dvojice client_id a client_secret. Občas banka může přidělit ještě dodatečný klíč pro volání PSD2 API endpointů.

Seznam registrovaných aplikací, klíč API pro ne-OAuth2 API volání.

V nastavení aplikací je pak potřeba zvolit ta API, ke kterým budete chtít přistupovat. Tím se dá typicky odlišit, zda chcete jenom zjistit informace o účtu (chcete být AISP), nebo iniciovat platby (PISP) anebo se ptát na dostatek prostředků na účtu (CISP). Někdy máte možnost zvolit i jemnější granularitu – po jednotlivých API endpointech. Toto nastavení je pak důležité pro ostrý provoz, ale v případě sandboxu typicky zaškrtnete, že chcete volat všechna dostupná API.

Ukázka přiřazení API k aplikaci

Důležité je také nastavení spojené s autorizací přístupu vaší aplikace k datům koncového uživatele. Pokud sandbox nepodporuje autentizační flow, tak i přesto vás donutí nastavit tyto údaje. Na oplátku mu můžete podstrčit neexistující URL nebo URL na localhost a ještě k tomu jako nezabezpečené HTTP (zatím jsem se nesetkal s kontrolou).

Adresa v příkladu http://localhost:8080/http/oauth_redirect se použije jako callback v okamžiku dokončení autentizace koncového uživatele. V tom okamžiku bude mít naše aplikace možnost získat access a refresh token (viz OAuth2) pro koncového uživatele. Jak to celé flow funguje, o tom řeknu něco více třeba někdy jindy.

A je to

A to je vlastně vše. Nyní stačí správně nastavit přístupové údaje do aplikace (nebo do curl) a můžeme volat API sandboxu.

V případě problémů je možné napsat na podporu dané banky. Většinou odepisují během jednoho dne. Dost často se jedná o chybu dokumentace API (typicky proces autentizace, který se může lišit), anebo mají prostě něco špatně. Cituji z jednoho mailu:

I regret to inform you that behavior described bellow is a bug (apearing of the login screen after issued service call). We reported it to IT department and now we are waiting for correction.

Občas něco funguje a pak přestane fungovat:

Dear Vaclav.
let me thank you for your message.  We are sorry for this problem. There was a bug in our mocks due to yesterday’s changes. Right now everything should be OK as we have already deployed a new version of mocks.

Ve všech případech (bylo jich víc, než jsem uvedl) všechno dobře dopadlo a banky chyby opravily. Budeme doufat, že to tak bude i v ostrém provozu.

Závěr

Přestože si autoři PSD2 předsevzali, že sjednotí platební služby na trhu EU, rozhodně se tak nestalo. Stupeň volnosti je příliš velký na to, aby mohly vznikat jednotné platební aplikace.

Naopak je zde příležitost pro vznik tzv. PSD2 API agregátorů. Tedy aplikací, které budou řešit nejednotnost různých PSD2 API. Místo aby se každá platební aplikace napojovala na dvacet různých API od různých bank, tak se bude možné napojit na API agregátora, resp. na jeho API. Pokud API agregátor přidá do svého portfolia novou banku, pak platební aplikace bude na tuto banku napojena – a bez vývoje.

Na vývoji jedné takové aplikace jsem se podílel. Na některých screenshotech jste si možná všimli jejího jména – BeeHub. To je PSD2 API agregátor, který vyvíjíme v Banking Software Company.

Na závěr bych rád poděkoval svým kolegům Václavu Matouchovi a Luboši Račanskému za revizi textu, zpětnou vazbu a vlastně i za to, že celý článek vznikl.

Reference

• Payment Services Directive 1
• Payment Services Directive 2
• Seznam doplňujících nařízení komise (RTS)
• RTS pro SCA
• Český COBS Standard
• Slovenský SBA Standard
• Berlin Group Standard
• ISO 20022 Standard