Nagy várakozás övezte a PSD2-re épülő nyílt bankolás elindulását és bár Európa-szerte látni már figyelemre méltó kezdeményezéseket, több, mint két év után is összességében elmondható, hogy a nyílt bankolás gyerekcipőben jár még. A hozzáférési interfészek (API-k) nehézkes használata mellett a harmadik feles szolgáltatóknak egy másik kihívással, az eIDAS tanúsítványok megújítása, az új tanúsítvány szinkronizációja során leküzdendő akadályokkal is meg kell birkózniuk.

Magyarország első, Magyar Nemzeti Bank által regisztrált számlainformációs szolgáltatója (AISP) az Aggreg8, a FintechX csoport tagja már több mint két éve indította el API aggregátor megoldását. A témában itthon legtöbbet tapasztalt szolgáltató, az Aggreg8 vezérigazgatójával, Mudri Györggyel beszélgettünk a magyarországi bankoknál tapasztalható folyamatokról, valamint arról milyen kihívásokkal találkoztak a tanúsítványok megújítása során.

Mik azok az eIDAS tanúsítványok? Miért van fontos szerepük a nyílt bankolásban?

Az eIDAS tanúsítványok fontos szerepet töltenek be a PSD2 folyamatokban.

Használatuk kötelező annak biztosítása érdekében, hogy a számlainformációs adatok, illetve fizetés-kezdeményezési tranzakciók során közlekedő adatok mindenkor biztonságban legyenek és csak megbízható partnerek részére kerüljön átadásra.

A minősített bizalmi szolgáltatók (ú.n. QTSP) által kiállított tanúsítványok egyfajta útlevélként szolgálnak a bankok felé, a harmadik feles szolgáltatók (ú.n. TPP) ezzel azonosítják magukat a banki csatornákhoz való hozzáférés során. A tanúsítvány mellett a szolgáltatók továbbá rendelkeznek egy egyedi azonosítóval, a PSD2 engedélyszámmal. Míg ez utóbbi a TPP-k “élete során” nem változik, az eIDAS tanúsítványok változnak, tekintettel arra, hogy azok megújítása szükséges 1-2 évente.

Az EU-ban ugyanakkor nincsenek egyértelmű eljárások, illetve iránymutatások a bankok számára arra vonatkozóan, hogyan kezeljék az eIDAS tanúsítványok első alkalommal történő regisztrációját, illetve a lejáratot követő frissítését. Ennek következtében az egyes bankoknál eltérő folyamatokkal találkozhatnak a szolgáltatók és a tapasztalatok szerint a tanúsítványok megújítása, az új tanúsítvány szinkronizációja komoly akadályokba ütközik, akár veszélyeztetheti az üzletmenet folytonosságát a szolgáltatóknál.

Mi a tapasztalatotok a magyar bankok tanúsítvány kezelési folyamatával kapcsolatban? Milyen folyamatokkal találkoztatok itthon?

Mudri György: Amikor a tanúsítványok kezeléséről beszélünk, akkor ez alatt két külön dolgot értünk: (1) Amikor egy TPP integrál egy banki API-hoz és első körben regisztrálja / ellenőrzi a bank a TPP eIDAS tanúsítványát, majd (2) később amikor a TPP eIDAS tanúsítványa – jellemzően évente, vagy kétévente – lejár, ekkor a régi tanúsítvány érvényességét veszti, helyette egy új tanúsítvány kerül kibocsátásra, amelyeket banki oldalon is cserélni szükséges.

Az eddigi tapasztalataink szerint a tanúsítványok frissítése ugyanazon, vagy legalábbis hasonló csatornán keresztül, illetve folyamat mentén történik, mint az első tanúsítvány regisztrációja. Az ugyanakkor elmondható, hogy a tanúsítványok kezelése kapcsán a legkülönfélébb gyakorlatokkal lehet találkozni.

