A DÁP eAláírás bevezetésénél az egyik fő kihívás, hogy a pénzügyi szolgáltató már a tervezéskor úgy építse fel a folyamatot, hogy az később bizonyítható, dokumentálható és auditálható legyen. Szintén az elején érdemes átgondolni, hogy egyedül vagy IT beszállítóval vágjon bele a szolgáltató. Ezek voltak a FinTechZone és a Comnica legutóbbi DÁP-webinárjának egyik legfontosabb üzenetei.
A DÁP-csatlakozás kapcsán sok pénzügyi szolgáltató ma már nem nulláról indul. Az eAzonosítás, az informatikai zártsági elvárások és a kiberbiztonsági megfelelés több szervezetnél ismert terep.
A DÁP eAláírás azonban új szintet jelent:
itt már nem pusztán az ügyfél hiteles azonosításáról van szó, hanem arról, hogy az ügyfél a szolgáltató saját ügyintézési vagy szerződéskötési folyamatában, abból kilépés nélkül, a DÁP mobilalkalmazás jóváhagyásával hozzon létre minősített elektronikus aláírást.
A FinTechZone és a Comnica webinárjának panelbeszélgetésében Kayser Péter, a DÁP-hoz kapcsolódó audit- és tanúsítási folyamatok szakértője, valamint Jeney Gábor, a Comnica ügyvezető igazgatója mutatta be a DÁP eAzonosítás és a beágyazott DÁP eAláírás megfelelési kérdéseit.
A beszélgetés azt járta körbe, milyen auditokra, tanúsításokra és belső felkészülési lépésekre kell számítaniuk a pénzügyi szolgáltatóknak, milyen bevezetési forgatókönyvek látszanak, és hogyan érdemes tervezni az idővel, az erőforrásokkal és a felelősségi körökkel.
Nem ugyanaz az eAzonosítás és az eAláírás auditlogikája
A DÁP eAláírás viszont más logikát követ. Itt az eIDAS-alapú, ETSI-szabványokra épülő megfelelési kör is megjelenik.
A csatlakozási szabályzat alapján az érintett elektronikus információs rendszernek jelentős biztonsági osztályban legalább 95 pontos megfelelési eredményt kell elérnie. Emellett az aláírási lánc azon részeit is vizsgálni kell, amelyekben a partner rendszere, a „konnektor”-alkalmazás és a DÁP-rendszerek együttműködnek.
A pénzügyi szolgáltatók szempontjából a lényeg:
a zártsági audit vagy a kiberbiztonsági audit önmagában nem váltja ki az eIDAS/ETSI szerinti láncmegfelelés vizsgálatát. A két világ egymás mellett jelenik meg, de nem ugyanarra ad választ.
Három bevezetési út: saját fejlesztés, beszállítói fejlesztés, kész szolgáltatás
A megfelelési logika tisztázása után a következő kérdés már gyakorlati: milyen bevezetési modellben érdemes gondolkodnia egy pénzügyi szolgáltatónak? Jeney Gábor a bevezetési lehetőségeket három fő forgatókönyvre bontotta.
Az első, amikor a pénzügyi szolgáltató saját maga fejleszti le a DÁP eAláíráshoz szükséges rendszerelemeket, ügyfélfolyamatot és kapcsolódásokat. Ebben az esetben a szervezetnek nemcsak meg kell terveznie és le kell fejlesztenie a megoldást, hanem auditáltatnia, üzemeltetnie és folyamatosan karbantartania is kell.
A második lehetőség, amikor egy informatikai beszállító fejleszt le egy, a pénzügyi szolgáltató igényeire szabott megoldást. Ez csökkentheti a belső fejlesztési terhet, de a tanúsítási és üzemeltetési felelősség jelentős része továbbra is a pénzügyi szolgáltató oldalán maradhat.
A harmadik út a kész szolgáltatói megoldás. A Comnica példája ebbe a kategóriába tartozik: a szolgáltató olyan kapcsolóelemet – konnektort – biztosít, amely összekapcsolja a pénzügyi intézmény rendszereit a DÁP szolgáltatásokkal, elvégzi a szükséges aláírás előkészítő műveleteket, és a saját oldalán gondoskodik a kapcsolódó megfelelési (audit) követelmények teljesítéséről.
Jeney Gábor szerint ennek az a jelentősége, hogy egy pénzügyi szolgáltatónak nem feltétlenül kell minden elemet nulláról felépítenie.
Ugyanakkor Kayser Péter óvatosan árnyalta a képet:
egy előre elkészített, dokumentált, tesztelt és auditálásra felkészített elem sokat gyorsíthat, de önmagában nem szünteti meg az auditkötelezettséget. A saját folyamatba beépített teljes láncot továbbra is végig kell nézni.
A kulcskérdés: hol lesz az aláírási lánc kritikus pontja?
itt az SCA az aláírás-létrehozó alkalmazást (Signature Creation Application) jelöli. Ez az a szerepkör, amely az ügyfélfolyamatból érkező aláírási igényt a DÁP felé továbbítható aláírás-létrehozási kéréssé alakítja.
Ez a szerep azért lényeges, mert az ügyfél nem lép ki a pénzügyi szolgáltató folyamatából.
A banki vagy biztosítói rendszer indítja az aláírást, a jóváhagyás a DÁP alkalmazásban történik, a kapcsoló (konnektor) alkalmazás pedig kezeli az aláírási tranzakciót: például előállítja a dokumentum lenyomatát, kezeli az aláírási kérést és az aláírt dokumentum visszaadását.
Kayser Péter szerint az auditnak ezért azt kell igazolnia, hogy ez a láncrész hitelesen, változtatás nélkül, naplózhatóan és biztonságosan működik.
Azaz bizonyítható, hogy valóban az a dokumentum, azzal a tartalommal, azzal az ügyleti szándékkal és ügyféljóváhagyással került aláírásra, amelyet a pénzügyi szolgáltató folyamata indokolt.
Nem lesz bizalmi szolgáltató, de a saját láncrészt bizonyítani kell
A beszélgetés fontos megnyugtató üzenete volt, hogy a DÁP eAláírás integrálásával a csatlakozó pénzügyi szolgáltató nem válik bizalmi szolgáltatóvá.
Ez azonban nem jelenti azt, hogy a saját oldali felelőssége eltűnik. A teljes bizalmi szolgáltatási lánc több elemre bontható, és a kritikus kérdés az, hogy a pénzügyi szolgáltató folyamata hol és hogyan kapcsolódik ehhez a lánchoz.
A partneri oldalon nem a teljes szakrendszert kell ETSI szerint auditálni, hanem azt a vékony, de kulcsfontosságú metszetet, ahol az üzleti folyamatból aláírási tranzakció lesz, majd az aláírt eredmény visszakerül a partner rendszerébe.
Ezt a gyakorlatban olyan kérdésekkel kell bizonyítani, mint: honnan érkezik az aláírandó dokumentum, mikor válik véglegessé, ki indíthat aláírást, hogyan kapcsolódik az ügyleti cél az aláírási kéréshez, hova kerül vissza az aláírt dokumentum, és milyen naplózás alapján követhető vissza az esemény.
Az auditálhatóságot nem az utolsó héten kell kitalálni
A beszélgetés egyik legerősebb gyakorlati tanulsága az volt, hogy az auditálhatóság nem a projekt végén kezdődik.
Kayser Péter szerint nem az audit előtti héten kell elkezdeni a megfelelés dokumentálását. A bizonyíthatóságot, a naplózhatóságot, a felelősségi határokat és a vizsgálati kör pontos meghúzását már az architektúra és a fejlesztési folyamat tervezésekor figyelembe kell venni.
Az auditor alapvetően nem felkészítő szereplő: a kész terméket, illetve a kész láncot vizsgálja. Ezért a pénzügyi szolgáltatónak már a felkészülés során tudatosan kell kezelnie, mi tartozik a vizsgálati körbe, mely rendszerelemek érintettek, hol vannak a határpontok, és milyen bizonyítékokkal igazolható a működés.
Jeney Gábor ehhez kapcsolódva azt emelte ki, hogy a szolgáltatót vagy fejlesztőpartnert érdemes minél korábban bevonni.
A legrosszabb forgatókönyv, amikor az audit már elindult, és a beszállító „tegnapra” kap egy hosszú kérdéssort.
A külső partnerre nem utólagos adatszolgáltatóként, hanem a projektcsapat tagjaként érdemes tekinteni.
Mit tisztázzon egy pénzügyi szolgáltató holnap reggel?
- Mely ügyfélfolyamatban akarjuk elsőként bevezetni a DÁP eAláírást, és pontosan milyen dokumentumot kell aláírni?
- Hol keletkezik az aláírandó dokumentum, mikor válik véglegessé, és hogyan bizonyítjuk, hogy aláírás előtt nem módosult?
- Ki vagy mi látja el az aláírás-létrehozó szerepet: saját rendszer, beszállítói fejlesztés vagy kész szolgáltatói megoldás?
- Mely rendszerelemek kerülnek be a vizsgálati körbe, és hol húzódik a határ a zártsági/kiberbiztonsági megfelelés és az ETSI-alapú vizsgálat között?
- Van-e házon belül elegendő szakértelem, projektvezetési kapacitás, informatikai és jogi erőforrás az önálló bevezetéshez, vagy célszerű külső megoldásra építeni?
- Mikor vonjuk be a fejlesztőpartnert, az üzemeltetést, az informatikai biztonságot, a jogi és megfelelési területet, valamint az üzleti folyamatgazdát?
- Képesek vagyunk-e végig bizonyítani az aláírási láncot: az ügyleti szándéktól a dokumentum lenyomatán és a DÁP-jóváhagyáson át az aláírt dokumentum visszaérkezéséig?
A DÁP eAláírás auditjának valódi tétje, hogy a pénzügyi szolgáltató, a technológiai partner és az auditor ugyanazt az aláírási láncot lássa maga előtt, nem pedig az, hogy „meglegyen a papír”.
Ha ez már a tervezéskor világos, az audit nem akadály, hanem a biztonságos és védhető bevezetés természetes része lehet.
A prezentációban is szereplő szakmai megjegyzés szerint a fenti értelmezés nem minősül jogi tanácsadásnak. A végső vizsgálati kört minden esetben a konkrét csatlakozási felépítés, a választott bevezetési modell és az érintett rendszerek alapján kell rögzíteni.
TechShow X. – Ahol a pénzügyi technológia és az üzlet találkozik
2016 óta a TechShow-család Magyarország pénzügyi szektorának meghatározó találkozópontja. Idén először a FinTechShow, PayTechShow és BankTechShow egy jubileumi eseményen egyesül.
- TechShow X. — 2026. október 14-15.
- Várkert Bazár, Budapest
- Program és regisztráció a FinTechZone oldalán →
