Az MNB júliusban publikálta a nyílt bankolás terjedését segítő „akadálymentesítő” ajánlást. Megkerestük a FintechX csoporthoz tartozó Aggreg8 csapatát, hogy segítsenek értelmezni az MNB ajánlást. Emellett közösen leteszteltük, hogyan néz ki jelenleg a folyamat a legnagyobb hazai bankoknál, amikor egy harmadik feles szolgáltató (pl. nyilvántartásba vett fintech startup) kíván rácsatlakozni a PSD2-es banki API-hozzáférésre.

A hazai ajánlás kiadására azért volt szükség, mert 2019. szeptember 14., a PSD2 teljeskörű kötelező alkalmazása óta nem történt érdemi előrelépés a nyílt bankolás terén.

“Az akadályozás leggyakrabban úgy valósul meg, hogy a hozzáférési interfészeket úgy alakítják ki a bankok, hogy azzal kellemetlenséget okoznak az azokat igénybe vevő ügyfeleknek, illetve a harmadik fél szolgáltatóknak”

– fogalmazta meg az MNB a Fizetési Rendszer Jelentésben.

Korábbi megkeresésünk során az MNB azt nyilatkozata, “az ellenőrzések során megállapítást nyert, hogy az API-k elkészültek ugyan, de az API-k működése nem feltétlenül felhasználóbarát módon került kialakításra, ami ösztönözné a minél szélesebb körű használatot.”

Az alábbiakban bemutatjuk egy táblázatos formában, hogy a nagyobb hazai bankok által biztosított PSD2 API csatornák teljesítik-e a kérdéses elvárásokat. Továbbá értelmeztük az Aggreg8 csapatával közösen, hogy a Magyar Nemzeti Bank milyen pontok tekintetében fogalmazott meg fenntartásokat és jó gyakorlatokat.

A Magyar Nemzeti Bank az ajánlásban foglaltak alkalmazását 2021. augusztus 1-től várja el a felügyelt pénzintézetektől.

Magyarországi banki API-körkép

Az alábbiakban összefoglaltuk az Aggreg8 csapatával közösen végzett tesztelés összefoglaló eredményeit táblázatos formában. A közös tesztelést az MNB ajánlás alábbi fejezet pontjaira végeztük el:

• I. Többszörös erős ügyfél-hitelesítés
• III. Bankszámlaszám végfelhasználó által történő manuális megadása

A többi fejezet ponttal kapcsolatos tapasztalatokat az Aggreg8 2019. szeptember 14-e óta gyűjti. Ezekkel kapcsolatban további információkat a hazai banki szakértők a psd2@aggreg8.io email címen kérhetnek.

Az MNB által kiadott ajánlás két vizsgált pontjában (I., III.) a tesztelés főbb megállapításai:

• A vizsgált 12 hazai bankból a GRÁNIT Bank, az MKB Bank, a Sberbank és a Takarékbank teljesítették az MNB ajánlásait.
• Az MNB ajánlás alapján többszörös erős ügyfél-hitelesítés a 12 bankból 4 esetén fordult elő.
• A vizsgált 12 hazai bankból 7 nem teljesíti a „III. Bankszámlaszám végfelhasználó által történő manuális megadása” c. fejezetben megfogalmazott ajánlásokat.

Összességében a hazai bankok meghatározó része úgy alakította ki az interfészeket, hogy azok kellemetlenséget okoznak a nyílt bankolásra épülő szolgáltatásokat (pl. számlainformációkat összesítő szolgáltatásokat) igénybe vevő ügyfeleknek. 2021. augusztus 1. óta viszont ezeket a kellemetlenséget meg kellett volna szüntetniük a bankoknak. Az eredményeket pár hónap múlva visszateszteljük.

A nyílt bankolás terjedését segítő megoldásokkal , a digitális pénzügyi ökoszisztémák építésével, a digitális transzformáció új irányaival részletesen foglalkozunk 2021. október 7-8. között az idén 5 éves FinTechShow-n. 40 hazai és nemzetközi előadóval vizsgájuk meg, hogyan alakulhat át a pénzügyi közvetítői rendszer a következő években.

MNB elvárások és jó gyakorlatok