A legfejlettebbnek tekinthető folyamat, amikor a tanúsítvány beküldése és annak banki oldali validációja egy automatizált folyamat keretében – egyfajta “TPP onboarding API”-n keresztül – megy végbe. Vannak bankok, ahol a fejlesztői portálon keresztül tudja a szolgáltató a tanúsítványt feltölteni, azonban annak ellenőrzése, jóváhagyása, illetve a banki rendszerben történő beállítása már egy manuális folyamat eredményeképpen valósul meg. A harmadik feles szolgáltatók számára a legalacsonyabb ügyfélélményt biztosító folyamat, amikor a teljes tanúsítvány kezelési folyamat e-mail-en keresztül, levelezés útján történik.

Milyen átfutási idővel érdemes kalkulálni a tanúsítványok megújításakor?

Mudri György: A tanúsítványok megújítása két fő lépésből áll: (1) új tanúsítvány igénylése a bizalmi szolgáltatótól (QTSP), (2) az új tanúsítvány saját és banki rendszerekben történő frissítése.

A tanúsítványok igénylésekor a QTSP által szerződésben vállalt határidő több hét is lehet, amelyet külön díj – egyfajta sürgősségi felár – mellett van lehetőség egy hétre, vagy akár három napra is csökkenteni. Bár az alapszolgáltatás igénybevétele esetén is a bizalmi szolgáltatók jellemzően gyorsabban szoktak reagálni a szerződésben vállalt határidőnél, éppen nemrég, a tanúsítványunk második alkalommal történő megújításakor a három hetet is elérte az új tanúsítvány kibocsátása.

Ha figyelembe vesszük, hogy a részben, vagy egészben manuális folyamatot alkalmazó bankok esetében az új tanúsítvány beállítása akár egy hetet is igénybe vehet, összességében azok lejárata előtt minimum egy hónappal érdemes megkezdeni a folyamatot a tanúsítvány kiállítójával. Mindezt úgy, hogy közben a bizalmi szolgáltató a régi tanúsítványt is életben kell tartsa addig, amíg az új tanúsítványok a banki rendszerekben is mindenhol átállításra kerülnek.

Milyen kihívásokat láttok, illetve tapasztaltatok eddig a tanúsítványok megújítása kapcsán?

Mudri György: Az, hogy egy bank milyen folyamat mentén végzi a tanúsítványok kezelését azért is kiemelten fontos a szolgáltatók számára, mert az új tanúsítvány banki rendszerekben történő frissítése időkritikus folyamatnak tekinthető. A tanúsítványt kiállító bizalmi szolgáltató ugyanis egy új tanúsítvány kiállítása után alapértelmezetten akár 24 óra elteltével érvénytelenítheti a régi tanúsítványt, függetlenül annak tényleges lejáratától, valamint attól, hogy azok beállítása a banki rendszerekben megtörtént-e már.

A 24-órás reagálási képesség azon bankok esetében, ahol automatizált – API alapú – tanúsítvány-kezelési folyamat áll rendelkezésre egy akár teljesíthető lehet, azonban

minden olyan folyamat esetében, ahol részben vagy egészben manuális jóváhagyás, illetve tanúsítvány-beállítás történik, minimális az esélye annak, hogy az új tanúsítvány beállítása befutható a régi tanúsítvány érvényességének elvesztése előtt.

Tanúsítvány kiállítótól függően ugyan, de azért van lehetőség a régi tanúsítvány érvényességének fenntartására az új tanúsítvány kiadása után is meghatározott ideig (ha még nem járt le). Ezt az új tanúsítvány igénylésekor célszerű egyeztetni a bizalmi szolgáltatóval.

Amennyiben az új tanúsítvány beállítása a banki rendszerben nem történik meg a régi tanúsítvány érvényességi idejének megszűnéséig, akár a régi, akár az új tanúsítvánnyal próbál meg API kapcsolatot felépíteni a szolgáltató a bankkal, a kezdeményezés elutasításra kerül “érvénytelen tanúsítvány” címen. Így gyakorlatilag a számlainformációs, illetve fizetés-kezdeményezési szolgáltatás ellehetetlenül egészen addig, amíg az új tanúsítvány beállítása nem történik meg.

