Revolut és brit bankok akadoztak a Google Cloud október 20-i leállásakor

Mi történt október 20-án?

A Google Cloud londoni, europe-west2 régiójának egyik rendelkezésre állási zónájában 2026. október 20-án áramellátási esemény miatt szolgáltatáskiesés történt. A Google Cloud hivatalos incidensnaplója szerint a zavar 06:08 UTC-kor, vagyis 08:08-kor magyar idő szerint kezdődött. Az érintett zónában több felhőszolgáltatás nem volt elérhető, a tágabb londoni régióban pedig időszakos hálózati hibák és megnövekedett hibaarány jelentkeztek.

A felhőhiba nem egyetlen weboldalt érintett. A Google infrastruktúrájára támaszkodó, egymástól független vállalkozások alkalmazásai is nehézségekbe ütköztek. A Google aznap fokozatos helyreállításról számolt be, majd közölte, hogy a probléma a legtöbb ügyfelénél enyhült; néhány érintettnél a helyreállítás tovább tarthatott. A szolgáltató részletes utólagos technikai elemzést ígért. A közlemények alapján a kiváltó esemény üzemeltetési, áramellátási hiba volt, nem igazolt kibertámadás.

Hogyan érintette a Revolutot és a brit bankokat?

A Nemzeti Kiberbiztonsági Intézet október 21-i összefoglalója és az érintett szolgáltatók beszámolói szerint a Revolutnál mobilalkalmazási és banki funkciók működése akadozott. A brit Lloyds és a HSBC is jelezte, hogy ügyfelei egy része nehezen érte el az online bankolást; a Halifax neve szintén szerepelt a nyilvános hibajelentésekben. Nem állítható azonban, hogy minden felhasználónál valamennyi szolgáltatás egyszerre leállt volna.

A Revolut a sajtónak adott nyilatkozatában elnézést kért az érintettektől, és azt közölte, hogy az ügyfelek pénze és adatai biztonságban maradtak. A szolgáltatás elérhetőségi zavara nem azonos pénzvesztéssel vagy adatlopással. Az alkalmazásban jelentkező hiba ugyanakkor nagyon is valós gondot okozhat: valaki nem tudja ellenőrizni az egyenlegét, jóváhagyni egy műveletet vagy megbizonyosodni egy utalás állapotáról.

Miért állhat le több banki alkalmazás ugyanattól a felhőhibától?

A modern digitális bankolás nem egyetlen szerveren fut. A felhasználói felület mögött bejelentkeztetési rendszerek, adatbázisok, értesítési és feldolgozó szolgáltatások, API-k és külső technológiai beszállítók együttműködése áll. Ha ezek valamelyike egy érintett felhőrégióban működik, egy infrastruktúrahiba több, látszólag egymástól független banki funkciót is elérhet.

A londoni incidens különösen jól mutatja a koncentrációs kockázatot: számos pénzügyi szereplő szolgáltatása ugyanarra a néhány nagy technológiai infrastruktúrára támaszkodik. Ez nem jelenti, hogy a felhő használata önmagában hibás döntés. A kritikus kérdés az, milyen gyorsan és milyen korlátok mellett képes a pénzügyi szolgáltató egy kiesett összetevő helyett másik működési útvonalat használni.

Mit tehet az ügyfél, ha a mobilbankja éppen nem működik?

A legfontosabb, hogy ne tekintsünk minden sikertelen képernyőn megjelenő választ meghiúsult pénzügyi tranzakciónak. Előfordulhat, hogy a művelet a háttérben elindult, csak a visszaigazolás nem érkezett meg. Érdemes megvárni a szolgáltató hivatalos állapotjelentését, és ha lehet, később az alkalmazás tranzakciótörténetében ellenőrizni, hogy a megbízás teljesült-e.

Ugyanazt az átutalást nem tanácsos ellenőrzés nélkül többször megismételni, mert ez kettős teljesítéshez vezethet. Ha egy befizetés vagy fizetés sürgős, csak a bank által hivatalosan kínált alternatív csatornát szabad használni. Közösségi médiában vagy üzenetben érkező „helyreállítási” linkkel ne adjunk ki banki belépési adatot; egy valódi üzemzavar idején is megjelenhetnek adathalász próbálkozások.

Az eseményből nem következik, hogy minden kártyás fizetés megbízhatatlan lenne. A kártyás vásárlás, a banki átutalás és az alkalmazáson belüli szolgáltatás eltérő háttérrendszerekhez kapcsolódhat, ezért kiesésük terjedelme sem feltétlenül azonos.

Miért különösen fontos ez a webáruházaknak és vállalkozásoknak?

