NAPKÖZBENI TÖBBSZÖRI ELSZÁMOLÁS PROJEKT - GYAKRAN ISMÉTELT KÉRDÉSEK

Átírás

1 NAPKÖZBENI TÖBBSZÖRI ELSZÁMOLÁS PROJEKT - GYAKRAN ISMÉTELT KÉRDÉSEK InterGIRO2 GYIK / FAQ v Budapest, Vadász utca 31. Telefon: (1) , (1) Fax: (1) ISO9001:2008

2 NAPKÖZBENI TÖBBSZÖRI ELSZÁMOLÁS PROJEKT - GYAKRAN ISMÉTELT KÉRDÉSEK InterGIRO2 GYIK / FAQ v6.0

3 Készítette Demeter Anikó, Prágay István, Horváth Ákos A jelen dokumentum tartalma szerzői jogi védelem alatt áll, a mű felhasználói jogai a GIRO Zrt.-t illetik. A dokumentumot az Ügyfél korlátlan számban a számítógépére letöltheti, adathordozókon tárolhatja, kinyomtathatja, saját célra használhatja, azonban a dokumentum - részeinek, vagy egészének - nyilvánosságra hozatalára, terjesztésére, átdolgozására, feldolgozására, bárminemű egyéb módosítására, fordítására kizárólag a GIRO Zrt. jogosult, illetve az Ügyfél vagy más személyek ezeket a jogokat kizárólag a GIRO Zrt. írásába foglalt engedélye alapján gyakorolhatják. Napközbeni többszöri elszámolás projekt - gyakran ismételt ek InterGIRO2 GYIK / FAQ v6.0 Oldalak száma: 33 GIRO Zrt. Budapest,

4

5 IG2 GYIK GIRO Zrt. Tartalomjegyzék Általános tájékoztató InterGIRO2 működése Szakaszbeosztás Fedezetbiztosítás SEPA/UNIFI ISO szabványok Egyéb IG2 monitor (interaktív terminál) EIS 2.3 ek nyomán javítandó, pontosítandó hibái Verzió: v6.0 Dátum: oldal

6 GIRO Zrt. IG2 GYIK ÁLTALÁNOS TÁJÉKOZTATÓ A klíringtagok által feltett eket és GIRO okat az alábbi témák szerint csoportosítva, folyamatosan (havonta) frissítve jelenítjük meg a GIRO honlapjának IG2 szekciójában ( 1 ) és ahol lehet, megadjuk az EIS (Külső Interfész Specifikáció) hivatkozást. A banki eket egyes esetekben a lényeg megtartása mellett az egyszerűbb érthetőség érdekében csekély mértékben módosítottuk. Verziókövetési információ: Verzió Módosítások leírása Dátum 1.0 G1-G43, S1-S3, F1-F3, U1-U6, E1-E G44-G52, U7-U23, E G53, U24-U33, E9, M1-M8, korábbi ok v3.0 kiegészítése számos ponton 4.0 G54-57, U34-U37 korábbi ok 4.0 kiegészítése számos ponton 5.0 G58-64, U38-U47, E10 korábbi ok 5.0 kiegészítése számos ponton 6.0 G65-66, U48-50 W1-W9 korábbi ok 6.0 kiegészítése számos ponton A eket és okat az alábbi módon osztályoztuk: G) InterGIRO2 működése S) Szakaszbeosztás F) Fedezetbiztosítás U) SEPA/UNIFI ISO szabványok E) Egyéb M) Monitor W) EIS 2.3 ek nyomán javítandó, pontosítandó hibái (későbbi változatokból eltávolítandó pont) Jelen (v6.0) változat a klíringtagok november 17-ig feltett eit és a okat tartalmazza. 1 Az oldal jelszóvédett; amennyiben nem találja a belépési adatait, az info@mail.giro.hu címen tudunk segítséget nyújtani! 2. oldal Dátum: Verzió: v6.0

7 IG2 GYIK GIRO Zrt INTERGIRO2 MŰKÖDÉSE G1. Az EIS szerint a fájlneveknek nem kell egyedinek lenniük a nap során, de ugyanakkor több SCF is keletkezhet, ha a kiküldendő megbízások száma meghaladja az egy SCF-be helyezhető megbízások számát. Célszerűnek látszik a file-név megkülönböztetés napon belül, ha több azonos típusú file is készülhet. Csak a résztvevő által beküldött input fájlok nevei lehetnek nem egyediek, a GIRO által küldött SCF-ek minden esetben egyediek, mert a rendszer gondoskodik a fájlnevek egyediségéről. G2. Egy küldő file-ba (ICF) több BULK is kerülhet-e? Egy input fájlban csak egyetlen homogén (azonos típusú megbízásokat tartalmazó) BULK szerepelhet. G3. Az indító bank a camt.056-ot, pacs.004-et és camt.029-t tranzakciótípusokat is (típusonként) az ICF-ben küldi a GIRO felé? Igen. Egy ICF csak egyféle üzenettípust, azon belül tételt tartalmazhat. Egy ICF-ben tehát csak camt.056 vagy camt.029 vagy pacs.008 vagy pacs.004 lehet, de ezekből akár tétel is. v5.0 kiegészítés: Egy ICF csak egyféle üzenettípust, azon belül tételt tartalmazhat G4. Várhatóan mikortól lesz használható az összes jelenlegi BKR tranzakciótípus és tranzakciókód? Az InterGIRO2 induláskor (2012. július) csak a és a tranzakciókódot kezeli. A visszautalások kódja (2ttss) expliciten soha nem jelenik meg a SEPA megbízásokban. A visszautalás (pacs.004) mindig tartalmazza az eredeti megbízás minden fontos adatát, ebből lehet következtetni, hogy milyen tranzakciókódú visszautalásról van szó. (Az eredeti megbízásban a Local Instrument mezőben csak a kód szerepel. Bár a kód is feltüntethető, de ez felesleges, mivel a Local Instrument mező hiánya egyenértékű a kóddal.) Lásd EIS v2.1 I. kötet 3.2; 4.1.5; fejezet G5. IG2_EIS I. kötet 3.2 pontjában említett Local Instrument mezőben kötelezően kitöltendő a tranzakció kódja (00100,00701)? v 4.0 kiegészítés: A Local Instrument mező kitöltése a SEPA szerint is és az IG2 szerint is tható. Ha ki van töltve, akkor csak ISO kódot (LclInstrm/Cd) vagy IG2 saját (az IG2GMDB-ben lévő) saját tranzakciókódot (LclInstrm/Prtry) tartalmazhat. Jelenleg használható IG2 tranzakciódok: , Mivel a tranzakciókódhoz semmilyen kiegészítő magyar sajátosság nem tartozik, a tranzakciókód használata el is hagyható, azaz a Local Instrument adatelem nélküli és a LclInstrm/Prtry mezőben értéket tartalmazó HCT egyaránt egyszerű átutalást jelöl. Ha egy bank csoportos átutalást indít és ezt jelezni is akarja, akkor nemcsak a LclInstrm/Prtry mezőt kell kitölteni értékkel, hanem a csoportos átutalás egyéb sajátosságait (jogcímkód, bázisazonosító, ügyfélazonosító) is be kell írni a megfelelő mezőkbe Mivel a Local Instrument mező használata banki megállapodáson alapul, és a magyar bankok csak a BKR saját tranzakciókódok használatában (LclInstrm/Prtry) állapodtak meg, a szabványos ISO kódok használata (LclInstrm/Cd) az IG2-ben nem engedélyezett. v5.0 kiegészítés A SEPA szabványos ISO kód használata (LclInstrm/Cd) az IG2-ben engedélyezett. Verzió: v6.0 Dátum: oldal