A történetet tovább “színesíti”, hogy a tanúsítvány-kezelési folyamatban nem egy, hanem két fajta tanúsítvány is érintett (ú.n. QWAC és QSEAL), amelyek érvényességi ideje az esetek nagyobb részében eltér. Mindez azt vonja maga után, hogy a szolgáltatóknak nem egy, hanem adott esetben két körben szükséges átverekedni magukat a banki folyamatokon. Tovább bonyolítja a helyzetet, hogy van olyan bank, amelyik az azonosítási folyamat során mindkét tanúsítványt kéri és van olyan, ahol csak a QSEAL tanúsítvány használatára van szükség.

Ha figyelembe vesszük, hogy egy szolgáltatónak a tanúsítvány megújításakor nem egy, hanem a bankok garmadája felé kell a tanúsítvány frissítését elvégezni, könnyen belátható mekkora kihívást jelent a különféle banki folyamatokat és azok megvalósulásának eltérő átfutási idejét összehangolni.

Az eltérő folyamatok számontartása, kezelése messze nem elhanyagolható adminisztrációs terhet jelent a szolgáltatók számára.

Az MNB július 1-jén publikált 10/2021. számú, a nyílt bankolást segítő “akadálymentesítő” ajánlása megfogalmazott elvárásokat a tanúsítványok kezelésével kapcsolatban, amely szerint a regisztrációs folyamat akkor nem minősül akadályozásnak, ha az „technikailag feltétlenül szükséges a számlavezető pénzforgalmi szolgáltatóval való biztonságos kommunikációhoz, kellő időben, de legkésőbb a következő munkanap végéig feldolgozásra kerül és nem okoz indokolatlan kellemetlenséget az ügyfél számára.”

Ezt az elvárást azok a bankok tudják nagy biztonsággal teljesíteni, amelyek megszüntetik, de legalább is minimalizálják a manuális beavatkozást a tanúsítvány-kezelési folyamatban.

Összességében hogy látod, a jelenlegi tanúsítvány megújítási folyamat milyen hatással lehet a felhasználók által tapasztalható szolgáltatási élményre?

Mudri György: A képlet egyszerű. Ha az új tanúsítvány beállítása a banki rendszerben nem történik meg a régi tanúsítvány érvényességi idejének megszűnéséig, a régi tanúsítvány lejáratát követően a szolgáltatás nem biztosítható tovább, egészen addig, amíg az új tanúsítvány beállítása nem történik meg a banki rendszerben.

Az adatok lekérése, illetve a fizetés kezdeményezése során ebben az esetben az érintett bank ügyfele hibaüzenettel találkozik. Amennyiben a harmadik feles szolgáltató időben kezdeményezte a tanúsítvány megújítási folyamatot ez azért is különösen kellemetlen, mert

a szolgáltatás-kiesés nem a TPP-nek felróható okból valósul meg, ugyanakkor az ügyfél a szolgáltatót fogja hibáztatni.

Az ügyfélélmény szempontjából további problémát okozhat az a fajta (szerencsére nem minden banknál, hanem csak a bankok egy szűkebb körénél tapasztalható) implementáció banki oldalon, amikor az ügyfél hozzájárulását a bank nem magához a harmadik feles szolgáltatóhoz kapcsolja hozzá, hanem a tanúsítványhoz. Ez ugyanis azt okozhatja, hogy egy új tanúsítvány érvénybe lépésekor a korábban adott ügyfél-hozzájárulás “eltörik”.

Ez a gyakorlatban olyan számlainformációs szolgáltatói felhasználási módokat akadályozhat, ahol a TPP annak ellenére lesz kénytelen a végfelhasználókat újra elküldeni egy tanúsítvány megújítás miatt a banki oldalra megismételni a teljes két-faktoros authentikációs folyamatot, ahol az adott ügyfélhozzájárulás esetében a korábban megadott hozzájárulás 90 napos határideje még nem járt le.

Találkoztunk olyan bankkal, ahol a tanúsítvány megújítási folyamat eredményeként az összes ügyfél-hozzájárulásunkat – a 90 napos határidőtől függetlenül – elvesztettük és valamennyi végfelhasználó esetében szükség volt az új hozzájárulás beszerzésére. Minden ilyen jellegű frusztráció a folyamatban komoly ügyfél lemorzsolódáshoz vezethet.

Címlapfotó: Jonathunder,  Wikipedia. Licence: CC BY-SA 3.0