A szabályozó megerősíti, hogy egy pénzintézet a PSD2 API műveletek végzése során (akár AIS, PIS, vagy CIS műveletről van szó) nem kérhet több alkalommal, szélesebb tartalommal, vagy bonyolultabb módon erős ügyfél-hitelesítéshez szükséges adatokat/akciókat a végfelhasználóktól, mint amit a végfelhasználónak az adott művelet elvégzéséhez a bank saját felületén (netbanki felületen, vagy mobilalkalmazásban) kellene végrehajtania a művelet elvégzéséhez.

Értelemszerűen nem minősül akadályozásnak az az eset amennyiben egy pénzintézet több külön erős-ügyfélhitelesítést kér akkor, ha a felhasználó egymást követően különböző (AIS/PIS/CIS) műveleteket kezdeményez, vagy abban az esetben sem, ha egy művelet végrehajtása a bank saját felületén is több erős ügyfél-hitelesítéssel jár (például egy fizetéskezdeményezés esetében, amikor a netbank esetében is két SCA kört kér a bank a belépéshez és a fizetéskezdeményezés aláírásához).

A szabályozó kimondja, hogy amennyiben egy pénzintézet az SCA rendelet szerinti kivétel szabályt alkalmaz az erős-ügyfélhitelesítés tekintetében bármely TPP esetében, akkor az adott kivételszabály alkalmazását minden más TPP esetében is alkalmazni köteles.

Ez a szabályozás a gyakorlatban azt jelenti, hogy

• alapesetben egy TPP a felhasználótól kapott 90 napra szóló felhatalmazás alapján napi 4 passzív (ügyfél jelenléte nélküli) lekérdezést tud RTS szerint külön a végfelhasználó által végig vitt SCA azonosítás nélkül indítani.
• Amennyiben egy bank egy TPP-nek biztosítja azt, hogy a felhasználótól kapott 90 napra szóló felhatalmazás alapján a napi 4 db-ot meghaladó számú passzív lekérdezést, vagy a napi 4 db passzív lekérdezésen túl a felhasználó az általa indított „aktív felhasználás” keretében újabb SCA teljesítése nélkül tud hozzáférni a számlainformációihoz az SCA rendelet kivétel szabálya alapján, akkor ezt minden más TPP számára is biztosítania kell.
• Viszont amennyiben egy bank senkinek nem biztosítja az RTS-ben meghatározott napi 4 db passzív lekérdezésen felüli esetben az SCA kivételt, akkor az nem számít a TPP szolgáltatásnyújtás akadályozásának.

A szabályozó explicit módon kijelenti, hogy amennyiben a pénzintézet PSD2 API-ján keresztül csak úgy végezhető valamilyen művelet, hogy a művelet elkezdéséhez előzetesen a végfelhasználó által manuálisan meg kell adni a műveletben érintett pénzforgalmi számla számát (azaz a bankszámlaszámot), akkor az a TPP szolgáltatásnyújtás akadályozásának minősül.

Az MNB például jó gyakorlatnak tartja, ha az ügyfél pénzintézet oldalán történő hitelesítése után a pénzintézet felületén egy listából tudja kiválasztani az elvégezni szándékozott műveletben érintett számlát, vagy számlák körét. Az ajánlás ezen ponton is kitér arra, hogy egy adott művelet elvégzése (számlainformációk lekérése, fizetéskezdeményezés) nem lehet bonyolultabb az API csatorna használatával, mint a bank saját felületeinek használata során.

A szabályozó elvárja, hogy azon végfelhasználók, akik a bank saját felületén keresztül valamilyen API-n keresztül is kezdeményezhető műveletet indíthatnak (pl. számlainformáció lekérés, vagy átutalás indítása), ugyanazoktól a felhasználóktól a bank nem kérhet semmilyen addicionális hozzájárulást, előzetes regisztrációt, vagy beleegyezést, hogy ugyanazokat a műveleteket az API csatorna használatával is elvégezhessék.

A bank ezzel együtt biztosíthat olyan felületet, ahol a végfelhasználó kifejezett ilyen irányú döntése alapján meghatározott TPP számára letilthatja a számlahozzáférést és/vagy fizetéskezdeményezési szolgáltatás elérését.

