ISO 20022: november 28-ra módosult a TARGET-frissítés időpontja, miközben a Swift külön halasztott

Mi változott a TARGET Services menetrendjében?

Az EKB 2026. szeptember 4-én közölte: a tervezett novemberi fejlesztési csomag tartalmát megtartja, de bevezetésének időpontját 2026. november 14-ről november 28-ra módosítja. A változás a T2, a T2S, a TIPS és az Eurosystem Collateral Management System (ECMS) szolgáltatást érinti. A döntés hátterében a Swift által bejelentett szabványfrissítési halasztás és az európai piaci szereplőkkel folytatott egyeztetés áll.

A TARGET elnevezés itt nem egyetlen fizetési alkalmazást jelent, hanem több, az eurórendszer által működtetett pénzpiaci infrastruktúrát. A T2 főként nagy értékű fizetési elszámolást, a TIPS azonnali fizetési elszámolást, a T2S értékpapír-ügyletek elszámolását támogatja. Az ECMS a jegybanki hitelműveletekhez kapcsolódó fedezetkezelési rendszer. Ezek külön funkciókat látnak el, ugyanakkor a változások több intézmény technikai kapcsolatait egyszerre érinthetik.

A két hetes eltolás nem jelenti a teljes fejlesztés leállítását. Az EKB az eredetileg tervezett kiadási tartalom folytatását közölte, és azt, hogy a csatlakozó szereplőknek a módosításokhoz alkalmazkodniuk kell. Ezért a bankoknak nem elegendő csupán egy új naptári dátumot beírniuk: saját alkalmazásaik, partnereik és tesztkörnyezeteik változáskezelési tervét is össze kell hangolniuk.

Miért más a Swift szabványfrissítésének története?

A Swift globális pénzügyi üzenetküldési hálózat, amelynek szabványfrissítései többféle üzenetcsaládot és üzleti folyamatot érintenek. Az ISO 20022 pedig nem egy hálózat neve, hanem az elektronikus pénzügyi üzenetek strukturált adattartalmához és modelljéhez kapcsolódó nemzetközi szabványcsalád. A kettőt gyakran egy mondatban emlegetik, de nem felcserélhető fogalmak.

A Swift 2026. augusztus 27-i közleménye szerint a piac több szereplője jelezte: a szabad szöveges postai címek strukturált vagy hibrid formátumra való átállására további felkészülési idő szükséges. A Swift ezért a fizetési üzeneteket érintő SR2026-változtatások elhalasztásáról tájékoztatott. A strukturált címek új bevezetési menetrendjét további szakmai konzultációhoz kötötte, és legkésőbb decemberre ígért aktualizálást.

A Swift a 2026. szeptember 21-i frissítésében közölte, hogy az SR2026-ból elkülönített, többek között értékpapír-, alapkezelési, tracker-, valamint kivétel- és vizsgálati üzeneteket érintő csomag új bevezetési időpontja 2027. június 12. Ez nem azt jelenti, hogy minden korábban tervezett fizetési címadat-szabály automatikusan ugyanazon a napon indul el. A különböző csomagok és üzenettípusok eltérő ütemezést kaphatnak; a projekttervet mindig a legfrissebb, üzenetcsaládra vonatkozó dokumentációra kell építeni.

Mit jelentenek a strukturált és a hibrid címadatok?

A pénzügyi üzenetekben a felek neve és címe többféleképpen szerepelhet. Szabad szöveges cím esetén több mezőben egybefűzött leírásból kell kitalálni, melyik rész város, ország, utca vagy irányítószám. A strukturált cím külön mezőkben tárolja a releváns elemeket. A hibrid forma egyes kötelezően strukturált részeket – jellemzően a település nevét és az országkódot – korlátozott szabad szöveggel egészíthet ki.

