Microsoft 365-kimaradás: így gyűrűzhet tovább az Exchange hibája a pénzügyi működésben

Nem érkezik meg egy ügyfélszolgálati levél, nem frissül egy megosztott naptár, vagy hibát ad egy e-mailre épülő üzleti alkalmazás. A hiba látszólag különböző helyeken jelentkezik, mégis ugyanahhoz a felhőszolgáltatáshoz vezet vissza. Ezt a működési függőséget tette láthatóvá a 2026. november 12–13-i Microsoft 365-szolgáltatáskimaradás.

A Microsoft először az Exchange Online postafiókok elérési problémáit közölte az EX1550543 incidensazonosító alatt, majd a több kapcsolódó Microsoft 365-funkciót érintő problémákat MO1550821-ként követte. A hivatalos szolgáltatásállapot-oldalon és a vállalati adminisztrációs központban időközben több műszaki helyreállítási frissítést tettek közzé.

A történet Open Banking-szempontból nem arról szól, hogy bizonyítottan leállt volna valamelyik bank alapvető fizetési rendszere. A kérdés az, hogy egy pénzügyi szolgáltatás mennyire képes működni, amikor a kommunikációs és integrációs háttér egyik gyakran használt eleme hibázik.

Mi történt a Microsoft 365-tel?

A Microsoft adminisztrátori incidensnaplóiban az Exchange Online probléma kezdete november 12-én 16:17 UTC, magyar idő szerint 17:17. A több szolgáltatásra kiterjedő MO1550821 incidens kezdete 18:26 UTC, azaz 19:26 magyar idő szerint. Az első jelentések amerikai postafiók-elérési hibákról szóltak, majd a Microsoft jelezte, hogy más régiókban is előfordulhatnak csatlakozási gondok.

Az érintett Exchange Online-kapcsolódási módok közé az Outlook webes felülete, a MAPI-n keresztül működő asztali Outlook, az Exchange ActiveSync és egyes REST API-kapcsolatok tartoztak. Később az e-mail-kézbesítés késését is az érintett hatások közé sorolták. A Microsoft az incidensről azért tájékoztatott a nyilvános állapotoldalon is, mert egyes rendszergazdák még az adminisztrációs felületet sem érték el megfelelően.

Miért húzódhatott el a helyreállítás?

A Microsoft műszaki helyzetjelentése szerint nem egyszerűen a felhasználói kérések száma nőtt meg. Szerverek váltak váratlanul elérhetetlenné, így a megmaradó infrastruktúrára hárult több forgalom. Az érintett kiszolgálók egy részén az automatikus állapotellenőrzés, illetve a kapcsolatok feldolgozásáért felelős folyamatok túlterhelődtek; egyes szerverek az újraindítás után, forgalom alatt ismét válaszképtelenné válhattak.

A Microsoft több párhuzamos lépést vizsgált: a forgalom átterelését, a szerverek újraindítását és fokozatos visszaengedését, korlátozott forgalmi módokat, valamint korábbi konfigurációval újraépített szervereket. A későbbi közlemények a hálózati konfigurációk visszaállítását és a kapacitás bővítését is említették. Ezek az incidenskezelés során közölt technikai megállapítások, nem végleges gyökérok-elemzés.

A november 13-i reggeli állapotjelentések még szolgáltatásromlást mutattak egyes környezetekben. A helyreállítás régiónként és funkciónként eltérhet; a pillanatnyi, konkrét felhasználói állapotot a Microsoft folyamatosan frissülő állapotoldalán és a saját bérlő adminisztrációs felületén kell ellenőrizni.

Miért érintett a Teams, a SharePoint vagy a Copilot is?

A Microsoft 365 nem egymástól teljesen független alkalmazások gyűjteménye. Több szolgáltatás adatokat kér le az Exchange Online-ból, vagy olyan közös háttérkomponensekre támaszkodik, amelyek egy levelezési incidensben is érintettek lehetnek. A Microsoft MO1550821 közleménye szerint ezért az Exchange-hez kapcsolódó műveletek más termékekben is hibázhattak.

