Mit kell tennünk a jövőben ahhoz, hogy a banki adatvagyon hasznosítására alapozhassunk innovatív, digitális pénzügyi szolgáltatásokat a PSD2 szerint?

Piacnyitás, verseny, EU-szerte azonos szolgáltatási feltételek, open API és még sorolhatnánk. Vajon  mennyire engedte ki a gyeplőt a szabályozó? Mik a felelősségi szabályok?

 

1./ Piacralépés: regisztráció vs engedélyezés

A  jelenleg konzultáció alatt lévő AISP regisztrációs és a PISP engedélyezési eljárását bemutató ajánlás tervezet alapján:

  • az AISP, azaz a számlainformációkat összesítő szolgáltató csupán regisztráció köteles. Nem szükséges szavatoló tőkével rendelkeznie, elég egy független biztosítóval kötött szakmai felelősségbiztosítás igazolása. Alapvető követelmény a technikai és IT infrastrukturális feltételek kiépítésén és annak független auditor általi hitelesítésén túl 3 éves üzleti terv, teljes vállalatirányítási szabályzat, adatvédelmi- és IT biztonsági szabályzat bemutatása.
  • Az innovatív fizetési szolgáltatást nyújtó – PISP – szolgáltató tekintettel arra, hogy az ügyfelek pénze felett rendelkezhet, engedélyt kell szerezzen, melynek alapfeltétele 50.000 Euro alaptőke rendelkezésre állásának auditált számlakivonattal történő igazolása (a szakmai felelősségbiztosítás mellett).  Az előző bekezdésben említett követelményeken az ügyfélpénz védelmére intézkedéseket kell tenni, melyeket be kell mutatni, valamint teljes compliance átvilágításon esik át a szervezet – és a menedzsment – az engedély kiadása előtt. A tagállami bankfelügyelet előírhat szervezeti szétválasztási kötelezettséget a PISP szolgáltató számára, amennyiben az pl. AISP szolgáltatást is nyújtani szeretne.

 

2./ Nem elég felkerülni a regisztrációs listára, vagy megszerezni az engedélyt, a szolgáltatás nyújtásához többek között ügyfélelérés is kell.

A PSD2 adathozzáférési kötelezettsége keretében a  folyószámla-kezelő rendszerekhez nyílt szabványos API-n keresztül a bankok térítésmentesen kötelesek hozzáférést biztosítani a regisztrált, vagy engedély birtokában lévő szolgáltatók számára.

Milyen adatokhoz lehet részben a PSD2, részben pedig a nyílt banki adatok körét meghatározó munka nyomán hozzáférni?

Az ügyfél fizetési számla adataihoz (a PSD2 ennél mélyebbre nem megy). Az OBS (Open Banking Standards)  zászló alatt folyó munka nyomán születhet meg az adathozzáférési kötelezettség tartalmának definíció rendszere is.

Hozzáférés, de hogyan?  – Nyílt szabványos interfészen keresztül.

A szabványosítási folyamat ütemterve alapján ez év végén megismerjük a nyílt banki adatok, mint pl. ATM-k és bankfiókok adatainak olvasására alkalmas API szabványt, 2017.Q1-re az ügyféladatok és pl. az egyenleg olvasására alkalmas API szabványt, majd 2018.Q1-re pedig már azt  a szabványt, ami az AISP, azaz a számlainformációk összehasonlítását – erre alapozva pl. PFM szolgáltatást – kínáló szolgáltató működéséhez szükséges.  2019.Q1-ben látjuk majd a teljes funkcionalitású read-write API szabványt.

 

3./ Hogyan igazolja magát az új – AISP , PISP – szolgáltató, hogy a megfelelő engedélyek birtokában van és hogy az ügyfél felhatalmazta arra, hogy adataihoz hozzáférjen?

A PSD2 alapján alapszabály, hogy az AISP és a PISP szolgáltató azon túl, hogy megszerzi a tagállami bankfelügyeletnél  a regisztrációt/engedélyt a kiszolgálandó ügyfél explicit felhatalmazását is meg kell szereznie,  illetve minden tranzakció előtt a bank felé ezt bizonyítania kell.

A vonatkozó részletszabály (Draft Regulatory Technical Standards on Strong Customer Authentication) generális álláspontja, hogy 2-faktoros azonosítást  kell alkalmazni főszabályként. Az azonosítás módját a fogadó bank határozhatja meg  – fraud esetekben teljes felelősségvállalás mellett -, a hozzáférést kérő szolgáltatónak alkalmazkodnia kell.

A 2 faktoros azonosítás előírása az online fizetésekre elég nagy vitát kelt a webáruházak, a webáruházak számára fizetési megoldásokat nyújtó cégek részéről, tekintettel arra, hogy a checkout folyamat nehezítése az amúgy épp felvirágzás alatt lévő e-kereskedelem – elektronikus fizetési tranzakcióinak – csökkenését idézheti elő.