8 GIRO Zrt. IG2 GYIK v 6.0 kiegészítés ld. W5. G6. A példákban a csoportos átutalás tranzakcióknál nem található meg az ügyfélazonosító mező (private identification)? Az ügyfélazonosító (customer identifier) szerepel az események leírásánál is, pl. customer identifier Nagy Balázs (Ultimate Creditor proprietary field) és a kifejtett példában is: CdtTrfTxInf/UltmtCdtr/Id/PrvtId/Othr (Nagy Balázs). A példa az ügyfél nevében is és ügyfélazonosítóban is ugyanazt a (Nagy Balázs) karaktersorozatot szerepelteti. G7. Milyen karakterek használhatók a HCT tranzakciókban? Mit értünk UTF8 alapkészleten? Ez azt jelenti, hogy a magyaron kívül egyéb speciális karakterek (pl. nem lesznek használhatóak? Az EIS v2.1 I. kötetében a HCT alapellenőrzésl ( fejezet, 2.6 pont) szerint az UTF8-beli alapkészleten kívül a tranzakciókban csak az ékezetes magyar karakterek használhatók. A fentiektől eltérő karakterek esetén a visszautasítás hibakódja HU36. A SEPA (SCT RB) az alap latin karakterkészletet (kisés nagybetűk, számok, ill. a köv. karakterek: / + - : (). szóköz ) használatát támogatja, javasolja, a többit rábízza a résztvevőkre (bilaterális megállapodás alapján mást is használhatnak). A GIRO az UTF8 alapkészleten az ASCII (hexa 20 7E) közötti összes karaktert érti. Meg fogjuk kérdezni a fejlesztőt és a szerint módosítjuk, kiegészítjük az EIS-t. G8. Bázisazonosítóbeli összeállítási dátum kötelezően kisebb az érvényes elszámolási dátumnál? Ld. U8 Az EIS v2.1 I. kötetében a HCT kiegészítő ellenőrzés (4.1.3 fejezet, pont) szerint az 8 karakter hosszúságú összeállítási dátum bázis-azonosítóban a dátum minimum 1 és maximum 15 naptári nappal lehet régebbi, mint az érvényes elszámolási dátum. Az aznapi elszámolás és kiegyenlítés esetén az összeállítási és elszámolási dátum azonossága (egyenlősége) is elfogadható, ezért az ellenőrzési feltétel következő módosítását kértük a fejlesztőtől: a bázisazonosító összeállítási dátuma lehet egyenlő az érvényes elszámolási dátummal, vagy annál max. 15 naptári nappal régebbi. A fejlesztő beleegyező a után módosítjuk az EISt. v 6.0 kiegészítés EIS v2.3 I. kötet , pont szövege: Az összeállítási dátum legkorábban az aktuális elszámolási nap, de maximum 15 naptári nappal lehet régebbi, mint az érvényes elszámolási dátum; G9. Lesz-e majd tranzakció-prioritás? Nem lesz. Az általános funkcionális specifikáció 2009-es elkészítése során az akkori munkacsoport elvetette a priorizálás lehetőségét. G10. Melyik tételekről keletkezik pacs (Payment Status Report? Igaz-e, hogy minden beküldött ICF (.I kiterjesztésű) file-ra kapunk ul pontosan egy PSR (.V kiterjesztésű) file-t, amelyben az OrgnlGrpInf/OrgnlMsgId tag tartalmazza az eredeti file GrpHdr/MsgID-jében megadott id-t? Minden ICF-re keletkezik PSR, amelyik hivatkozik az ICF belső azonosítójára (OrgnlGrpInf/OrgnlMsgId). Ha az ICF minden tranzakciója jó, vagy az ICF fájlszinten hibás, akkor erről rövid (tételek nélküli) PSR tájékoztatja az ICF benyújtóját. A PSR-beli visszajelzési kód hibátlan ICF esetén ACCP, fájlszinten hibás ICF esetén pedig RJCT Ha az ICF-ben voltak jó és hibás tranzakciók is, akkor a PSR csak a hibásakat tartalmazza. A PSR-ben a visszajelzési kód ilyenkor PART. 4. oldal Dátum: Verzió: v6.0

9 IG2 GYIK GIRO Zrt. G11. A PSR köteg szintű? (Kötegenként történik a PSR visszaküldése?) G12. Beküldése után honnan tudhatjuk, hogy a megbízás melyik ciklusba lett befogadva? v 4.0 kiegészítés: G13. Mely üzenetekből értesül a Bank arról, ha egy adott tétel átkerült a következő ciklusba? Milyen formája lesz az üzenetnek (csak a GIRO monitoron lesz látható vagy a Bank számára bedolgozható formája lesz)? Elszámolt tranzakció esetén, hogyan lehet pontosan meghatározni, hogy melyik ciklusban lett elszámolva? Igen. Minden input (ICF.I) fájlra egy visszaigazoló, az IG2 általi ellenőrzés eredményét tartalmazó validációs fájl (PSR.V) készül. A GIRO kérte a fejlesztőt, hogy a PSR-beli kiegészítő információ (Additional Information) mezőbe írja bele annak a szakasznak a számát, ahova az IG2 feldolgozásra besorolta az ICF-et. A fejlesztő visszajelzése alapján fogjuk a dokumentációt módosítani. A GIROHáló átvételi nyugtán szereplő időpont alapján eldönthető. A cut-off előtt átvett tételek a következő szakaszban kerülnek feldolgozásra. A PSR külső fájlneve tartalmazza annak a szakasznak az azonosítóját, amelyben az ICF feldolgozásra került. Jelenleg nincs ilyen üzenet. A GIRO kérte a fejlesztőt, hogy a szakaszvégi jelentéssel együtt adjon ki egy jelentést az adott szakaszban elszámolt (vagy továbbgörgetett) tranzakciókról. A fejlesztőtől a későbbiekben beérkező visszajelzés alapján fogjuk a dokumentációt módosítani. SSR és SRR jelentések elkészítését a szállító vállalta. A jelentések specifikációját az országos projekt kapcsolattartók megkapták (ld.: IG2_feature_requests_v1.0_forBMCS.doc) v 6.0 kiegészítés Ld. EIS v2.3 vol I.: 4.5.1, EIS v2.3 vol II. 3.2, 3.3 G14. Az MNB által küldött MT900 / MT910-ben megjelenik-e a szakaszazonosító? (IG2 szakasz száma). Ha nem, kérhető ennek megjelenítése? G15. A dokumentum szerint a SCF tartalmazhat átutalást vagy visszahívást, vagy visszautasítást. Recall NACK-ot nem? G16. SCF file-ban van szakaszazonosító (hányadik szakasz)? Függőben lévő, a szállítótól vár t a GIRO. A cél legalább a szakasz számának megjelenítése, a jóváírásban a főbb forgalmi adatokat is megjeleníteni tervezzük A szállító a fejlesztést elvégzi, a VIBER szabványkönyv tervezete már tartalmazza (ld pont. A tervezet a oldalon található meg. Recall Nack-ot tartalmazó SCF is van. Fontos megjegyezni, hogy egy SCF csak egyféle műveletet: átutalást, visszautasítást, visszahívást, vagy visszahívás elutasítását tartalmaz. Nincs Igen. A fejlesztő megvalósította. v 6.0 kiegészítés Ld. EIS v2.3 vol. I G17. Lehet-e tranzakció szinten szakaszonként rekonsziliálni? v 6.0 kiegészítés Jelenleg nem. Az IG2 által visszautasított tranzakciókat a folyamatosan kiküldött PSR (Azonnali Visszajelzés) fájl, a törölt (visszavont) tranzakciókat pedig a Törlési Információs fájl (CPSR) tartalmazza. Az elszámolt (és továbbgörgetett) tranzakciókra vonatkozóan a GIRO kérte a fejlesztőt, hogy a szakaszvégi jelentéssel együtt adjon ki egy jelentést az adott szakaszban elszámolt (vagy továbbgörgetett) tranzakciókról. A fejlesztőtől a későbbiekben beérkező visszajelzés alapján fogjuk a dokumentációt módosítani. Igen SSR és SRR jelentések elkészítését a szállító vállalta. A jelentések specifikációját az országos projekt kapcsolattartók megkapták. (ld.: IG2_feature_requests_v1.0_forBMCS.doc) Ld. EIS v.2.3 Verzió: v6.0 Dátum: oldal

10 GIRO Zrt. IG2 GYIK G18. Milyen automatikus üzeneteket küld a Giro a bank részére az egyes ciklusok után, ezek milyen formában és mely időpontokban várhatóak? v 6.0 kiegészítés Ld. EIS v2.3 G19. Utolsó ciklusba való beküldésnél honnan lehet tudni, hogy már nem került befogadásra a file? v 4.0 kiegészítés: G20. Egy visszahíváskérés-file-ba (camt.056 ICF) csak olyan tételek kerülhetnek-e, amelyeknél az Engedményező bankja ugyanaz? (pl. az egyik file-ba csak az A bankba induló visszahívási kérések kerülnek, egy másikba a B bankba induló kérések stb.) G21. A visszahívás kérések (camt.056) nem a többi fogadó köteggel kerülnek-e kiküldésre az IG2- ből a DP-k részére? Az input fájl ellenőrzésének eredményét (az Azonnali Visszajelzést, PSR-t) az IG2 folyamatosan küldi ki a fájlt benyújtó Közvetlen Résztvevőnek. Minden szakasz elszámolása után a Közvetlen Résztvevők a Szakaszvégi Jelentésből értesülnek a legfontosabb információkról (pl. elszámolt, továbbgörgetett, fogadott tranzakciók száma és összege), a fogadó köteg (SCF) pedig az ügyfelek számláin jóváírandó tranzakciókat tartalmazza. A törölt megbízásokról a Törlési Információs fájl (CPSR) tájékoztatja a beküldő Közvetlen Résztvevőt. SSR és SRR jelentések elkészítését is vállalta a szállító. A jelentések specifikációját az országos projekt kapcsolattartók megkapták (ld.: IG2_feature_requests_v1.0_forBMCS.doc). PSR TM01 hibakóddal jelzi a késői küldés miatti visszautasítást. Ld. EIS v2.1 I. kötet fejezet, Általános ellenőrzés A későn érkezett fájlra adott GIROHáló átvételi nyugtában szereplő időpont későbbi, mint az utolsó szakasznak az üzemidő tábla szerinti GIRO befogadási időpontja. A PSR külső fájlnevében a szakasz-azonosító értéke NA Egy input fájlban több, különböző címzett (az eredeti átutalás kedvezményezettje) felé irányuló visszahívás (camt.056) szerepelhet Az IG2 által nem teljesíthető, a már elszámolt átutalásokra vonatkozó visszahívásokat tartalmazó fogadó kötegek azonnal (a nap folyamán bármikor) továbbításra kerülnek a címzettek (az eredeti átutalás kedvezményezettjeinek) bankjának. G22. A fogadó kötegektől (SCF) függetlenül a nap folyamán bármikor várható visszahívás kérés fogadó köteg (camt.056)? Az IG2 által nem teljesíthető visszahívásokat az IG2 azonnal továbbítja a címzetteknek, ld. magyar nyelvű EIS 27. oldal utolsó bekezdés v 6.0 kiegészítés G23. A Recall funkció csak tranzakció-, vagy csoportszinten (is) értelmezhető lesz-e? G24. A Recall NAK file a tranzakció-visszahívás (Recall) elutasításáról szól, míg a visszahívás elfogadásánál egy normál visszautalás file-t készít a címzett bank (Recall ACK)? G25. A Recall, és Recall NAK üzeneteket az Intergiro 2 változtatás nélkül továbbítja a címzett felé (mert ezeknek nincs elszámolása)? EIS pont alatt található (v2.3 magyar változatban a 40. oldalon) Recall funkció homogén csoportszinten (egy küldő egy fogadó), és tranzakciószinten értelmezhető. Átutalásokat (pacs.008) tartalmazó input fájl (ICF) visszavonása (camt.056-tal) tranzakciónként vagy pedig (IG2 monitorról) homogén csoportonként történhet. Lásd EIS v2.1 I. kötet fejezet: Néhány megjegyzés a visszahívásokkal (Recall) kapcsolatban Igen, a Recall (camt.056) visszautasítása a Recall NAK (camt.029), teljesítése pedig visszautalással (pacs.004) történik. Igen. A már elszámolt tranzakciókat visszahívó Recall (camt.056) megbízások, és a Recall-t visszautasító (camt.029) megbízások beérkezésük után azonnal, a soron következő elszámolási szakasz eredményei előtt, külön homogén SCF fájlban kerülnek továbbításra a címzettekhez. G26. Lesz-e visszaigazoló üzenet a visszahívásra? Visszahívás(oka)t tartalmazó input (ICF) fájlra azonnal készül validációs fájl (PSR). Amennyiben elszámolás 6. oldal Dátum: Verzió: v6.0

11 IG2 GYIK GIRO Zrt. előtt érkezik a visszahívás, akkor a visszavont (törölt) átutalásokat tartalmazó Törlési Információs fájl (CPSR) a szakasz végén kerül kiküldésre. A már elszámolt tranzakciókra vonatkozó, a kedvezményezett bankjának továbbított visszahívásokról a visszahívásokat tartalmazó input fájl (ICF) ellenőrzésének eredményét tartalmazó Azonnali Visszajelzésből (PSR) a bank implicit módon értesül a továbbításról, azaz a PSR-ben hibásként nem szereplő visszahívási tranzakciókat az IG2 elfogadta, és a CPSR fájlban nem szereplő visszahívásokat továbbította a kedvezményezett bankjának. v 4.0 kiegészítés: A sikeresen végrehajtott, teljesített visszahívások (camt.056 tranzakciók és a visszahívás miatt törölt átutalások (pacs.008 tranzakciók) főbb jellemzőit a CPSR fájl tartalmazza. G27. Hány napig lehetséges visszahívást küldeni abban az esetben, ha a kedvezményezettnek már jóváírták a tételt? v 6.0 kiegészítés G28. Mi számít múltbeli visszahívásnak, a már elszámolt AZNAPI is? G29. Hogyan kell hivatkozni az egyedi azonosítókra visszautalás, visszahívás esetén? G30. Ha az indító bank camt.056-ot indít a kedvezményezett bank felé úgy, hogy az IG2 még törölni tudja a visszahívandó utalást, akkor a CPSR mikor érkezik: a PSR-rel egyidejűleg? G31. A jelenlegi IG1 monitort az IG2 is fogja-e használni a tételek visszavonására, vagy új, más megoldás készül erre. Ha más, akkor mi lesz az, hogyan fog működni? A GIRO oldal szabályozott lesz (erre a célra szolgáló üzenet, várhatóan naptári nap a visszahívásra, illetve az arra adandó ra). Az ügyfél oldal az IG1- ben sem volt szabályozott, az IG2-ben sem lesz az, vagyis a pénz visszakérésének nincsen szabványosított módja. EIS 2.3 vol I szerint: a visszavonást (camt.056 megbízást) az átutalást követő 0-45 naptári napon belül, a visszavonásra adott t (pacs.004 és / vagy camt.029 tranzakciót) pedig az eredeti átutalást követő 0-90 naptári napon belül kell kezdeményezni. Igen, a már elszámolt aznapi megbízás is múltbéli abból a szempontból, hogy kizárólag camt.056-tal vonható vissza (monitorról nem). A camt.056 azonnal továbbításra kerül a kedvezményezett bank részére. Minden olyan tranzakciótípus (visszavonás, bank általi visszautasítás és visszautalás, visszavonás visszautasítása), amelyik valami múltbeli, előzetes tranzakció hatására keletkezett, kötelező jelleggel tartalmazza az előzmény tranzakció legfontosabb adatait (pl. tranzakció-azonosító, összeg, BIC-ek és számlaszámok). Lásd az EIS v2.1 II. kötetében (Üzenetszabványok) A sikeres visszahívás a monitoron azonnal megjelenik, a camt.056 tranzakciókat tartalmazó input (ICF) fájlra azonnal készül az IG2 általi ellenőrzés eredményét tartalmazó (.V kiterjesztésű) validációs fájl (PSR). A törlést visszaigazoló.c kiterjesztésű fájl kiküldésére csak a szakasz végén, a szakaszjelentésekkel egyidejűleg kerül sor. Az IG1 és az IG2 külön monitorral fog rendelkezni (természetesen igyekszünk, hogy az IG1ben is meglévőkhöz hasonló kijelzések legyenek az IG2ben is). A menüstruktúrát és a képernyőkijelzéseket az IG2 Felhasználói / Monitor Kézikönyvben fogjuk részletezni. A kijelzések pontos formai ismerete a fejlesztés késői szakaszáig még nem fontos, mivel azok a vizuális áttekintést hívatottak szolgálni, a banki belső rendszerek IG2 közötti külső interfész programozásához nem szükséges. A kijelzések tartalmi ismertetését az InterGIRO2 monitor képernyő-kijelzéseinek v0.9 verziójában lehet megtalálni. Ezek újabbak, mint az EIS v2.1 I. kötetében található képernyőminták. Felhívjuk a figyelmet, hogy az IG2-ben a visszavonást nem csak monitorról, hanem tranzakcióval (camt.056) is Verzió: v6.0 Dátum: oldal

12 GIRO Zrt. G32. Honnan tudhatjuk, hogy az utolsó szakaszban fedezethiány miatt mely tételeket utasította vissza a rendszer? G33. Honnan lehet tudni, hogy vége van egy ciklusnak és már nem érkezik több állomány? Az EoS riport kiküldése tekinthető ciklus vége jelnek? G34. Honnan tudjuk, hogy kell-e még várni további file-okra? Az EoD riport kiküldése tekinthető nap vége jelnek, ami után aznap már több file-t nem küld ki IG2? G35. Igaz-e, hogy (.C kiterjesztésű) Cancellation PSR file-t egyszer, az utolsó ciklus végén kap a bank? Ha több mint törölt tétel van, akkor több file is lehet? G36. Ha a nap végén fedezethiány miatt visszautasított tranzakciók több ICF-ből származnak, akkor sem lesznek összesöpörve egy CPSR-be (még ha kevesebb is, mint db), hanem ICF-enként külön-külön CPSR készül majd, ami OrgnlGrpInf/OrgnlMsgId-el hivatkozik az eredeti ICF-re? G37. Amennyiben az InterGIRO1-hez elkészül a banki fejlesztés az aláírás és a fájltovábbítás funkciókra, akkor az alkalmazható-e az InterGIRO2 rendszerben? G38. GIRO Cut-off time időpontjában éppen beküldés (GiroHáló) alatt álló fájllal mi történik? Még be lesz fogadva vagy átesik a következő ciklusba? G39. A FIFO-t adott szakaszban csomagra, vagy csomagon belül értendő? Ha nincs részteljesítés, akkor hogyan alkalmazható, értelmezhető a FIFO? lehet kezdeményezni. További monitor (M) ek alatt IG2 GYIK A nap végén fedezetlenség miatt visszautasított akárcsak a sikeresen (még az elszámolás előtt) visszahívott tranzakciókról a Törlési Információs fájl CPSR (Cancelled Payment Status Report) tájékoztat. A CPSR beli kód jelzi, hogy a fájl az utolsó szakaszban a fedezethiány miatt (AM04) vagy pedig a visszahívás miatt (CUST) törölt tranzakciókat tartalmazza. Lásd EIS v2.1 I. kötet fejezetben. A funkcionális követelmények dokumentum csak a szakasz végén kiküldendő eredményfájlokat sorolja fel, nincs szigorúan meghatározott kiküldési sorrend. Ennél pontosabb t csak a tesztelés után tudunk adni. A funkcionális követelmények dokumentum csak a nap végén kiküldendő eredményfájlokat sorolja fel, nincs szigorúan meghatározott kiküldési sorrend. Ennél pontosabb t csak a tesztelés után tudunk adni. Több CPSR is keletkezhet egy nap. CPSR tudósít a sikeresen (elszámolás előtt) visszavont tételekről is, és nap végén a fedezethiány miatt elszámolatlan tételekről is. Mivel egy ICF és egy CPSR kölcsönösen egyértelműen megfeleltethetők egymásnak, egy CPSR max tételt tartalmazhat. A különbözö ICF-ekből származó fedezetlen tranzakciók annyi CPSR-ben fognak szerepelni, ahány ICF-ben küldte be a bank. Igen, az aláírás és a fájltovábbítás a április 4-től kizárólagossá vált STP-elvek alapján zajlik majd (GIROHáló GIROFile adattovábbítási mód). A GIROHáló elve szerint egy adott fájl beküldésének szakasza a GIROHáló-nyugtával ér véget. A beküldés alatt álló fájl IG2 általi feldolgozásának megkezdéséhez szükséges, hogy az állomány a GIROHálón már beérkezzen a CoT előtt, azaz ha a CoT időpontjában a fájl még fájlküldés fázisban van, abban az esetben az IG2 nem fogja elkezdeni a fájl befogadását és feldolgozását az adott szakaszban, hanem automatikusan a következő szakaszba esik be. Ha a tényleges fájlküldés már éppen befejeződött a CoT előtt, de a GIROHáló-nyugta még nem zárta le a beküldés szakaszt, abban az esetben az IG2 a feldolgozást még az adott szakaszra vonatkozóan fogja elvégezni. A GIRO kérte a fejlesztőt, hogy a Közvetlen Résztvevő kapjon minden beküldött fájlra egy időpecsétes technikai átvételi igazolást (delivery notification). Ha az időpecsét az adott szakasz befogadási időpontjának vége (COT) előtti, akkor az IG2 az adott szakaszban megkezdi a fájl feldolgozását. A FIFO szerinti elszámolás a beküldött input fájlok sorrendjében, a fájlokon belül pedig - az elszámolás egységétől függően - tranzakciónként vagy homogén csoportonként történik. Ha az elszámolás egysége a homogén csoport (egy input fájlon belül ugyanannak a Klíringtagnak címzett tranzakciók összessége), akkor a rendszerparaméter értékétől függően - a fájlon belül a tranzakciók sorrendje megegyezik az elszámolás 8. oldal Dátum: Verzió: v6.0

13 IG2 GYIK GIRO Zrt. sorrendjével, vagy pedig ez a sorrend felborul (mert pl. ha az 1. és a 26. és az utolsó tranzakció címzettje ugyanaz a Klíringtag, akkor ezek a tranzakciók hamarabb elszámolódnak, mint pl. a , és a 27.- utolsó előtti tranzakciók). G40. Az elszámolás tétel vagy köteg alapú lesz? Biztosan nem köteg alapú lesz az elszámolás, hanem a rendszerparaméter értékétől függően tétel vagy homogén csoport szintjén történik. G41. A bázisazonosítóban (BASEID) szereplő szóköz használható az <EndToEndId> mezőben? A no space allowed arra utal, hogy csupa szóköz nem lehet a mező tartalma? A <TxId>-ra ugyanez a megfogalmazás igaz. A Max35Text pedig String mely min. 1, max. 35 karakter és nem lehet csupa szóköz. A <TxId> például használhatná a jelenlegi G4-2 (6) + G4-3 (5) + G5-1 (8) + G5-2 (7) amiben szintén van szóköz a G4-2 ben. G42. A strukturált közlemény (CdtTrfTxInf.RmtInf.Strd.CdtrRefInf.Ref) mezőben hány karakter továbbítható? Az EIS 2.1 verzió II. kötetében a strukturált közlemény esetében 35 karakter a max. hossz. Az xsd-ben nem látjuk ezt a karakterkorlátot. A SEPA Credit Transfer Inter-bank Implementation Guidelines Version 5.0-ban ez a leírás szerepel: Format Rule: Structured can be used, provided the tags and the data within the Structured element do not exceed 140 characters in length. A strukturált közlemény továbbításához kapcsolódóan valóban minden előtte található tag-et is továbbítani kell? (Creditor Reference Information alatt Multiplicity gyel jelölt tag-ek) G43. Lesz-e értesítés, ha valamelyik banktól nem sikerült beszedni a szükséges fedezetet az utolsó ciklusban? A no spaces allowed kifejezés azt jelzi, hogy sehol sem lehet egyetlen szóköz sem a mezőben. Ha tehát az InterGiro1 (BKR) felépítésű tranzakcióazonosítót szándékoznak használni az InterGIRO2-ben, akkor a szóközöket valamilyen karakterrel helyettesíteni kell. Ugyanez vonatkozik a bázisazonosítóbeli szóközökre is. Az InterGIRO2 elfogad 9 karakter hosszúságú intézményazonosítót is a bázisazonosítóban. (Lásd EIS v2.1 magyar nyelvű kiadás 31. oldal pont). 1. az xsd hivatkozott mezője tartalmazza a 35 karakteres korlátot Igen, a 140 karakterbe beszámít minden < kezdő > és </ záró > tag is. A típus alatt a structured communication (SCOR) jelzőt feltétlenül szerepeltetni kell. Az Issuer adatelem szerepeltetését, használatának lehetőségét felvételét kérni fogjuk a fejlesztőtől (hogy a Postát itt fel lehessen tüntetni). Az Issuer (Issr) címkét az EIS v2.2 tartalmazza A bankonkénti visszajelzést (beszedendő összeg, nyitó egyenleg) a szakaszvégi jelentés tartalmazza. A GIRO kérte a fejlesztőt, hogy az utolsó ciklusban adjon jelzést a bankoknak, hogy a fedezetképzés teljeskörűen megtörtént-e (és így minden tétel elszámolható lesz, vagyis a végleges záró egyenleg meg fog egyezni a GIRO által előzetesen közölt egyenleggel), vagy pedig nem. A GIRO körüzenetben tájékoztatja az összes Közvetlen Résztvevőt az összbanki szinten hiányzó fedezetről (a hiányzó fedezet értéke 0, ha minden banktól sikerült beszedni a fedezetet). A fejlesztőtől a későbbiekben beérkező visszajelzés alapján fogjuk a dokumentációt módosítani. Fejlesztő a kérést visszaigazolta. A fejlesztő részére készített specifikációt a projekt kapcsolattartók megkapták. v 6.0 kiegészítés Ld. EIS v2.3 vol I., E) G44. A jelenleg használatos tranzakciókódokat lehetne-e továbbra is használni, esetleg minden esetben kötelezővé tenni? (CdtTrfTxInf/PmtTpInf/LclInstrm/Prtry; TxInf/OrgnlTxRef/PmtTpInf/LclInstrm/Ptry - Az IG2 a júliusi induláskor a BMCS döntése szerint csak a és a tranzakciókódot fogadja el. A tranzakcióköd használata nem kötelező. A tranzakciókód esetén az IG2 az alapvető Verzió: v6.0 Dátum: oldal

14 GIRO Zrt. segítené a tranzakciók típusának azonosítását G45. A Local Instrument mező alatti két tag <Cd > és <Prtry> közül, melyik esetben melyik töltendő? v 4.0 kiegészítés: G46. Visszahívásra t a GIRO nem ellenőriz (valóban volt-e eredeti tranzakció), ugyanakkor a két számlaszám adat nem kötelező. Ha nincs eredeti visszahívó üzenet és nincsenek megadva az opcionális számlaszám adatok, akkor nem tudható ki küldi kinek az összeget. Várható ezen a területen bármilyen módosulás, vagy ez így jó? v 6.0 kiegészítés: G47. Elsősorban az a meddig lehet egy tranzakcióra visszahívást indítani? Van-e bármilyen megkötés? Avagy előfordulhat-e, hogy úgy kapunk visszahívást, hogy az eredeti tranzakció már nincs az adatbázisban (illetve a Giro nem ellenőrzi az eredeti tranzakciót)? v 6.0 kiegészítés: G48. 2 Van megfeleltetés az IG1-es átutalás a csoportos átutalás tranzakció és a HCT üzenet között? G48./a A címmező gyakorisága az UNIFI ISO20022 szabvány szerint [0..7], az EIS szerint viszont a max. előfordulás 2. (EIS v2.3 I. kötet 9. MELLÉKLET kedvezményezett címe / AT-22) G49. Hivatkozva a visszahívás tranzakció IG2-es specifikációjára, szeretném megkérdezni, hogy IG2 GYIK magyar sajátosságokon kívül ellenőrzi a csoportos átutalás speciális mezőinek (bázisazonosító, ügyfélazonosító, jogcímkód) a helyes kitöltöttségét is és a csoportos szerepköröket is. Egyszerű átutalásnál a Local Instrument egyiket mezőjét sem kötelező kitölteni. Csoportos átutalásnál a <Prtry> mezőben szerepeltetni kell a kódot, hogy az IG2 ellenőrizze a bázisazonosító, jogcímkód és ügyfél-azonosító helyes kitöltöttségét, ill. a csoportos szerepköröket. Egyszerű átutalás -sal szemben az egyéb átutalás pontosabb meghatározás A szabványos ISO kód <Cd > nem használható. Lásd a G5 v4.0 kiegészítését Banki döntés volt az, hogy az IG2 ne keresse a párját sem a múltbeli recall-nak (camt.056), sem a recall ainak (pacs.004, camt.029). A bankok felelőssége, hogy az azonosításhoz szükséges minden mezőt helyesen töltsenek ki. A visszahívás nem-párosítás funkció egyelőre függőben lévő, még nem visszaigazolt fejlesztés. Visszaigazolás megtörtént EIS 2.3 tartalmazza, de az IG ben még nem így működik A BMCS döntés szerint a visszahívás napig indítható, azaz egy átutalás az elküldését követő 45 napig visszahívható. A visszahívásra adott (pozitív vagy negatív ) a visszahívás (recall, camt.056) fogadását követő 45 napig indítható. A GIRO az azonos napi visszahívás kivételével nem ellenőrzi, hogy volt-e előzmény párja a visszahívásnak. (Visszahívás, camt.056 előzmény párja az átutalás, pacs.008; a visszahívásra adott pozitív, pacs.004, ill. negatív, camt.029 nak az előzmény-párja szintén az eredeti átutalás, pacs.008.) Banki döntés volt az, hogy az IG2 ne keresse a párját sem a múltbeli visszahívásnak (recall, camt.056), sem a visszahívás ainak (pacs.004, camt.029). A bankok felelőssége, hogy az azonosításhoz szükséges minden mezőt helyesen töltsenek ki. A visszahívás nem-párosítás funkció egyelőre függőben lévő, még nem visszaigazolt fejlesztés Visszaigazolás megtörtént EIS 2.3 tartalmazza, de az IG ben még nem így működik Igen, ld. EIS v2.3 I. kötet 9. Melléklet (ANNEX 9) Az UNIFI ISO20022 szabvány által megengedett [0..7] gyakoriságot az SCT IGL 5.0 verziója (SEPA CREDIT TRANSFER SCHEME INTER-BANK IMPLEMENTATION GUIDELINES) max. 2-re korlátozza [0..2]. Az IG2 EIS v2.3 az SCT IGL v5.0 val összhangban 2*70 karakterre korlátozta a cím maximális méretét. Az IG2-ben a CLRG jelentése eltér az IG1 klíring tranzakció fogalmától. A klíring tranzakció, nem klíring 2 v6.0-ban javítottuk a v3.0 során bekerült pontatlan szöveget. Ennek keretében került G48 megbontásra G48-ra és G48/a-ra. 10. oldal Dátum: Verzió: v6.0

15 IG2 GYIK jól sejtem-e hogy az alábbi új tranzakció klíring üzenet? SttlmMtd>CLRG</SttlmMtd> G50. Miért van az EOD jelentésben ugyanaz az elszámolási nap ugyanazon szakaszára más MsgId-t és más timestamp, mint a napközben kiküldött EOS fájlokban? GIRO Zrt. tranzakció fogalompár a fizetési tranzakciók és a felhatalmazások megkülönböztetésére szolgáló kizárólagos BKR / IG1 fogalom. A SttlmMtd>CLRG</SttlmMtd> az átutalások és visszautalások elszámolásának, kiegyenlítésének módjára utal. Az IG2-ben nem használjuk a klíring tranzakció fogalmát. Mivel a (camt.056 és camt.029) visszahívások nem igényelnek elszámolást (hiszen nem hordoznak elszámolandó összeget), az elszámolási módszert nem kell szerepeltetni a visszahívásokat tartalmazó kötegben. Egyéb lehetőségek a SttlmMtd értékére: Code Name Definition CLRG ClearingSystem Settlement is done through a payment clearing system. COVE CoverMethod Settlement is done through a cover payment. INDA InstructedAgent Settlement is done by the agent instructed to execute a payment instruction. INGA InstructingAgent Settlement is done by the agent instructing and forwarding the payment to the next party in the payment chain. Mivel az EOD report az IG2 által a napvégén ismét legyártott szakaszvégi jelentéseket tartalmazza, az EOD-beli szakaszvégi jelentések létrehozási ideje és üzenetazonosítója eltér az egyes szakaszok végén gyártott és kiküldött EOS jelentések létrehozási idejétől és üzenetazonosítójától. Ettől eltekintve az EOD-beli EOS jelentések lényegi tartalma azonos az önálló EOS jelentésekben található tartalommal. G51. Miért nincs az EOD riportnak külön - üzenetazonosítója (<MsgId>) - létrehozási dátuma (<CreDtTm>) - elszámolási dátuma (<IntrBkSttlmDt>) - kire vonatkozik (<RcvBIC>) Az utolsó kettő még kitalálható az <EosRprt> részből, de az első kettőre semmi hivatkozás. Jó lenne, ha ebben a tekintetben ez a riport is hasonlatos lenne a PreNotification és az EOS riporthoz (és az összes többi fájl típushoz mindegyik IG2-es üzenetnek van MsgId mezője!!!). Bár kevés esélyt látunk a program utólagos változtatására, és szerintünk az új mezők semmi hozzáadott értékkel nem bírnak, az EOD tartalmának kibővítésére vonatkozó igényt jeleztük a BMCS és a fejlesztő felé. (Az EOD jelentés felépítése és tartalma december óta ismert.) Szállító kiegészíti a napvégi jelentést az igényelt kellékekkel. v 6.0 kiegészítés: Ld. EIS v2.3 vol. II., 5.13 G52. Az IG2 EIS dokumentáció sok helyen hivatkozik az ún. IG2-GMDB-re. Ez kizárólag a GIRO számára készült és használatos dokumentáció, vagy a bankok számára is publikus? Amennyiben nem publikus, a jelenlegi hitelesítő tábla (és UGIRO katalógus) esetleg kiegészítve az SCT Routing táblában szereplő információkkal használható validálásra A GMDB az InterGIRO működéséhez szükséges összes környezeti adatot tartalmazó, saját (belső GIRO) formátumú mesteradatbázis (GIRO Master Database). A GMDB tárolja az MNB-től kapott Hitelesítő Tábla adatait, a bankok által bejelentett banki csoportos szerepköröket és jogcímkódokat, ill. fedezeti paramétereket, az elszámolásforgalmi naptárt, a hibakódokat és magyarázatukat. Verzió: v6.0 Dátum: oldal

16 GIRO Zrt. a specifikációk kialakításához, ill. ellenőrzéshez? G53. BMCS listában, már korábban szerepelt, hogy a Hitelesítő tábla, amit a Bankok kapnak nem minden esetben tartalmaz BIC kódot. A kapott szerint a tesztelés megkezdése előtt a V-BIC mező feltöltésre kerül. Ezzel kapcsolatban lenne pontosító ünk, hogy az üres BIC kód mezőket az MNB tölti fel és a feltöltött HT tábla kerül a Bankokhoz, vagy esetleg más megoldásra gondoltak, ha igen milyen módon tervezték a BIC kódok pótlását? IG2 GYIK A GMDB-ből készítjük el és tesszük közzé minden hónapban az UGIRO Katalógus állományait (a banki csoportos szerepköröket tartalmazó banki fájlt és a jogcímkód-listát, ill. beszedői- és fiók-fájlokat). A bankoknak kiadott állományok (Hitelesítő Tábla, Elszámolásforgalmi naptár, UGIRO katalógus) szerkezeti változását nem tervezzük az IG2 kapcsán, azaz a jelenlegi állományok minden további nélkül használhatók a fejlesztések során! A V-BIC-et a bankoknak kell bejelenteniük, az MNB / GIRO csak felszólíthatja őket az adat megadására. Amennyiben egy bank nem rendelkezik BIC-kel, neki magának kell a SWIFT-től igényelni legkésőbb a évi IG2 tesztelés megkezdése előtt. A HT jelenleg a levelező bankok BIC-jeit tartalmazza a közvetett résztvevők (levelezett bankok) esetén. G54. A tévesen érkezett pacs004 tételek visszautasítására van-e technikai lehetőség az IG2-ben? Esetleg egy újabb pacs004 küldése az eredeti (pacs008) tranzakció adataival? G55 Uncovered HCTs rolled over to the next day mezők (RldOvrND/RldOvrNDNb és RldOvrND/RldOvrNDAmt) mikor lesznek kitöltve az EOD riportban? G56. Recalling HCTs executed mezők (Rec/RecNbExc, Rec/RecAmtExc) egyaránt tartalmazzák a monitoron keresztül és tranzakcióval visszahívott tételeket is EOS riportban? G57. HCTs planned to be cleared mezők (SntAccpHCTs/ClrgHCTsNb, ClrgHCTs/ClrgHCTsAmt) tartalmazzák a teljesítve státuszú visszahívásokat az EOS riportban? A pacs.004 üzenettel már visszautasított átutalások ismételt visszautasítására nincs lehetőség. Lásd az EIS v fejezetében (Item error codes) a HU74 hibakód magyarázatát: All returns must have their unanswered initiating pair (if reason code is NOT FOCR) Akkor, amikor az IG2 az utolsó szakaszban fedezetlen átutalásokat és visszautalásokat (visszautasítás helyett) BCP esetén átgörgeti a következő elszámolási napra Igen. Nem. A visszahívások (camt.056) eleve nem tartoznak az elszámolandó (ClrgHCTs) megbízások közé. Továbbá a sikeresen visszahívott / törölt átutalásokat sem számítja be az IG2 az elszámolandók (ClrgHCTs) közé. G58 G59 G60 Mennyire vehetjük 100%-nak, hogy a tételes szakasz végi visszajelzés megvalósításra kerül látható időn belül (max. 1 hónap). Ha megvalósul, akkor a szakasz végi jelentésben lesz az várható? Amennyiben egy adott köteg csak részben kerül bedolgozásra a GIRO COT előtt, akkor annak bedolgozása hogyan várható: a köteg COT előtti része bedolgozódik és a többit a GIRO visszautasítja, a GIRO teljes köteget visszautasítja, a már megkezdett köteget a GIRO teljes mértékben bedolgozza. A visszahívás és visszahívás negatív a üzenetekben kötelezően használandó a GIRO IG2 rendszer BIC kódja. A GIRO példaállományaiban két értékkel is találkoztunk: A fejlesztő december végére vállalta a tételes szakaszvégi jelentés change request megvalósítását. Erre tud a GIRO is vállalást tenni. A tételes szakaszvégi visszajelzés a szakaszvégi jelentéssel együtt, de nem annak részeként, hanem önálló fájlban kerül kiküldésre. Egy köteg abban a szakaszban kerül teljes egészében feldolgozásra, amelyik fájlbefogadási idejének végénél (CoT) korábbi időpecsét szerepel a kötegre adott technikai nyugtában. Az utolsó szakasz CoT ideje után beküldött köteg teljes egészében (fájl szinten) visszautasításra kerül, A GHUNHUHBGIR BIC azonosítót kell szerepeltetni a camt.056 / visszahívás és a camt.029 / visszahívás visszautasítása tranzakciókat tartalmazó input állomány (ICF) fejében a címzett mezőben (+Assignement / ++ Assignee). 12. oldal Dátum: Verzió: v6.0

17 IG2 GYIK GIRO Zrt. G61 G62 G63 G64 G65 - GHUNHUHBGIR, vagy - GHUNHUHB Kérem adják meg a helyes értéket! Mennyire tekinthető állandónak ez az érték? Mit kell beírni a CS-DETSTA üzenet T427 és T428 mezőjében IG2 esetén? mezőjében Amennyiben a Bank hibás tételt küld, a GIRO-tól milyen üzenet érkezik? Pl. ha egy recall üzenetet ugyanarra a tételre többször küld, vagy egy recall üzenetre többször ol? Milyen üzenettel ol a GIRO abban az esetben, ha a bank által küldött tételt a GIRO visszautasítja, de még a visszautasítás előtt a bank recall üzenetet küld? Az azonnali visszaigazolást mikor kapja vissza a bank? - Azonnal, egy köteg beküldése után, függetlenül az adott szakasz COT-tól, - Vagy a szakaszbeosztás táblában jelölt Tbg időpontban, a szakasz COT-ot követően? Milyen összefüggés van a CPSR küldés és a HU14 ill. HU37 hibakódok között? A hivatkozott kódok azt jelzik, hogy az IBAN számla pozícióján lévő irányító kód nem szerepel az IG2-GMDB-ben. (EIS v2.3 vol1: 44. oldal, és vol2: 448., ill. 449., és 45., ill. 55. oldal) Egy táblázatban az szerepel, hogy CPSR filetípusba is bekerülnek a HU14 és HU37 hibakódos tételek ("sending is suspended" ill. "receipt is suspended"): - vol1: 90. oldalra (HU14 és HU37) Ez az információ szerepel az EIS v2.3 II. kötetében. A fenti (GIRO DVP BIC) azonosítót nem szándékozunk a későbbiekben megváltoztatni. A GHUNHUHB azonosítót a banknak sehol nem kell feltüntetnie. Ez az azonosító a terhelési és jóváírási értesítéseken mint ellenszámla szerepel. A CS-DETSTA.142 üzenet T427 mezőjébe a visszautalás pacs TxInf / ++ RtrId mezőbeli azonosítóját, a T428 mezőjébe pedig az eredeti átutalás pacs.008 +CdtTrfTxInf / ++ PmtId / +++TxId mezőbeli azonosítóját kell beírni.). Felhívjuk a figyelmüket, hogy a DETSTA üzenetben az eredeti és a tranzakció (IG1-re kialakított) 29 karakter hosszúságú hivatkozási kódjával szemben az IG2-ben a tranzakció-azonosítók 35 karakter hosszúságúak lehetnek. Ha egy azonosító hosszabb, mint 29 karakter, akkor a bank feladata az azonosító darabolása és elhelyezése a DETSTA üzenetben. A hibás tételek - a hiba típusától függően - tételszintű vagy fájl-szintű visszautasításra kerülnek a validációs fájlban, a.v kiterjesztésű Payment Status Report-ban (pacs.002 üzenetben). Banki kérésre a visszahívásokat (camt.056 tranzakciókat) és aikat (pacs.004 és camt.029 tranzakciókat) az IG2 - az aznapi visszahívás kivételével - a jövőben csak önmagukban vizsgálja (séma megfelelőség és címzett megléte),a mezőiket nem párosítja, nem veti össze az eredeti átutalással. Aznapi visszahívás esetén az első, sikeresen végrehajtott, teljesített visszahívás után beérkező, a már visszahívott, törölt átutalásra érkező visszahívásokat az IG1 tételszinten visszautasítja. A visszahívásra adott okat az IG2 - banki kérésre - a jövőben csak önmagukban vizsgálja, tehát egy visszahívásra adott több t is elfogad. Ha az aznapi visszahívás (camt.056 tranzakció) a visszahívandó, törlendő átutalás (pacs.008 tranzakció) előtt, vagy pedig a hibás átutalás IG2 általi visszautasítása után érkezik, az eredmény ugyanaz: az IG2 nem találja az eredeti (vagy még be sem érkezett, vagy már visszautasított) átutalást, ezért a visszahívást (pacs.056 tranzakciót) vissza fogja utasítani. Lásd az előző re adott t is. Az Azonnali Visszajelzés - előre láthatóan általában a köteg beküldését követő 20 percen belül esedékes. Ha a köteg közvetlenül COT előtt érkezett be a GIRO-ba, akkor a visszajelzés COT után érkezhet. Alapeset: Ha az IBAN számla 5-12 pozícióján lévő bankszerv-kód nem létezik, azaz nincs a Hitelesítő Táblában a tranzakciót az IG2 visszautasítja a PSRben, indok: HU14 (küldő nem létezik), ill. HU37 (fogadó nem létezik). Fizetés-korlátozás: az IBAN számla 5-12 pozícióján lévő bankszerv-kód létezik, azaz benne van a Hitelesítő Táblában, de az IBAN számla 5-7 pozícióján lévő bankkódú bank a nap során (küldésre és / vagy fogadásra) felfüggesztésre került. Ha a tranzakció a fizetés-korlátozás IG2 általi tudomásul vétele után érkezik, akkor az IG2 a PSR-ben visszautasítja a tranzakciót HU14, ill. HU37 hibakóddal, attól függően, hogy a küldés vagy a fogadás nem Verzió: v6.0 Dátum: oldal

18 GIRO Zrt. IG2 GYIK G66 - vol2: 441. oldalán (HU14 és HU37) Mi a különbség a két előfordulás között? Mikor kerül visszautasításra "csak" PSR-ben, és mikor érkezik CPSR HU14 ill. HU37 kódokkal? Mindkettőben találkozunk majd ezekkel a hibakódokkal ugyanarra a tételre vonatkozóan? A PNR értesítést megelőzően egy aktuális szakasz tervezett multilaterális nettó pozícióját az IG2 Monitoron kívül el lehet-e érni valamilyen automatizálható módon, hogy egy esetleges fedezetlenségi kockázatot még az elszámolási szakasz közben, automatikus riasztással lehessen észlelni, és idejében cselekedni. engedélyezett a tranzakcióban szereplő (az IBAN számla 5-7 pozícióján szereplő bankkódú) banknak. Ebben az esetben CPSR nem keletkezik a korlátozás miatt. Ha a tranzakció a fizetés-korlátozás IG2 általi tudomásul vétele előtt érkezik, akkor az IG2 a PSR-ben elfogadja, nem utasítja vissza a (akkor még hibátlan) tranzakciót és besorolja az elszámolandó tranzakciók közé. A fizetés-korlátozás érvényesítésekor az IG2 törli a tranzakciót az elszámolandók közül és erről a tényről a CPSR-ben tájékoztatja a beküldő bankot, indok: HU14 (küldő korlátozása), ill. HU37 (fogadó felfüggesztése). Ez az eset hasonló a visszahívás miatt törölt tranzakciók folyamatához: a PSR-ben az IG2 elfogadja, nem utasítja vissza a (hibátlan) tranzakciót, majd pedig a visszahívás teljesítéseként törli a tranzakciót az elszámolandók közül, és erről CPSR-ben tájékoztatja a beküldő bankot (indok: CUST). Összegezve: ugyanarra a tranzakcióra nem keletkezik PSR is és CPSR is HU14, ill. HU37 indokkall, azaz vagy csak PSR keletkezik HU14, ill. HU37 kóddal, vagy csak CPSR keletkezik HU14, illetve HU37 kóddal. Megjegyzendő, hogy a banki illetve MNB kérésre megvalósítandó új funkciók követelményspecifikációját (amely tartalmazta a fizetés-korlátozás esetén végrehajtandó teendőket is) július 28-án a GIRO megküldte a banki IG2 projekt kapcsolattartóknak A PNR kiadása előtt a multilaterális pozíció nem érhető el SZAKASZBEOSZTÁS S1. Miért nem lesz hajnali ciklus a július 2-i induláskor? Van-e lehetőség a 0. ciklus bevezetésére? S2. Mennyi idő telhet el az egyes szakaszokban a fedezetfoglalás és a VIBER számlán való elszámolás között. S3. Az utolsó szakaszban a treasury cselekvési idő mikor kezdődik és mikor ér véget? Az Országos Projekt PIB-döntése értelmében a hajnali ciklus (Early Morning) a július 2-i éles induláskor nem kerül bevezetésre. A rendszer moduláris felépítése miatt a későbbi bevezetés lehetősége ugyanakkor megmarad. Erre vonatkozóan csak becsléseink vannak, az utolsó szakaszt kivéve perccel számolunk, az utolsóban +25 perc ehhez hozzájön/hozzájöhet (a fedezeti összeg beszedésének sikerességétől függően). Az utolsó szakaszban a treasury cselekvési idő a GIRO általi előzetes értesítés (PreNotification Report) legyártásakor 16:30 és 16:55 között kezdődik, és maximum 17:30-ig tart. A bank a saját cut off-ja után a saját küldési forgalmát ismeri, aminek alapján már előzetes kalkulációt végezhet, amelyhez az előzetes értesítés ad többletinformációkat (ha a bank a fedezetbiztosítást GPO elven végzi, akkor erre nincs szükség) FEDEZETBIZTOSÍTÁS 14. oldal Dátum: Verzió: v6.0

19 IG2 GYIK F1. A majdani fedezetbe a zárolt értékpapírok is beleszámítanak? F2. Ha egy adott (napközbeni) ciklusban nincs elegendő fedezet, akkor az adott ciklusban beadott összes kimenő utalásunk nem fog teljesülni vagy a rendelkezésre álló VIBER egyenleg erejéig a GIRO teljesíti a kimenő utalásainkat? F3. Ha MNO+X összegű fedezetet szed be az IG2, de egy másik IG2 tag alulfedezettsége miatt X- nél nagyobb összegű befolyó pénz nem tud nekem teljesülni a klíringben, akkor mi történik? Tegyük fel, hogy a VIBER számlán lenne pótlólagos fedezet. Még ugyanabban a szakaszban beszedi a hiányzó fedezetet, vagy sorba állít a következő körre? GIRO Zrt. A fedezetbe kizárólag az MNB-nél vezetett VIBERszámláról lehívott összeg (nyitóegyenleg), és a fogadott átutalások összege számít bele. Zárolt értékpapír ellenében először a VIBER-ben kell likviditást szerezni, a GIRO számára a VIBER likviditás forrása közömbös. Amennyiben a bank a paraméter szerint biztosítandó fedezettel nem rendelkezik, akkor az elszámolás induló kerete 0. Az MNB ui. nem teszi lehetővé a VIBER-ben a részteljesítést. A bank által a GIRO-hoz elszámolásra benyújtott megbízások közül azok teljesülnek, amelyekre a jóváírandó megbízások fedezetet nyújtanak. Az IG2 kiadja a fedezetkérő üzeneteket. Ha egy banknak nincs elegendő fedezete a VIBER számláján, akkor a VIBER (és nem az IG2!) sorba állítja a fedezetlen megbízásokat. Ha az IG2 a várakozási időn belül (paraméter, értéke napközben 15 perc) nem kap rendben, a fedezet átutalva a GIRO számlára üzenetet a VIBER-től, akkor az IG2 visszavonja a fedezetlen megbízásokat. A nem teljesült és ezért az IG2 által visszavont fedezeti üzenetek bankjainak az adott szakaszbeli nyitóegyenlege 0 lesz, azaz átutalási tranzakcióit csak a fogadott jóváírások erejéig számolja el az IG2. Az elszámolatlan, fedezetetlen tranzakciókat az IG2 átgörgeti a következő szakaszra és ott kísérli majd meg az elszámolást. Az utolsó szakaszban fedezetlen megbízásokat az IG2 visszautasítja (CPSR fájlban). A bank által megadott paraméter alapján történő sikeres beszedés esetén pótlólagos fedezet bevonására semmilyen esetben sincs lehetőség Verzió: v6.0 Dátum: oldal

20 GIRO Zrt. IG2 GYIK SEPA/UNIFI ISO SZABVÁNYOK U1. Miért van szükség a SEPA-szabványok alkalmazására? U2. Lesz-e lehetőség arra, hogy a jelenleg előállított 002- es kötegből készüljön XML állomány? A pénzforgalom átfogó fejlesztésének két célja van. Az egyik az ügyfeleknek nyújtott szolgáltatások tartalmának javítása, a másik a megbízások teljesítésének gyorsítása. A SEPA-szabvány az euró fizetések szabványa a SEPA országokban, így Magyarországon is. Magyarországon a belföldi forint pénzforgalom fejlesztését nem célszerű ettől eltérő alapon végezni A GIRO nem tervez ilyen segítséget nyújtani. A bankoknak arra kell törekedni, hogy a banki rendszerekből régi típusú BKR szabvány szerinti, illetve UNIFI xml üzeneteket is elő tudjanak állítani. U3. Miért nem lehet egy az egyben az SCT stb. szabványokat alkalmazni? Az SCT-szabványokban kötelező mező az euró mint devizanem, ill. a SEPA mint "Service level". Ezeket az euró hazai bevezetéséig nem tudjuk alkalmazni, azonban az euró bevezetésével természetesen azonnal az SCT stb. szabványok kerülnek alkalmazásra, tekintettel arra, hogy a HCTszabványokban kizárólag azokat a kötelező mezőértékeket változtattuk meg, amelyeknek az eredeti értéke a hazai elszámolásforgalomban értelmezhetetlen. Továbbá a HCT szabvány tartalmazza a kódú tranzakciók kiegészítő mezőit is (bázisazonosító, jogcímkód, ügyfélazonosító) az SCT szabvány kötelező (End-To-End- Identification), ill. opcionális (Purpose, Ultimate Creditor) mezőben. U4. Mi az SDD lényege? SDD: SEPA Direct Debit, az euróövezeten belüli közvetlen beszedés szabványa. Debit tranzakció esetén - a küldő (jogosult) a jóváírandó fél kezdeményezi a beszedést (hasonlóan a csoportos beszedéshez), de hozzá kell benyújtani a felhatalmazásokat is, - a fogadó (kötelezett) a terhelendő félnek csak a beszedés vissza-utasítását kell közölnie az elszámolóházzal, a visszautasítás hiánya egyenértékű a beszedés teljesítésének jóváhagyásával. U5. A SEPA Rulebook (RB) és az ISO melyik változatával indulunk? U6. Mikor kerül bevezetésre Magyarországon az SDD (HDD)? U7. Jelenleg van olyan tag az üzenet struktúrákban (pl.... /LclInstrm/ Cd - EIS_2.1_II. pdf 20 oldal) amelynél nem látjuk, hogy Magyarországon belátható időn belül használatban lesz-e, mert van olyan alternatíva, amit inkább alkalmazhatunk (/LclInstrm/Prtry tag , ). Tervben van-e, hogy a használaton kívüli tag-ek felülbírálatra kerülnek, és országos szinten kimondásra kerül, hogy nem használjuk? Ha nem, akkor kérjük szépen az EIS-t kiegészíteni azokkal a "Standard ISO code"-okkal, amelyek itt előfordulhatnak. SEPA RB és IGL (Implementation Guidelines) 5.0 változatával, és a évi, tehát nem archív, ISO üzenetekkel. Az SDD (HDD) tranzakciótípus az InterGIRO2 első fázisában nem kerül kifejlesztésre, mert a nemcsak a szabvány, hanem a beszedés üzleti folyamatai is alapjaiban térnek el a jelenlegi hazai beszedéstől, erre a fizetési módra Magyarországon jelenleg nincs sem jogi, sem technikai gyakorlat. A bevezetés időpontja később kerül meghatározásra. A "Payment Initiation" szabvány véleményezése folyamatban van, meghatározza a használható adatelemeket, ami ezeken kívül esik, az értelemszerűen nem kerül továbbításra a bankközi térben sem). A GIRO viszont nem alkalmaz ilyen korlátozást. Az internal code-ok az xsd-ben találhatók, az external code-ok egy Excelben letölthetők a Javasoljuk forgassák a Payments Maintenance 2009 Message Definition Report dokumentumot is. 16. oldal Dátum: Verzió: v6.0