• Outlook és Exchange Online: postafióknyitás, e-mail-hozzáférés, egyes API-műveletek és az üzenetek kézbesítése akadozhatott.
• Microsoft Teams: az Exchange-et használó naptár- és megbeszélésszervezési funkciók is hibázhattak. Ez nem jelenti azt, hogy minden Teams-beszélgetés vagy videóhívás leállt.
• Microsoft Graph: az Exchange-adatokat, például leveleket, naptárakat vagy névjegyeket elérő API-hívások időtúllépésbe futhattak. Más Graph-erőforrásokról ebből önmagában nem következik általános leállás.
• Microsoft 365 Copilot: a munkakörnyezet e-mailjeire és naptáradataira támaszkodó funkciók adatlekérései, illetve egyes felületei érintettek lehettek.
• SharePoint Online és más szolgáltatások: egyes kapcsolódó funkciók akadozhattak, de a Microsoft külön jelezte, hogy a közvetlenül SharePointban tárolt fájlokhoz való hozzáférés továbbra is működött.

Ez a különbségtétel lényeges: a szolgáltatásromlás nem azonos minden Microsoft 365-termék teljes leállásával. A tényleges üzleti hatás a használt funkcióktól és integrációktól függ.

Miért fontos ez a bankoknak és a fintechcégeknek?

Egy modern pénzügyi szolgáltatás körül sok olyan háttérfolyamat működik, amely nem maga az átutalást teljesítő banki rendszer, mégis jelentősen befolyásolja az ügyfélélményt. Például egy fintechcég e-mailben kommunikál az ügyfelekkel, közös naptárban egyeztet partnereivel, vagy a Microsoft Graphon keresztül dolgozza fel a levelezésből érkező feladatokat.

Ha ezek közül valamelyik elem nem elérhető, az ügyfél nem feltétlenül tudja, hogy a háttérben csak egy kommunikációs függőség esett ki. Az elmaradt visszaigazolás, a késő ügyfélszolgálati válasz vagy egy meghiúsult időpontegyeztetés a teljes szolgáltatás megbízhatóságába vetett bizalmat befolyásolhatja.

Amikor az e-mail egy integráció része

Az üzleti rendszerek egy része beérkező üzenetekből indít jegykezelési, számlaellenőrzési, ügyfélszolgálati vagy belső jóváhagyási folyamatokat. Ha az Exchange-hez kötött API-hívás nem válaszol, egy alkalmazás késve értesülhet az új levelekről. Ilyenkor különösen fontos, hogy az automatizmus ne veszítsen el eseményeket, és a későbbi újrapróbálkozás ne hozzon létre duplikált műveletet.

Az incidens alatt nyilvános üzemeltetői státuszközlemények konkrétan e-mailből létrehozott ügyfélszolgálati jegyek késését is jelezték. Ez jól mutatja a láncreakciót, de nem bizonyít banki átutalási vagy számlavezetési hibát.

Két különféle függőséget kell szétválasztani

A fizetési API-k, a számlaadat-hozzáférések és a core banking rendszerek rendelkezésre állása nem automatikusan azonos a Microsoft 365 rendelkezésre állásával. Ugyanakkor egy pénzügyi szervezet támogatási, kommunikációs, megfelelőségi vagy fejlesztői munkafolyamatai ettől még lehetnek Microsoft-felhőszolgáltatásokra építve. Az üzleti kockázat felmérésekor ezért nem elég a fizetési végpontokat figyelni: a mögöttük álló, kritikus függőségeket is ismerni kell.

Öt gyakorlati ellenőrzés pénzügyi szolgáltatóknak és fejlesztőknek