A szabályozó előírja, hogy a pénzforgalmi intézmények technikai okokból szükséges regisztrációs folyamatok (pl. TPP Cert megosztása) kivételével addicionális feladatokat és lépéseket követeljenek meg a TPP-ktől az API hozzáférés biztosítása érdekében, azonban ez a folyamat nem tarthat a regisztráció kezdeményezését követő munkanap végénél tovább.

Ugyanígy nem kötheti a bank a TPP számára a hozzáférés biztosítását a bank és a TPP közötti szerződéses jogviszony létrejöttéhez (ez utóbbi kitétel az ajánlás III. 7 / 23-as pontjában szerepel az Egyéb elvárások között, de tartalmilag ehhez a ponthoz tartozik).

A szabályozó elvárja, hogy API csatorna használatánál a végfelhasználók minden olyan hitelesítési eljárást (pl. SMS, VICA, biometrikus azonosítás) használhassanak, melyet a bank saját felületeinek használata során biztosít a végfelhasználó számára.

A szabályozó továbbá elvárja, hogy az azonosítási folyamat egyes banki felületen végzett lépései során a bank ne alkalmazzon olyan nyelvezetet, megfogalmazást, ami akár közvetlenül, vagy közvetve eltántorítaná a végfelhasználót a TPP szolgáltatásnyújtásának igénybevételétől.

A szabályozó elvárja, hogy pénzforgalmi intézmény ugyanazokat a díjakat számolja fel a végfelhasználóknak saját felületeinek használata során, mint az API csatornák használata során (azaz nem különböztetheti meg az egyes csatornákat díjszabásban, vagy például azzal, hogy egy netbanki bejelentkezés során erős ügyfél-hitelesítés érdekében kiküldött SMS után nem számol fel díjat, míg egy API csatorna erős ügyfél-hitelesítési folyamatában kiküldött SMS után költséget számol fel a végfelhasználónak).

A szabályozó felhívja a figyelmet, hogy az API technikai specifikációjának bármely változását előzetesen, de legalább 3 hónappal a változás végrehajtása előtt TPP-k rendelkezésére bocsássa – kivéve sürgős helyzetek, melyek tekintetében pénzforgalmi intézménynek dokumentálási kötelezettsége van, továbbá ezt a dokumentációt kérésre MNB rendelkezésére kell bocsájtania. MNB felhívja továbbá a bankok figyelmét arra, hogy a „sürgős helyzet” esetében történő módosítás sem járhat azzal, hogy TPP-k szolgáltatásnyújtása indokolatlanul hosszú időre akadályba ütközzön.

Szintén a TPP szolgáltatásnyújtás akadályozásának minősíti a szabályozó azokat az eseteket, amikor a banki API csatorna technikai specifikációja indokolatlanul gyakran módosul, illetve ha egy banki oldalon felmerülő hibajavítás a technikailag szükséges időnél tovább tart.

Szabályozó továbbá elvárja a bankoktól, hogy amennyiben a PSD2 API interface tekintetében bármilyen, a használatát befolyásoló váratlan esemény következne be, akkor arról a banknak haladéktalanul értesítenie szükséges az API-t használó TPP-ket, mihamarabb visszaállítani az API megfelelő működését (és mentesség esetét kivéve) köteles a kieső időre tartalékmechanizmust biztosítani a szolgáltatások elérésére.

Szabályozó kimondja, hogy akár a törvényben felsorolt pénzforgalmi indokkal (fraud gyanús), vagy egyéb törvényi megfelelés (pl AML, GDPR) érdekében a számlavezető pénzforgalmi intézmény jogosult lehet korlátozni egy adott TPP szolgáltatásnyújtását, de ebben az esetben a szolgáltatás nyújtás korlátozásának okát az MNB felé meg kell tudnia indokolni és az MNB-t tájékoztatnia kell.

A felfüggesztés tényét és indokát az érintett TPP felé is kommunikálni szükséges és amennyiben a korlátozás indoka már nem áll fenn, akkor a technikailag lehetséges időn belül, de legkésőbb a következő munkanap végéig vissza kell állítani TPP API hozzáférési jogosultságait.