A megfelelő címadat a gépi ellenőrzést, a szankciós és pénzmosás-megelőzési szűrést, valamint az automatikus feldolgozást segítheti. A strukturálás ugyanakkor adatminőségi kihívás: egy régi vállalatirányítási rendszerben a cím egyetlen sorban lehet, a külföldi neveket eltérő átírással tárolhatják, vagy hiányozhat a kétbetűs országkód. Az átállás többnyire adatfelmérést és javítást is igényel, nem csupán új XML-sémát.

Miért vezettek be ideiglenes könnyítést a T2-ben?

Az EKB jelezte, hogy a nemzetközi fizetések zavartalan kezelésének támogatására átmenetileg lehetővé teszi a teljesen strukturálatlan postai címek használatát egyes T2 RTGS-üzenetekben. Ez a technikai átmeneti intézkedés az eltérő globális felkészültséget kezeli. Az EKB ugyanakkor arra kéri a T2-résztvevőket, hogy folytassák a strukturált vagy hibrid címek bevezetését, és az átmeneti időszakban maradjanak képesek a strukturálatlan címek fogadására is.

Ez nem általános mentesség minden fizetési csatornán. A különböző hálózatok, üzleti esetek és üzenettípusok eltérő adatkövetelményeket alkalmazhatnak. Egy olyan fintech, amely több bankkal működik együtt, nem következtethet automatikusan egy T2-szabályból arra, hogy minden SEPA-, Swift- vagy banki API-kapcsolatában ugyanaz a kivétel megengedett.

Mit ellenőrizzen most egy bank vagy fejlesztőcsapat?

A legfontosabb első lépés a függőségek feltérképezése. Melyik rendszer kapcsolódik közvetlenül T2-, TIPS-, T2S- vagy ECMS-szolgáltatáshoz, és melyik csak közvetítő bankon vagy fizetési szolgáltatón keresztül? Ezután el kell különíteni a TARGET-követelményeket, a Swift-üzenetszabályokat és a belső banki adatmodelleket. A közös ISO 20022-alap önmagában nem teszi ugyanazzá az egyes szolgáltatások részletes validációját.

Az EKB tájékoztatása szerint az érintett A2A-kapcsolatok felhasználói tesztjeinek tervezett kezdőnapja 2026. október 9. Itt az A2A application-to-application, vagyis rendszerek közötti technikai kommunikációt jelent; nem keverendő a kereskedelmi „account-to-account payment” kifejezéssel, amely bankszámlák közötti fizetésre utal. A tesztekben a pozitív forgatókönyvek mellett ellenőrizni kell az érvénytelen címeket, kötelező mezők hiányát, státuszváltásokat, duplikált üzeneteket és a rendszerek közötti újraküldési logikát is.

A vállalati ügyfeleket kiszolgáló banki API-knál különösen fontos az adatmezők összehangolása. Ha az ügyfélrendszer csak szabad szöveges címet tud küldeni, az interfésznek egyértelműen jeleznie kell, hogy az adott fizetési útvonalon milyen formátum fogadható el. A banknak kerülni kell az olyan csendes, hibás adatátalakítást, amely később egy nemzetközi utalás visszautasításához vezetne.

Magyar piaci jelentőség

Bár Magyarország nem tagja az euróövezetnek, a magyar bankok és vállalkozások rendszeresen kapcsolódnak eurós és nemzetközi pénzforgalmi folyamatokhoz. A külföldi partnerek felé történő utalás, a vállalati XML-fájlból indított fizetés és a banki rendszerek közötti státuszfeldolgozás szempontjából a nemzetközi szabványkövetelményeknek közvetett hazai hatásuk lehet. A tényleges teendő azonban függ attól, melyik intézmény milyen szolgáltatáshoz és üzenetáramláshoz csatlakozik.

Egy magyar vállalkozásnak ezért nem általános „november 28-i átállást” kell hirdetni, hanem a saját bankjától pontos technikai tájékoztatást kérnie a használt fájlformátumról, címmezőkről, elutasítási kódokról és tesztelési lehetőségekről. A finanszírozási és értékesítési folyamatok szempontjából a legnagyobb kockázat a meglepetésszerű fizetés-visszautasítás vagy az elhúzódó manuális javítás lehet.