1. Függőségtérkép készítése. Mely ügyfélkapcsolati, pénzügyi, adminisztratív és automatizált folyamatok támaszkodnak Exchange-re, Teams-naptárra, SharePointra vagy Microsoft Graph mail/calendar végpontokra? Különítsd el a kritikus és a kényelmi funkciókat.
2. Másodlagos kommunikációs út. Ha nem működik az e-mail, legyen ellenőrzött ügyfél- és partnerértesítési mód: státuszoldal, ügyfélportál, hitelesített telefonos csatorna vagy megfelelő alternatív értesítés.
3. Biztonságos újrapróbálkozás. API-időtúllépésnél a háttérfeladatok kerüljenek nyomon követhető sorba; legyen korlátozott újrapróbálkozás, deduplikáció, idempotens feldolgozás és emberileg áttekinthető hibastátusz. Egy pénzügyi műveletet nem szabad pusztán a válasz hiánya miatt ellenőrizetlenül megismételni.
4. Független megfigyelés. A Microsoft Service health állapota mellett a saját kritikus végpontok hibaarányát, feldolgozási késését és a valós ügyfélfolyamatokat is mérni kell. A beszállítói állapotoldal önmagában nem helyettesíti a belső megfigyelést.
5. Üzletmenet-folytonossági próba. Teszteld, mi történik többórás e-mail- vagy Graph-kimaradásnál, hogyan kapcsolható be az alternatív folyamat, és hogyan dolgozza fel a rendszer a helyreállás utáni elmaradt eseményeket.

A hibakeresés első lépése mindig a Microsoft szolgáltatásállapotának és a saját naplóknak a korrelálása. Nem célszerű minden felhasználónál helyi Outlook-újratelepítéssel kezdeni, ha központi szolgáltatáskimaradásról van szó.

Mit jelent mindez a DORA szempontjából?

Az uniós DORA-rendelet a pénzügyi szervezetek digitális működési ellenálló képességét, a kritikus IKT-függőségek azonosítását, az üzletmenet-folytonosságot és a külső technológiai szolgáltatók kockázatainak kezelését is szabályozza. Az Európai Bankhatóság külön hangsúlyozza a kritikus harmadik fél IKT-szolgáltatók felügyeletét és a koncentrációs kockázatokat.

Fontos, hogy egy Microsoft 365-üzemzavar nem automatikusan DORA szerint jelentendő súlyos IKT-incidens minden pénzügyi szervezetnél. A besorolás a konkrét érintettségtől, a kiesés időtartamától, az érintett szolgáltatástól és a vonatkozó feltételektől függ. A szervezeteknek ezért a saját hatásukat kell dokumentálniuk, és ennek megfelelően alkalmazniuk az incidenskezelési és bejelentési szabályokat.

A tanulság nem az, hogy egy felhőszolgáltatást minden körülmények között két másikra kell cserélni. Az a fontos, hogy a kritikus funkciók függőségei ismertek legyenek, az alternatív eljárások működjenek, és a kiesésre adott reakciót előre kipróbálják.

Nem először látszik a felhőfüggőség üzleti ára

Az OpenBanking.hu korábban a 2026. októberi Google Cloud-leállás banki és fintechhatásairól is beszámolt. A mostani Microsoft 365-eset más rendszereket érintett: elsősorban a kommunikáció és a közös vállalati alkalmazások működését, nem valamely bizonyítottan leállt banki fizetési infrastruktúrát.

A két esemény közös szakmai üzenete azonban ugyanaz: a digitális pénzügyi szolgáltatások rendelkezésre állását nem egyetlen alkalmazás vagy API működése határozza meg. A teljes szolgáltatási láncba a külső kommunikáció, a személyzet munkakörnyezete, a háttér-API-k és a beszállítók működése is beletartozik.

Szerkesztőségi megjegyzés: a cikk a 2026. november 13-án elérhető incidensjelentésekre épül. Az esemény lezárása, a műszaki gyökérok és a régiónkénti helyreállási állapot későbbi közleményekben módosulhat.