Egy webáruház számára nemcsak az számít, hogy a fizetési szolgáltató általában milyen rendelkezésre állást ígér. Az is lényeges, mi történik akkor, ha a vásárló a fizetési folyamat végén hibát kap, miközben a fizetés állapota még nem egyértelmű. Ilyenkor a kereskedői rendszernek kezelnie kell az ismételt értesítéseket, a későn érkező visszaigazolást és a megismételt gombnyomásokat.

Az online fizetési integrációknál az idempotencia azt jelenti, hogy egy művelet ismételt technikai beküldése ne hozzon létre véletlenül több fizetést vagy megrendelést. A kereskedőnek érdemes rögzítenie, hogyan egyezteti a rendeléseket a fizetési szolgáltató adataival egy átmeneti kiesés után. A nagyobb cégeknél ugyanilyen fontos a banki API-k, a treasury- és ERP-kapcsolatok kiesés esetére kidolgozott folyamata.

Kapcsolódó korábbi anyagunk: Mitől jó egy banki API? – elérhetőség, válaszidő és hibakezelés.

Mit mond a szabályozás? A brit felügyelet és az uniós DORA nem ugyanaz

Az Egyesült Királyságban 2026. július 13-tól a brit jegybank, a PRA és az FCA közösen felügyeli az első kijelölt kritikus harmadik fél szolgáltatókat (Critical Third Parties). A Bank of England hivatalos bejelentése szerint a körbe a Google Cloud EMEA Limited, az AWS, a Microsoft és az Oracle kijelölt társaságai is bekerültek. A szabályozás célja, hogy egy technológiai szolgáltató zavara ne terjedjen ellenőrizetlenül a teljes pénzügyi szektorra. A kijelölés nem helyettesíti a bankok saját kockázatkezelési kötelezettségeit.

Az Európai Unióban a DORA-rendelet 2025. január 17. óta alkalmazandó. Az európai felügyeleti összefoglaló alapján a szabályrendszer az informatikai kockázatok kezelésére, az incidensek bejelentésére, az ellenálló képesség tesztelésére és a külső informatikai szolgáltatók kockázatainak felügyeletére épül. A DORA nem ígéri, hogy egyetlen banki szolgáltatás sem állhat le; azt követeli meg, hogy a pénzügyi szervezetek felkészüljenek a zavarokra, és megfelelően kezeljék a következményeket.

A két felügyeleti keret külön joghatóságban működik. A brit intézkedésekből nem lehet automatikusan a magyar bankokra vonatkozó új kötelezettséget levezetni. A magyar piacon az uniós előírások és a hazai felügyeleti elvárások adják az irányadó keretet. További háttér: DORA 2026 – fintech kiberbiztonsági és IKT-követelmények.

Mit érdemes most ellenőrizni a pénzügyi szolgáltatóknak?

Egy ilyen incidens után hasznos áttekinteni, hogy a kritikus banki folyamatok pontosan mely felhőszolgáltatásokra, régiókra és alvállalkozókra épülnek. A többrégiós vagy többzónás működés önmagában nem garancia: az adatbázisok, belépési szolgáltatások vagy harmadik fél API-jai továbbra is lehetnek közös hibapontok.

A megfelelő válasz ezért nem egyszerűen annyi, hogy „legyen még egy felhő”. A mérhető helyreállítási célokhoz rendszeresen tesztelt forgatókönyvekre, kommunikációs tervre, az ügyfelek számára érthető státusztájékoztatásra és a tranzakciók utólagos egyeztetésére is szükség van. A tartalékmegoldás csak akkor segít, ha a valós kiesési helyzetben is működik, és az átállás nem okoz új adat- vagy elszámolási hibát.

Mi bizonyított, és mi vár még tisztázásra?

A Google hivatalos közleményében dokumentált londoni áramellátási hiba és a Revolutnál, illetve több brit banknál jelentett hozzáférési zavar ellenőrizhető tény. Nem áll rendelkezésre olyan hiteles bizonyíték, amely szerint ezt az eseményt kibertámadás okozta volna, vagy emiatt banki ügyfélpénzek tűntek volna el. A Google részletes műszaki incidensjelentésének közzétételéig a teljes ok-okozati lánc, valamint minden érintett alkalmazás helyreállításának időzítése nem rekonstruálható egyformán pontosan.

A digitális pénzügyek szempontjából a történet lényege nem önmagában egy néhány órás zavar, hanem az, hogy a kritikus infrastruktúra és a banki ügyfélélmény mennyire szorosan összekapcsolódott. A jövőben a gyors és hiteles ügyféltájékoztatás éppúgy a szolgáltatásminőség része, mint a stabil technológiai működés.