Mitől jó egy banki API? Elérhetőség, válaszidő és hibakezelés az Open Bankingben

Miért nem elég, hogy „működik az endpoint”?

Tegyük fel, hogy egy pénzügyi alkalmazás több bank számlaadatát összesíti. A felhasználó reggel szeretné látni, mennyi pénze van összesen, és melyik számlán van esedékes kifizetés. Az egyik bankból a tranzakciós lista két másodperc alatt megérkezik, a másiknál tíz másodpercig tölt a képernyő, a harmadik pedig új hitelesítést kér. Műszakilag mindhárom banknak lehet működő API-ja, az ügyfél mégis megbízhatatlannak érezheti a teljes szolgáltatást.

Az Open Bankingben ezért a szolgáltatásminőség legalább négy dimenziót jelent: technikai elérhetőséget, időbeni válaszkészséget, üzletileg helyes adatokat és sikeresen végigvihető felhasználói folyamatot. Egy jó API nem pusztán HTTP-választ ad, hanem kiszámítható módon támogatja az engedélyezett üzleti műveletet.

A problémák különösen összetettek fizetésindításnál. A sikeres kérés elfogadása nem feltétlenül azonos a fizetés teljesülésével. Ha a szolgáltató ezt a két állapotot összemossa, a kereskedő akár kétszer teljesíthet egy rendelést, vagy tévesen mutathat „sikertelen” üzenetet egy már úton lévő fizetésre.

Mit ír elő a szabályozás?

A PSD2-höz kapcsolódó 2018/389/EU felhatalmazáson alapuló rendelet a biztonságos kommunikáció és az erős ügyfélhitelesítés műszaki követelményeit rendezi. A 32. cikk szerint a dedikált interfésznek legalább olyan rendelkezésre állási és teljesítményszintet kell biztosítania, mint amilyet a bank a saját online ügyfélfelületén nyújt. A számlavezető intézménynek átlátható kulcsteljesítmény-mutatókat és szolgáltatási célértékeket kell meghatároznia; ezek hatósági ellenőrzés tárgyát is képezhetik.

A szabály lényege a hozzáférési versenysemlegesség. Ha egy bank saját mobilalkalmazása zavartalanul működik, miközben a jogosult harmadik fél szolgáltató egy indokolatlanul gyengébb kapcsolattal szembesül, az felügyeleti kérdést vethet fel. Nem minden API-hiba jogsértés, és a műszaki hiba okát mindig tényszerűen meg kell vizsgálni.

Az EBA 2020-as és 2021-es állásfoglalásai több akadályozó gyakorlatot azonosítottak: a szükségtelen többszörös hitelesítést, egyes kiegészítő regisztrációs lépéseket és bizonyos kötelező manuális adatmegadásokat. A 2026 júniusában közzétett EBA-válasz külön megerősítette, hogy a dedikált interfészhez kapcsolódó támogatásra vonatkozó elvárás a harmadik fél szolgáltatók technikai támogatását érinti, nem automatikusan a lakossági ügyfélszolgálat minden funkcióját.

Mely mérőszámok adják a valós képet?

Rendelkezésre állás és hibaosztályok

A nyers uptime fontos, de kevés. Külön kell mérni az infrastruktúra hibáit, az alkalmazásoldali 5xx válaszokat, az ügyféloldali 4xx hibákat és az üzleti okból visszautasított kéréseket. Egy érvénytelen hozzájárulás miatt jogosan visszautasított hívás nem ugyanaz, mint a banki szerver kiesése.

A monitorozásnál lényeges a mérési módszer: mely endpointok szerepelnek benne, mennyi ideig kell tartania egy hibának, és beszámítják-e a tervezett karbantartást? Két különböző módszerrel számolt százalék nem feltétlenül összehasonlítható.

Válaszidő és teljesítményeloszlás

Az átlagos válaszidő elrejtheti a legrosszabb felhasználói élményeket. Érdemes a medián mellett a 95. és 99. percentilist is figyelni. Ha a kérések többsége gyors, de minden huszadik ügyfél több másodpercet vár, a probléma üzletileg érezhető lehet. Az adatlekérés és a fizetésindítás végigvitelének idejét külön mérjük, mert eltérő folyamatokról van szó.

Ügyfélút sikeressége

Mérhető, hány ügyfél jut el a bankválasztástól a hitelesítés végéig, hányan szakadnak meg a visszairányításnál, és hányan kapnak értelmezhető státuszt. A kiesés mögött lehet rossz mobilos átirányítás, hibás munkamenet, elégtelen tájékoztatás, vagy valós banki technikai probléma is. A puszta konverziós szám önmagában nem dönti el az okot.

Adatminőség és frissesség

Számlainformációs szolgáltatásnál számít, hogy az egyenlegek, könyvelt és függő tranzakciók, devizanemek, időbélyegek és közlemények következetesen érkeznek-e. A fejlesztőnek tisztáznia kell, hogy az API milyen időbeli frissességet és milyen tranzakciókört biztosít. Egy üres válasz nem feltétlenül azt jelenti, hogy nem történt mozgás.

Hogyan kezeljük a tipikus hibákat?

Hálózati időtúllépés: a kliens nem tudja, hogy a kérés eljutott-e a szerverig. Fizetésindításnál vakon újrapróbálkozni veszélyes lehet. Előbb ellenőrizni kell a meglévő tranzakció azonosítóját és állapotát, majd a dokumentált idempotencia- vagy ismétlési szabályok szerint eljárni.

Lejárt hozzájárulás: a szabályozott számlaadat-hozzáférés nem korlátlan ideig él. A felület mondja el a felhasználónak, hogy új engedélyezésre van szükség, és ne állítsa úgy be a helyzetet, mintha a bankja hibásan működne.

Hibás vagy hiányzó válaszadat: legyen sémaellenőrzés, korrelációs azonosító, naplózás és megbízható hibajelzés. Érzékeny számlaadatokat a naplózás során nem célszerű indokolatlanul tárolni.

Függő fizetési állapot: a kereskedő ne állítsa késznek a rendelést kizárólag egy kezdeményezési kérés elküldése alapján. A tényleges pénzmozgást megfelelő banki státusszal vagy egyeztetéssel kell alátámasztani.

Gyakorlati ellenőrzőlista integrátoroknak

A szerződéskötés előtt kérdezzük meg, van-e éles és tesztkörnyezet, friss API-dokumentáció, verzióváltási rend, karbantartási értesítés és technikai incidenscsatorna. Érdemes tisztázni a sebességkorlátokat, a tokenkezelést, a hibakódokat, az átirányítási és visszatérési URL-ek működését, valamint a szabványos és bankspecifikus eltéréseket.

Éles működés közben legyen végpontokra bontott szolgáltatásfigyelés, auditálható incidensnapló, visszajelzés a pénzügyi és ügyfélszolgálati csapatnak, valamint a részleges kiesésekre tervezett ügyfélkommunikáció. A kritikus kérdés: mit lát a felhasználó, ha egy bank átmenetileg nem elérhető, és hogyan lehet biztonságosan folytatni a folyamatot?