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

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

InterGIRO2 GYIK / FAQ v.6.0

1054 Budapest, Vadász utca 31.

Telefon: (1) 428-5600, (1) 269-2270 Fax: (1) 269-5458 ISO9001:2008

www.giro.hu

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

InterGIRO2 GYIK / FAQ v6.0

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 kérdések InterGIRO2 GYIK / FAQ v6.0 Oldalak száma: 33 © GIRO Zrt.

Budapest, 2011.11.17.

IG2 GYIK

GIRO Zrt.

Tartalomjegyzék 1.1.1.

Általános tájékoztató ................................................................................................ 2

1.1.2.

InterGIRO2 működése ............................................................................................. 3

1.1.3.

Szakaszbeosztás ................................................................................................... 14

1.1.4.

Fedezetbiztosítás ................................................................................................... 14

1.1.5.

SEPA/UNIFI ISO 200022 szabványok ................................................................... 16

1.1.6.

Egyéb .................................................................................................................... 26

1.1.7.

IG2 monitor (interaktív terminál) ............................................................................. 28

1.1.8.

EIS 2.3 kérdések nyomán javítandó, pontosítandó hibái ........................................ 28

Verzió: v6.0

Dátum: 2011. 11. 17.

1. oldal

GIRO Zrt.

IG2 GYIK

1.1.1. Á L TA L Á N O S T Á J É K O Z T A TÓ A klíringtagok által feltett kérdéseket és GIRO válaszokat 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 (www.giro.hu/ig2 1) és ahol lehet, megadjuk az EIS (Külső Interfész Specifikáció) hivatkozást. A banki kérdéseket 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-E7

2011-05-20

2.0

G44-G52, U7-U23, E8

2011-07-01

3.0

G53, U24-U33, E9, M1-M8,

2011-08-05

korábbi válaszok v3.0 kiegészítése számos ponton 4.0

G54-57, U34-U37

2011-09-01

korábbi válaszok 4.0 kiegészítése számos ponton 5.0

G58-64, U38-U47, E10

2011-09-30

korábbi válaszok 5.0 kiegészítése számos ponton 6.0

G65-66, U48-50

2011-11-17

W1-W9 korábbi válaszok 6.0 kiegészítése számos ponton A kérdéseket és válaszokat az alábbi módon osztályoztuk: G) InterGIRO2 működése S) Szakaszbeosztás F) Fedezetbiztosítás U) SEPA/UNIFI ISO 200022 szabványok E) Egyéb M) Monitor W) EIS 2.3 kérdések 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 2011. november 17-ig feltett kérdéseit és a válaszokat tartalmazza. 1

Az oldal jelszóvédett; amennyiben nem találja a belépési adatait, az [email protected] címen tudunk segítséget nyújtani!

2. oldal

Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt.

1.1.2. I N T E R GIRO2 M Ű K Ö D É S E

kérdés

válasz

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 1 – 9 999 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 9 999 tétel is.

v5.0 kiegészítés:

Egy ICF csak egyféle üzenettípust, 1 – 10 000 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 001-00 és a 007-01 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 007-01 kód szerepel. Bár a 001-00 kód is feltüntethető, de ez felesleges, mivel a „Local Instrument” mező hiánya egyenértékű a 001-00 kóddal.) Lásd EIS v2.1 I. kötet 3.2; 4.1.5; 4.1.7.2 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) ?

A „Local Instrument” mező kitöltése a SEPA szerint is és az IG2 szerint is választható. 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: 001-00, 007-01. Mivel a 001-00 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 001-00 é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 007-01 é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

v 4.0 kiegészítés:

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 (LclInstrm/Cd) az IG2-ben engedélyezett.

Verzió: v6.0

Dátum: 2011. 11. 17.

azon

belül

használata

3. oldal

GIRO Zrt.

IG2 GYIK

kérdés

válasz

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 (4.1.7.2 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 32- 128 (hexa 20 – 7E) közötti összes karaktert érti. Meg fogjuk kérdezni a fejlesztőt és a válasz szerint módosítjuk, kiegészítjük az EIS-t.


Ld. U8

Bázisazonosítóbeli összeállítási dátum kötelezően kisebb az érvényes elszámolási dátumnál?

Az EIS v2.1 I. kötetében a HCT kiegészítő ellenőrzés (4.1.3 fejezet, 3.1.2 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ő válasza után módosítjuk az EISt.


EIS v2.3 I. kötet 4.1.7.3, 3.1.2 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.002.001.03 (Payment Status Report? Igaz-e, hogy minden beküldött ICF (.I kiterjesztésű) file-ra kapunk válaszul 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.

G8.

4. oldal

Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt.

kérdés

válasz

G11.

A PSR köteg szintű? (Kötegenként történik a PSR visszaküldése?)

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.

G12.

Beküldése után honnan tudhatjuk, hogy a megbízás melyik ciklusba lett befogadva?

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.

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?

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)


Ld. EIS v2.3 vol I.: 4.5.1, EIS v2.3 vol II. 3.2, 3.3

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?

Függőben lévő kérdés, a szállítótól vár választ 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. 5.4.8 pont. A tervezet a www.giro.hu/ig2 oldalon található meg.

G15.

A dokumentum szerint a SCF tartalmazhat átutalást vagy visszahívást, vagy visszautasítást. Recall NACK-ot nem?

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.

G16.

SCF file-ban van szakaszazonosító (hányadik szakasz)?

Nincs


Igen. A fejlesztő megvalósította.


Ld. EIS v2.3 vol. I. 4.1.2

G13.

G14.

G17.

Lehet-e tranzakció rekonsziliálni?

szinten

szakaszonként

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: 2011. 11. 17.

5. oldal

GIRO Zrt.

IG2 GYIK

kérdés

válasz

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?

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).


Ld. EIS v2.3

Utolsó ciklusba való beküldésnél honnan lehet tudni, hogy már nem került befogadásra a file?

PSR TM01 hibakóddal jelzi a késői küldés miatti visszautasítást. Ld. EIS v2.1 I. kötet 4.1.5 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

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.)

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

G21.

A visszahívás kérések (camt.056) nem a többi fogadó köteggel kerülnek-e kiküldésre az IG2ből a DP-k részére?

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


EIS 4.1.5 pont alatt található (v2.3 magyar változatban a 40. oldalon)

G18.

G19.

G23.

A Recall funkció csak tranzakció-, csoportszinten (is) értelmezhető lesz-e?

vagy

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 4.1.5 fejezet: „Néhány megjegyzés a visszahívásokkal (Recall) kapcsolatban”

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)?

Igen, a Recall (camt.056) visszautasítása a Recall NAK (camt.029), teljesítése pedig visszautalással (pacs.004) történik.

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)?

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: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt.

kérdés

válasz 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 a szereplő visszahívásokat továbbította kedvezményezett bankjának.


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.

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?

A GIRO oldal szabályozott lesz (erre a célra szolgáló üzenet, várhatóan 45+45 naptári nap a visszahívásra, illetve az arra adandó válaszra). Az ügyfél oldal az IG1ben 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. 4.1.5 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 választ (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.

G28.

Mi számít múltbeli visszahívásnak, a már elszámolt AZNAPI is?

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.

G29.

Hogyan kell hivatkozni az egyedi azonosítókra visszautalás, visszahívás esetén?

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)

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?

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.

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?

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

G27.

Verzió: v6.0

Dátum: 2011. 11. 17.

7. oldal

GIRO Zrt.

IG2 GYIK

kérdés

válasz lehet kezdeményezni.


További monitor (M) kérdések 1.1.7 alatt

G32.

Honnan tudhatjuk, hogy az utolsó szakaszban fedezethiány miatt mely tételeket utasította vissza a rendszer?

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 4.1.2 fejezetben.

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?

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 választ csak a tesztelés után tudunk adni.

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?

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 választ csak a tesztelés után tudunk adni.

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 10 000 törölt tétel van, akkor több file is lehet?

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. 10 000 tételt tartalmazhat.

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 10 000 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?

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.

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?

Igen, az aláírás és a fájltovábbítás a 2011. április 4-től kizárólagossá vált STP-elvek alapján zajlik majd (GIROHáló GIROFile adattovábbítási mód).

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?

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.

G39.

A FIFO-t adott szakaszban csomagra, vagy csomagon belül értendő? Ha nincs részteljesítés, akkor hogyan alkalmazható, értelmezhető a FIFO?

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: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt.

kérdés

válasz 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 2.- 25., é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 -ra ugyanez a megfogalmazás igaz. A Max35Text pedig String mely min. 1, max. 35 karakter és nem lehet csupa szóköz. A 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.

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 3.1.2 pont).

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.

1. az xsd hivatkozott mezője tartalmazza a 35 karakteres korlá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.”

G43.

G44.

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 1..1”-gyel jelölt tag-ek)

Igen, a 140 karakterbe beszámít minden < kezdő > és 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

Lesz-e értesítés, ha valamelyik banktól nem sikerült beszedni a szükséges fedezetet az utolsó ciklusban?

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.


Ld. EIS v2.3 vol I., 4.2.3 E) Az IG2 – a 2012. júliusi induláskor – a BMCS döntése szerint csak a 001-00 és a 007-01 tranzakciókódot fogadja el. A 001-00 tranzakcióköd használata nem kötelező. A 007-01 tranzakciókód esetén az IG2 – az alapvető

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 -

Verzió: v6.0

Dátum: 2011. 11. 17.

9. oldal

GIRO Zrt.

IG2 GYIK

kérdés segítené a tranzakciók típusának azonosítását

A Local Instrument mező alatti két ’tag’ és közül , melyik esetben melyik töltendő?

G45.

v 3.0 kiegészítés: v 4.0 kiegészítés: Visszahívásra választ 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ó?

G46.

G47.

G48.

2


Visszaigazolás megtörtént


EIS 2.3 tartalmazza, de az IG2 2011-ben még nem így működik

Elsősorban az a kérdés 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)?

A BMCS döntés szerint a visszahívás 45+45 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 válasz) 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 válasznak az előzmény-párja az eredeti átutalás, pacs.008.) szintén 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 válaszainak (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 IG2 2011-ben még nem így működik Igen, ld. EIS v2.3 I. kötet 9. Melléklet (ANNEX 9)

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

2

válasz 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 mezőben szerepeltetni kell a 007-01 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 nem használható. Lásd a G5 kérdés 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 válaszainak (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.

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

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: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt.

kérdés jól sejtem-e hogy az alábbi új tranzakció klíring üzenet? SttlmMtd>CLRG

válasz 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 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

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?

G51.

Miért nincs az EOD riportnak külön - üzenetazonosítója (<MsgId>) - létrehozási dátuma () - elszámolási dátuma () - kire vonatkozik () 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!!!). v 3.0 kiegészítés:

G52.

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. 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 2010. december óta ismert.)


Szállító kiegészíti a napvégi jelentést az igényelt kellékekkel. Ld. EIS v2.3 vol. II., 5.13

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: 2011. 11. 17.

11. oldal

GIRO Zrt.

IG2 GYIK

kérdés

válasz

a specifikációk kialakításához, ill. ellenőrzéshez? 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).

G53.

BMCS kérdés 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 válasz szerint a tesztelés megkezdése előtt a V-BIC mező feltöltésre kerül. Ezzel kapcsolatban lenne pontosító kérdésü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?

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 2012. é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?

Igen.

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?

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

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ó?

A fejlesztő 2011. 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.

G59

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.

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,

G60

A visszahívás és visszahívás negatív válasza ü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 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

A pacs.004 üzenettel már visszautasított átutalások ismételt visszautasítására nincs lehetőség. Lásd az EIS v2.2. 5.2 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

Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt.

kérdés

válasz

GHUNHUHBGIR, vagy GHUNHUHB Kérem adják meg a helyes értéket! Mennyire tekinthető állandónak ez az érték?

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.004 + 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 választranzakció (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 válaszaikat (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 válaszokat az IG2 - banki kérésre - a jövőben csak önmagukban vizsgálja, tehát egy visszahívásra adott több választ 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ő kérdésre adott választ 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.

G61

Mit kell beírni a CS-DETSTA üzenet T427 és T428 mezőjében IG2 esetén? mezőjében

G62

Amennyiben a Bank hibás tételt küld, a GIRO-tól milyen válaszüzenet érkezik? Pl. ha egy recall üzenetet ugyanarra a tételre többször küld, vagy egy recall üzenetre többször válaszol?

G63

Milyen üzenettel válaszol 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?

G64

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, -

G65

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 5-12. 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)

Verzió: v6.0

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

Dátum: 2011. 11. 17.

13. oldal

GIRO Zrt.

IG2 GYIK

kérdés - 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?

G66

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.

válasz 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) 2011. 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.

1.1.3. S Z A K A S Z B E O S Z T Á S kérdés

válasz

S1.

Miért nem lesz hajnali ciklus a 2012. július 2-i induláskor? Van-e lehetőség a 0. ciklus bevezetésére?

Az Országos Projekt PIB-döntése értelmében a hajnali ciklus (Early Morning) a 2012. 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.

S2.

Mennyi idő telhet el az egyes szakaszokban a fedezetfoglalás és a VIBER számlán való elszámolás között.

Erre vonatkozóan csak becsléseink vannak, az utolsó szakaszt kivéve 30-50 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).

S3.

Az utolsó szakaszban a treasury cselekvési idő mikor kezdődik és mikor ér véget?

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).

1.1.4. F E D E Z E T B I Z T O S Í T Á S

14. oldal

Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt. kérdés

válasz

F1.

A majdani fedezetbe a zárolt értékpapírok is beleszámítanak?

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.

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?

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).

F3.

Ha MNO+X összegű fedezetet szed be az IG2, de egy másik IG2 tag alulfedezettsége miatt Xné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?

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: 2011. 11. 17.

15. oldal

GIRO Zrt.

IG2 GYIK

1.1.5. SEPA/UNIFI ISO 200022 S Z A B V Á N Y O K kérdés

válasz

U1.

Miért van szükség alkalmazására?

SEPA-szabványok

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

U2.

Lesz-e lehetőség arra, hogy a jelenleg előállított 002es kötegből készüljön XML állomány?

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 007-01 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-EndIdentification), 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 20022 melyik változatával indulunk?

SEPA RB és IGL (Implementation Guidelines) 5.0 változatával, és a 2009. évi, tehát nem archív, ISO 20022 üzenetekkel.

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 007-01, 001-00). 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.

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.

16. oldal

a

Az internal code-ok az xsd-ben találhatók, az external code-ok egy Excelben letölthetők a www.iso20022.org-ról. Javasoljuk forgassák a Payments Maintenance 2009 Message Definition Report dokumentumot is.

Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt.

kérdés

válasz


Felülvizsgált szöveg: A "Payment Initiation" szabvány HCT alkalmazási útmutatóját az MSE Tanácsa elfogadta, és tervezetként közzétette a www.sepahungary.hu meghatározza a használható oldalon (ez adatelemeket, ami ezeken kívül esik, az értelemszerűen nem továbbítandó a bankközi térben sem). Ez az alkalmazási útmutató nem korlátozza a LclInstrm / Cd használatát. Az EIS-t nem tervezzük minden ISO kóddal kiegészíteni. Az ISO 20022 belső kódok az xsdékben, és a „Payments - Maintenance 2009”, valamint az „Exceptions and Investigations - Maintenance 2009 Message Definition Report”-okban találhatók. A külső kódok egy Excelben letölthetők a www.iso20022.orgról. Javasoljuk, forgassák a felsorolt dokumentumokat is. A HCT elfogadott ügyfélátutalás szabványa megtalálható a www.giro.hu honlapon. A szabvány magyar nyelvű fordítása 2011. decemberben készülhet el.


U8.

Milyen karakterek használhatók az IG2-ben?

Az alfanumerikus mezők tartalmazhatnak az ASCII 32-128 számtartományon és az ASCII 128-256 engedélyezett részén** belüli" karaktereket. (** = "a magyar ékezetes karakterek az ISO 8859-2 szabvány szerint a bank és BKR közötti klíring szabványoknál, egyébként a 852 szabvány szerint")


v5.0 kiegészítés: U9.

U10.

U11.

Hol vannak leírva a szabványos ISO kódok

Ld.: G7 EIS leírás másképp: A tranzakciókban az UTF8 alapkészlet és az ékezetes magyar karakterek használhatók. Az UTF-8 alapkészlet minden karaktert tartalmaz a 20-126 (hex 32-7E) tartományból. Az ékezetes magyar magánhangzók UTF-8 kódja megegyezik az ISO 8859-2 (IG1 és a klíringtagok között használatos) megfelelő kódjaival. Az ékezetes magyar magánhangzók UTF-8 kódját az EIS v2.3 II. kötete tartalmazza. UNIFI ISO20022 Payment External Code List-ben. Letölthető az ISO20022 honlapjáról


Felülvizsgált szöveg: Kétféle szabványos UNIFI ISO20022 kód létezik. A belső kódok megtalálhatók az xsd fájlokban, illetve ’Payments Maintenance 2009 Message Definition Report’ az üzenetek leírásánál ezeket felsorolja. A külső kódok az UNIFI ISO20022 Payment External Code List-ben találhatók. Ezek egy az ISO20022 honlapról letölthető Excel fájlban találhatók meg.

CtgyPurp A elméletileg 4 hosszú kódot tartalmazhat, van-e ennek kódtáblája?

Lásd UNIFI ISO20022 Payment External Code List. (A HCT nem használja a CtgyPurp mezőt.) A SEPA-val való összhang miatt az IG2 megengedi a SEPA összes opcionális mezőjének használatát is.


A ’Category Purpose’ feldolgozási instrukció az átutaló, vagy a kedvezményezett bankjának. A kedvezményezett banknak az átutaló bankja akkor továbbítja ezt az adatot, ha ügyfele kéri, a kedvezményezettet azonban nem kell tájékoztatni az SCT szabályzata szerint. CtgyPurp használatáról a hazai bankok között nincs megegyezés. Az InstgAgt az input fájlt (ICF) küldő DP azonosítója, az InstdAgt az output fájlt (SCF) fogadó DP

Van-e bármilyen különbség a DbtrAgt-InstgAgt illetve CdtrAgt-InstdAgt párosok között?

Verzió: v6.0

Dátum: 2011. 11. 17.

17. oldal

GIRO Zrt.

IG2 GYIK

kérdés

válasz azonosítója. A DbtrAgt az átutalást kezdeményező bank azonosítója (amely vagy azonos az InstgAgt-tel, vagy annak levelezettje.)

U12.

Az xsd-ben az OrgnlTxRef kötelező (minOcc = 1), de egyik alábontása sem kötelező.

A CdtrAgt az átutalás kedvezményezett bankjának az azonosítója (vagy azonos az InstdAgt-tel, vagy annak levelezettje.) Az EIS v2.2 II kötetében a felettes TxInf szint is kötelező, az alatta lévő OrgnlTxRef is kötelező, az OrgnlTxRef alatti mezők némelyike kötelező, némelyike pedig opcionális.


pacs.004.001.02 üzenetről van szó Az EIS és XSD közötti eltérések (hibák) javítása folyamatosan történik. Kérjük ebben az esetben az EIS-t tekintsék irányadónak.

U13.

PACS 002.001.03. ezt a fájl formátumot csak a Giro állítja elő. Legalább ezt nem tudnák xsd szinten konkretizálni, hogy melyik mezőket töltik (pl. az Orgtr tagból gondolom csak a BICOrBEI tag van ténylegesen használatban) illetve, hogy ne legyen benne 0.n-es előfordulás (ld. )?

Az IG2 általi visszautasításokat tartalmazó pacs.002 szabványos SEPA formátumú. A SEPA csak a visszautasításra szabályozza a pacs.002-t. Csak a visszautasításról tájékoztató pacs.002-ben van . Az elfogadott ICF visszaigazolásaként gyártott pacs.002 GIRO (banki) kérés volt. Ebben nincs (nem lehet) , ezért 0.n az előfordulási gyakorisága.

U14.

pacs.004 esetén van-e összeg ellenőrzés GIRO oldalon?

Banki visszautasítás esetén az IG2 minden mező értékét összeveti az eredeti átutalás megfelelő mezőinek értékével. Visszahívás teljesítésére indított visszautalás esetén az IG2 – a BMCS kérése szerint – nem párosítja az eredeti átutalás mezőit a visszautaláséival. 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

v 3.0 kiegészítés: v 6.0 kiegészítés: U15.

A camt.029 és camt.056 típusú file-okkal kapcsolatban az alábbi kérdéseink merültek fel: 1. camt.029 file-ban CxlDtls.TxInfAndSts.CxlStsRsnInf előfordulási maximumaként "n" van megadva. Ez azt jelenti, hogy tranzakciónként több visszahívást visszautasító indok és originator adható meg? v 4.0 kiegészítés:


U16.

camt.029-ben található Cancellation Details (CxlDtls) és az alatt a Transaction Information And Status (TxInfAndSts) tag-ek előfordulási maximuma szintén "n". Ezt jól értelmezzük-e úgy, hogy a CxlDtls 1-1 megfeleltetésben van a TxInfAndSts-el, azaz minden egyes tranzakciónál külön CxlDtls tag-et kell nyitni, és azon belül csak egy TxInfAndSts fordulhat elő? (Másik értelmezés, hogy csak egy CxlDtls tag-et nyitunk, és azon belül több tranzakció lehet; esetleg több CxlDtls tag nyitása, és mindegyiken belül több TxInfAndSts).

18. oldal

EIS v2.3 tartalmazza, de a rendszer csak 2012 elején fog átállni. Egy tranzakció összegét visszakérő igény visszautasítása több indokkal is jelölhető, Pl. az egyik indok CUST (a Code mezőben), a másik indok pedig NOOR (a Proprietary mezőben). Mindkét esetben ugyanaz a visszautasító fél, azaz az ügyfél (az Originator alatti Name mezőben). Amennyiben a visszautasítás oka „LEGL” és a magyarázat nem fér el 210 karakteren (az mezőben), akkor szükség lehet a CxlStsRsnInf mező 1-nél több használatára. Bár az EIS – az SCT IGL v5.0-val összhangban megenged egynél többszöri előfordulást is, a gyakorlatban egyetlen CxlStsRsnInf mezőt kell használni. Mindkét megoldás elfogadható, azaz 1. 1:1 megfeleltetés a Cancellation Details (CxlDtls) és az alatt a Transaction Information And Status (TxInfAndSts) között, tehát minden egyes Cancellation Details (CxlDtls) alatt egyetlen Transaction Information And Status (TxInfAndSts) van, 2. 1:n megfeleltetés a Cancellation Details (CxlDtls) és az alatt a Transaction Information And Status (TxInfAndSts) között, tehát egy Cancellation

Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt.

kérdés

válasz Details (CxlDtls) alatt több Transaction Information And Status (TxInfAndSts) van.

U17.

U18.

U19.


Nem kötelező minden tranzakciónak külön CxlDtls címkét nyitni. A gyakorlatban tehát mindkét értelmezés alkalmazható

Nem világos, hogy az átutaló címe miért akkora. 1.2. átutaló címe / AT-03 CdtTrfTxInf / Dbtr / PstlAdr / AdrLine (2*70 karakter)

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.2 az SCT IGL v5.0 -val összhangban 2*70 karakterre korlátozta a cím maximális méretét.

Az iso20022 szabványban megtaláltam az AdrLine mező típust, de ami oda le van írva, az szerint 7*70 karakter lehetne, vagy valamit félre értelmezek? 9.1.11 AddressLine Presence: [0..7] Definition: Information that locates and identifies a specific address, as defined by postal services, presented in free format text. Data Type: Max70Text Format: maxLength: 70 Mire, hogyan kell használni a Returned Instructed Amount mezőt), amiről csak annyi derül ki, hogy visszahívás esetén lehet használni. A Payment_Maintenance_2009.pdf alapján ez az összeg mező a díj levonását megelőző összeget tartalmazza. (ez nem az eredeti összeg??? - original interbank settlement amount) Jól gondoljuk-e, hogy ez szolgálna a konverziós tételek visszautalására (visszahívás esetén)? - Ha igen, hogyan kell értelmeznünk? (Konverzió esetén az eredeti összeg és a visszautalt összeg között nem feltétlenül csak a díj lesz a különbség!) - Ha nem, akkor ez a mező mire való? v 3.0 kiegészítés:

Abban az esetben, ha a kedvezményezett számlájára lekönyvelődött az összeg, az ő beleegyezése szükséges ahhoz, hogy a számláját a bank beterhelje. Létezik-e olyan variáció, hogy az ügyfél arról nyilatkozik bankjánál (írásban, kvázi egy nyilatkozatban), hogy majd ő maga visszautalja a pénzt az indító fél részére? Ilyen esetben a bank küld egy negatív választ (camt 029) az indító banknak és a közleménybe beírja, hogy az ügyfél maga indítja az utalást és innentől kezdve a bank részéről nincs felelősség? Ha van ilyen alternatíva, akkor ezt kötelező csinálni a bankoknak? Vagy csak kétféle megoldás van?: 1) pozitív válasz és a pénz visszautalása (pacs004) vagy 2) negatív válasz/kérés visszautasítása (camt029)??? v 3.0 kiegészítés:

Verzió: v6.0

Ennek a mezőnek az értelmezése a bankok hatáskörébe esik. Továbbítjuk a kérdést a BMCS felé.

BMCS álláspont: Az üzenet az alábbi összegeket tartalmazza: ’Original Interbank Settlement Amount’, ’Returned Interbank Settlement Amount’, ’Charges Information/+Amount’, valamint az 5.0-ás SEPA változatban: ’Returned Instructed Amount’. Az ’Original Interbank Settlement Amount’ a ’Returned Interbank Settlement Amount’, és ’Charges Information/+Amount’ összege. Ezektől független a díjlevonás esetén kötelező ’Returned Instructed Amount’, aminek jelentése: visszafizetésre kerülő összeg a kedvezményezett bankját illető díj levonása előtt. Ez lehet nem forint összeg, illetve kevesebb lehet az eredeti átutalás összegénél, ha a bank a jóváírás után is díjat számított fel. A kérdés megvitatása, megválaszolása banki hatáskörbe esik. BMCS ülésen kell megvitatni. A szabvány szerint csak a kérdező által is említett kétféle megoldás van. 1) pozitív válasz és a pénz visszautalása (pacs004) vagy 2) negatív válasz/kérés visszautasítása (camt029)

BMCS álláspont: A bank lehetőleg ne fogadjon el visszautalási

Dátum: 2011. 11. 17.

19. oldal

GIRO Zrt.

IG2 GYIK

kérdés

válasz nyilatkozatot, illetve zárkózzon el visszautalásra való hivatkozás továbbításától, mert nem szavatolható, hogy az ügyfél teljesíti az átutalást. A bankon esetleg számon kérhető, miért nem szólította fel ügyfelét visszautalásra, illetve miért nem tartotta számon ezt a kötelezettségét. A bankok lehetőleg szorítkozzanak az egyszerű negatív és pozitív válaszok továbbítására.

U20.

Ua., mint U15

U21.

Ua., mint U16

U22.

Üres

U23.

Az EndToEndId-ra vonatkozóan az xsd-ben csak a hossz és a kötelezőségre való ellenőrzés szerepel, a formátumra vonatkozó nem (az EIS_I_2.2.pdf tartalmazza ugyan az ellenőrzést, de ezt hiányoljuk az xsd-ből.)

Az xsd elsősorban a SEPA előírások (SCT Rulebook és SCT Implementation Guidelines) szerinti megkötéseket tartalmazza. A magyar sajátosságok ellenőrzését (pl. bázisazonosító az EndToEndId mezőben) az IG2 programkódja tartalmazza.


Az EndToEndId mező ellenőrzését 007-01 kódú csoportos átutalás esetén az IG2 programkódja tartalmazza.

U24.

+CdtTrfTxInf / ++PmtTpInf / +++CtgyPurp, illetve +CdtTrfTxInf / ++Purp mezőkben lehet jogcímkódot megadni? Mi a különbség a két mező (csoport) között? Jogcímkódot csak csoportos átutalás esetében lehet megadni, vagy tetszőleges utalásnál? Jól gondoljuk, hogy a kódot nem a Code, hanem a Prtry tag-ben szükséges megadni?

A CtgyPurp feldolgozási instrukció, ami szólhat az átutaló, illetve a kedvezményezett bankjának is. A Purp kód a kedvezményezettnek adott információ, ami segíti a megbízás és a fizetés jogcímének azonosítását. Jogcímkódot nem kötelező megadni, kivéve akkor, ha csoportos átutalást küld a bank. Ekkor a csoportos jogcímkódot kell megadni ’Prtry’ címkével. A Code mezőben mindig csak ISO20022 jogcímkód adható meg. A szabványos ISO20022 jogcímkódokat a www.iso20022.org alatt található "Payment External Code List" tartalmazza, ami egy Excel fájl. A csoportos jogcímkódok a Prprty alatt szerepelhetnek.

U25.

Az AT-44 mező definíciója ellentmondásos az EIS első és második kötete között. A pain üzenetben csak a 4 hosszú „code” elemet kell megadni, a pacs üzenetben már „code” vagy „proprietary” szerepel, utóbbi 35 karakteren (eredetileg csak a 4 hosszú „code” mezőről volt szó). Ellentmondás továbbá a két kötetben, hogy az első kötet szerint mindkét mező opcionális, míg a második kötet szerint mindkét mező kötelező (illetve a proprietary-hoz is az van írva, hogy kötelező, de „00701 esetén nem lehet üres és érvényes GMDB-ben szereplő kódnak kell lennie. Kérem, szíveskedjenek a mező attribútumainak pontos értelmezését megadni.

Az EIS v2.2 I. és II. kötete között a jogcímkódot illetően nincs ellentmondás, de szükség van további pontosításra. A purpose code / jogcímkód mező az EIS-ben a következőképpen szerepel: - I. kötet 14-15 oldalon opcionálisként jelöli, de a leírás utal a csoportos átutalásra, melynek esetében kötelező használni, értéke az IG2-GMDB-ben szereplő "saját" (proprietary) jogcímkód lehet. Ezt megerősíti a 38. oldalon a (4.1.7.3 alatti) 3.1.3 pont, és a 68. oldalon található táblázat 3.2 sora, - II. kötet 54. és 55. oldala szerint opcionális, de kiválasztása esetén kötelezően vagy szabványos, vagy saját kód, csoportos átutalásnál kötelezően saját (proprietary) kód. Az EIS II. kötetének következő kiadásában s a mezőt O/M-ként fogjuk jelölni, tehát a jogcímkód csoportos átutalás esetén kötelező, egyébként opcionális. Az pain üzenetben (C2B szabványalkalmazási útmutatóban) azért nem szerepel a jogcímkód sajátos („proprietary”) értéke, mert a C2B munkabizottság megállapodott abban, hogy a csoportos átutalásokat továbbra is CSÁT.121 formátumban fogadják be a bankok (és nem a pain üzenet szerint), ezért a pain üzenetben nincs szükség a saját jogcímkód használatára.

20. oldal

Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

U26.

GIRO Zrt.

kérdés

válasz

A strukturált közleménnyel kapcsolatban a 140 karakteres korlátozás (tag-ekkel együtt) hogyan értelmezendő?

A strukturált közleményre is vonatkozó 140 karakteres korlátozás az átutalás felvételekor igaz, az átutaló bankja ennek megfelelően limitálja a kitölthető rovatok hosszát, ami jóval kevesebb 140 karakternél. Fogadó oldalon nincs szabály, a kivonat szabványt (egyelőre) nem implementáltuk.

1. Az <Strd> közötti, white space nélküli szövegtartalomra, beleértve a belső tag-eket? 2. Rendszerben ezt a „kompaktabb” nézetet kell tárolni (benne a többi taggel)?

ad 1. <Strd> közötti szöveg belső címkékkel (tag) együtt lehet 140 karakter (ebbe a szóközök is beleszámítanak, mivel a szóköz is érvényes karakter).

3. Ha igen, akkor hasonlóan kellhet a kivonaton megjeleníteni (amennyiben a megjelenítés mellett dönt a bank), valamint elektronikusan is „tag”-elve kell elérhetővé tenni, hogy a kedvezményezett felhasználhassa?

ad 2. Az adatok tárolásának módjáról minden bank saját hatáskörében dönt. Az xml formában történő tárolás – ha erre van lehetőség – hosszútávon ideális megoldás. ad 3. A pénzforgalmi jogszabályok szerint a közlemény tartalmát kell továbbítani, ebbe a címkék nem számítanak.

U27.

A küldő file-ok összegmezője xsd szerint 18 karakter lehet. - EIS 2.2_I szerint 14 fillér nélkül ill. fillér alkalmazásakor 12 karakter az egészrész, 2 karakter a fillér. (AT-04 -> 13. oldal a korrektúrás változatban) - az EIS 2.2._II korrektúrás változatának 14. oldalán utalás van a VIBER miatti karakterkorlátra az összeg esetében.

Bár az xsd - az UNIFI-vel összhangban - megengedi a 18 karakteres összeget, a VIBER üzenetek (fedezetbeszedés, záróegyenlegek átutalása) 15 karakteres korlátja miatt a bankonkénti teljes összeg, a tranzakciók összege minden szakaszban csak 14 karakternyi HUF lehet (fillér nélkül).

A fentiek alapján melyik karakterkorlátot célszerű figyelembe vennünk az összeg mezők esetében? (Interbank Settlement Amount, Total Interbank Settlement Amount, stb.) U28.

U29.

Visszahívás tranzakcióknál milyen ellenőrzést végez majd az IG2 rendszer - az xsd ellenőrzésen kívül -, amikor az 5 napos visszahívási korlát nem lesz benne?

A séma-ellenőrzésen kívül: a címzett meglétét és időkorlát betartását ellenőrzi a rendszer. Részletes leírást ld.: IG2_feature_requests_v1.0_forBMCS.doc


Ld.: EIS v2.3 vol I., 4.1.5 EIS v2.3 vol II. 2.1 5) Ld.: W2 Az EIS II. kötetének 2.2 utáni verziója a jelenlegi 6. fejezeten (Reject / Return Reason Codes as in ISO20022) kívül - önállóan is tartalmazni fogja a használható okokat, kódokat (reason codes) fizetési típusok szerint: banki visszautasítás, visszautalás (pacs.004), visszahívás (camt.056), visszahívás visszautasítása (camt.029). Ld: IG2_feature_requests_v1.0_forBMCS.doc, amiben ez a táblázat már szerepel

Készül-e, (ha igen, mikorra várható) olyan összefoglaló táblázat a visszautasítás kódokra vonatkozóan, ami azt is megmutatja, hogy mely kódokat alkalmazhatja az IG2 rendszer, melyeket a Bankok rendszerei, illetve mely file típusok esetében melyik értelmezhető?


U30.

pacs.008: Debtor Account / Currency: Erre vonatkozóan van bármilyen – a formain túli – ellenőrzés, vagy csak automatikusan továbbítódik? Jól gondoljuk, hogy pl. konverziós tétel esetében ez lehet HUF-tól eltérő?

Verzió: v6.0

Ld.: EIS v2.3 vol II. 7 Error Codes (IG2), 8 Reason Codes (Klíringtagok) A Debtor Account / Currency mező az EIS pacs.008ban nem szerepel a Currency mező, tehát nem is lehet kitölteni. A Currency mező az ISO 20022 globális szabvány része, és abban az esetben használható, ha a címzett számlaszám mögött több devizanemben vannak számlák, és az átutaló megjelöli a jóváírás

Dátum: 2011. 11. 17.

21. oldal

GIRO Zrt.

IG2 GYIK

kérdés

válasz devizanemét.

U31.

pacs.008: InstructionIdentification: melyik szereplője adhatja meg?

A

tranzakció

Az InstructionIdentification (InstrId) választható mező célja a megbízás két hitelintézet közötti azonosítása, szemben az TxId-vel, ami a teljes banki fizetési láncban állandó. Az IG2 az ICF-ben szereplő InstrId-t az SCF-ben változtatás nélkül továbbítja, de a fogadó banknak nem kell ugyanezt megtennie, ha egy közvetett résztvevő felé továbbítja a megbízást. Ez a bank az általa készített SCF-ben saját InstrId-ját is feltüntetheti. A mező bankközi viszonyban hivatkozásként történő használata bankközi megegyezést igényel, ami nélkül a küldő csak saját céljára használhatja a mezőt.


2.3 TxId azonos az AT43-al, az átutaló bankjának műveleti hivatkozásával.

U32.

Generálhat-e a küldő Bank az ügyfél helyett NOTPROVIDED-től eltérő automatikus end-to-end azonosítót, ha azt az ügyfél nem hagyja jóvá? (Pl. ha egyes befogadási csatornákon nem kívánja a jelenlegi felületeit módosítani.)

Célszerű a bank gyakorlatát úgy kialakítani, hogy a befogadáskor lehetővé tegye az end-to-end ID megadását. Ha erre a bank átmenetileg nem képes, a javasolt megoldás is segít. A bank azonban akkor jár el helyesen, ha az átutaló számlakivonatán szerepelteti a terhelt átutalások end-to-end ID-ját, annak érdekében, hogy az esetleges vitarendezés során ügyfele birtokában legyen a tételazonosítónak.

U33.

Megfelelően jár-e el a fogadó Bank, ha az end-to-end azonosító NOTPROVIDED értéke esetén úgy tekinti, hogy a kezdeményező ügyfél nem adott át erre vonatkozó információt, így pl. a kivonaton sem szerepelteti azt? (Tudjuk, hogy a kivonaton megjelenítendő adatok témájában az MNB nem kíván specifikusan állást foglalni.) Vagy – mivel az ügyfél szándékosan is adhat meg NOTPROVIDED értéket azonosítóként – ezt mindenképp továbbítani szükséges? Ha a bankok többsége NOTPROVIDED értékkel továbbítja a megbízásokat, amennyiben az ügyfél nem ad meg ilyet, viszont ezeket minden esetben feltüntetjük a kivonaton is, akkor ez az ügyfelek számára nehezen értelmezhető lehet, illetve a gyakorlatban szinte sosem hordoz információt.

Az MNB azért nem ad (nem adhat) állásfoglalást a kérdésben, mert a keretszerződés alapján történő utólagos tájékoztatást a pénzforgalmi szolgáltatás nyújtásáról szóló 2009. évi 85. törvény szabályozza. A törvényalkotói szándék értelmezésére a jogszabályt előkészítő NGM jogosult (mivel a szabály EU irányelvből származik, az NGM az EU Bizottság értelmezését tekinti irányadónak). Az EU Bizottság a PSD (2007/64/EU irányelv) vonatkozó 48. cikk 1. szakaszát eddig még nem értelmezte. A Pft. előírásainak betartását a PSZÁF ellenőrizheti. Kérdésükre tehát az EU Bizottság, az NGM és a PSZÁF adhatnak autentikus választ. A ’NOTPROVIDED’ betűsor önmagában tartalmatlan, az viszont közölhető, hogy az átutaló nem adott egyedi megbízásazonosítót.

U34.

Használható-e a cím mező, ill. melyik használható és mikor?

Az átutalást kezdeményező bank az IG2-ben feldolgozandó megbízáson a címmezőket (AT-03, AT22) a saját előírásai szerint tölti, vagy nem tölti ki.

U35.

pacs.008 tranzakciók a következő 3 tag (címke) alapján egyediek: TxId, elszámolási dátum, Debtor Agent. camt.056, camt.029, pacs.004 tranzakciók esetén az eredeti tranzakció visszakereséséhez a fentiek közül csak az eredeti tranzakcióra vonatkozó TxId és az elszámolási dátum kitöltése kötelező, a Debtor Agent nem. Hogyan biztosítható így az eredeti tranzakció azonosítása?

A válaszoló, a camt.056, camt.029, pacs.004 tranzakciókat indító bank felelőssége, hogy kitöltse az eredeti átutalást (pacs.008) kezdeményező, a választranzakció fogadóját azonosító Debtor Agent mezőt.

22. oldal

Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

U36.

GIRO Zrt.

kérdés pacs.004 tranzakció esetén az AddtlInf tag töltése az EIS v2.2 II. kötete szerint opcionális. Ezzel szemben az I. kötetben 1-ben található, ide vonatkozó definíció alapján (AT-R7), a mezőt pacs.004 / ACK üzenet esetén kötelező tölteni a fogadott camt.056 üzenet CxlId azonosítójával. pacs.004/ACK üzenet esetén kötelező-e tölteni az tag-et camt.056 / CxlId mező tartalmával? Ellenőrzi-e az IG2 az mező kitöltöttségét?

U37.

CPSR pacs.002 file-ban a kezdeményező a GIRO azonosítót tartalmazza a TxInfAndSts\StsRsnInf\Orgtr\Id\OrgID\, illetve a StsRsnInf\Orgtr\Id\OrgID\ alatt is?

U38.

Debtor Account / Currency: Erre vonatkozóan van bármilyen – a formain túli – ellenőrzés, vagy csak automatikusan továbbítódik? Jól gondoljuk, hogy pl. konverziós tétel esetében ez lehet HUF-tól eltérő? InstructionIdentification: A tranzakció melyik szereplője adhatja meg?

U39.

U40.

A +CdtTrfTxInf / ++PmtTpInf / +++CtgyPurp, illetve +CdtTrfTxInf / ++Purp mezőkben lehet jogcímkódot megadni? Mi a különbség a két mező (csoport) között? Jogcímkódot csak csoportos átutalás esetében lehet megadni, vagy tetszőleges utalásnál? Jól gondoljuk, hogy a kódot nem a Code, hanem a Prtry tag-ben szükséges megadni?

U41.

Cím megadhatósági ellentmondás van az EIS_v2.2ben. Az I. kötet - 13. oldalán az AT-03 mezőnél "Type: Not to be used"

- 15. oldalán az AT-22 mezőnél "Type: Not to be used"

Verzió: v6.0

válasz Az SCT Rulebook szerint a Recall és pacs.004 esetén hivatkozni kell a visszahívó megbízásra (AT-R7). Az EIS (az SCT IGL v5.0-val összhangban) az AT-R7 értéket tartalmazó mezőt opcionális, és csak a Recall-ra adott pozitív válasz (reason = FOCR) a pacs.004 esetén kitölthetőnek definiálja tranzakcióban. A válaszoló, a camt.004 tranzakciót indító bank felelőssége, hogy a megfelelő értékkel kitöltse az AddtlInf mezőt. Mivel az mező opcionális kitöltésű a pacs.004-ben és az EIS (az SCT IGL v5.0-val összhangban) csak annyit állít, hogy csak FOCR-os visszautalás esetén használható (és nem kötelezően használandó!), az IG2 nem ellenőrzi a mező tartalmát. Igen. Az Originator minden esetben (TxInfAndSts\StsRsnInf\Orgtr\Id\OrgID\ és OrgnIGrpInfAndSts\StsRsnInf\Orgtr\Id\OrgID\ alatt is) a GIRO BIC. A törlés oka (TxInfAndSts\StsRsnInf\Rsn) CUST ha a bank (vagy kérésére a GIRO), AM04 ha az utolsó szakasz végén az IG2 fedezethiány miatt kezdeményezte a törlést. CUST indok esetén a törlés kezdeményezőjét azonosítását (camt.056 tranzakció vagy operátor) a kiegészítő információ tartalmazza (TxInfAndSts\StsRsnInf/AddtlInf) Az IG2-ben – a SCT IGL v5.0-vel összhangban – a Debtor Account alatt csak IBAN használható, Currency almező nem. A bankközi (B2B) térben az InstructionIdentification mező tartalmát az átutalást kezdeményező bank adhatja meg. Az IG2-ben a csoportos átutalásnál kötelező megadni az érvényes (az IG2-GMDB-ben szereplő) jogcímkódot a +CdtTrfTxInf / ++Purp / +++ Prtry mezőben. A SEPA az átutalásnál megengedi mindkét jogcímkód (CtgyPurp, Purp) használatát. Mivel a jogcímkód mező használata - a csoportos átutalást kivéve - opcionális, ezért egyéb esetekben az IG2 csak séma-ellenőrzést végez. A Purpose és a Category Purpose között az a különbség, hogy míg az előző a kedvezményezettnek szóló információ, az utóbbi egy feldolgozási instrukció az átutaló, vagy a kedvezményezett bankja számára. Az, hogy milyen speciális feldolgozás köthető a mező használatához az érintett bank(ok) határozza (határozzák) meg. A kezdeményező (Originator) címét az ügyfél --> bank térben - a C2B munkacsoport ajánlása szerint - nem kell használni. A bankközi térben ennek az adatnak a megadása opcionális (a Debtor/PostalAddress/Addressline mezőben). Az átutalást kezdeményező bank az IG2-ben feldolgozandó megbízáson ezt a mezőt a saját előírásai szerint kitöltheti (vagy nem). A kedvezményezett (Beneficiary) címét az ügyfél --> bank térben - a C2B munkacsoport ajánlása szerint nem kell használni. A bankközi térben (B2B) ennek az adatnak a megadása opcionális (a Creditor/PostalAddress/Addressline mezőben).

Dátum: 2011. 11. 17.

23. oldal

GIRO Zrt.

IG2 GYIK

kérdés

válasz Az átutalást kezdeményező bank az IG2-ben feldolgozandó megbízáson ezt a mezőt a saját előírásai szerint kitöltheti (vagy nem).

- 85. oldalán a 3.4-es pont (T217-es mező) miért került törlésre?

U42.

Használhatók-e a cím mezők, ill. melyik és mikor használható?

U43.

pacs.008 tranzakciók esetén a tranzakciók a következő 3 tag alapján egyediek: TxId, elszámolási dátum, Debtor Agent. camt.056, camt.029, pacs.004 tranzakciók esetén az eredeti tranzakció visszakereséséhez a fentiek közül csak az eredeti tranzakcióra vonatkozó TxId és az elszámolási dátum kitöltése kötelező, a Debtor Agent nem. Hogyan biztosítható így az eredeti tranzakció azonosítása? pacs.004 tranzakció esetén az AddtlInf tag töltése az EIS v2.2 volume 2 szerint opcionális. Ezzel szemben a volume 1-ben található, ide vonatkozó definíció alapján (AT-R7), a mezőt pacs.004 / ACK üzenet esetén kötelező tölteni a fogadott camt.056 üzenet CxlId azonosítójával.

U44.

a.) pacs.004/ACK üzenet esetén kötelező-e tölteni az tag-et camt.056 / CxlId mező tartalmával? b) Illetve ezt a GIRO ellenőrzi-e?

U45.

U46.

A camt.029 üzenetben a tranzakciók CxlStsId tag-je (azaz a tranzakció azonosító) az XSD alapján kötelező mező, míg az EIS szerint opcionális mező? Hogyan, milyen hosszon használható a strukturált közlemény mezőben az Issuer és a Reference mező? Felettük az alábbi címkék vannak: SCOR Ezek összege: 94 karakter Issr max.: 35 karakter Ref max.: 35 karakter Összesen: 164 karakter A címkéket nem jól vesszük figyelembe (és a '<>/' szimbólumokat nem kellene beleszámolni), vagy valóban csökkenteni kellene a strukturált közlemény max. hosszát?

24. oldal

A magyarázatot a táblázat alatti sor tartalmazza: csoportos átutalásnál az ügyfél címe (a CSÁT T217 mező tartalma) az UNIFI ISO20022 szabvány szerinti CdtrTxInf/UltmtCdtr/PstlAdr adatelemnek feleltethető meg, ezt az adatelemet viszont az IG2 nem kezeli (mivel ez a SEPA-ban egy használaton kívüli mező). A fentiek miatt töröltük a CSÁT T217 <-> a CdtrTxInf/UltmtCdtr/PstlAdr megfeleltetést táblázatból. Mivel az EIS I. kötetében az SCT kézikönyvben meghatározott attribútumok, üzleti jellemzők hiánytalanul felsorolásra kerültek, feltüntettük a bankközi üzenetben opcionális kitöltésű kedvezményezett címét (AT-22), és a kezdeményező címét (AT-03) is. Az átutalást kezdeményező bank az IG2-ben feldolgozandó megbízáson a címmezőket (AT-03, AT-22) technikailag kitöltheti, de ezt nem ajánljuk, mert az ügyfél által adott átutalási megbízás MSE szabványa ezeket a mezőket mellőzi. A válaszoló, a camt.056, camt.029, pacs.004 tranzakciókat indító bank felelőssége, hogy kitöltse az eredeti átutalást (pacs.008) kezdeményező, a választranzakció fogadóját azonosító Debtor Agent mezőt.

Az SCT Rulebook szerint a Recall és NAK'd Recall esetén hivatkozni kell a visszahívó megbízásra (ATR7). Az EIS (az SCT IGL v5.0-val összhangban) az AT-R7 értéket tartalmazó mezőt opcionális kitöltésűnek definiálja. A válaszoló, a camt.029 tranzakció indító bank felelőssége, hogy a megfelelő értékkel kitöltse az AddtlInf mezőt. Mivel az mező opcionális kitöltésű a pacs.004-ben és az EIS (az SCT IGL v5.0-val összhangban) csak annyit állít, hogy csak FOCR-os visszautalás esetén használható (és nem kötelezően használandó!), az IG2 nem ellenőrzi a mező tartalmát. Az EIS 2.3 változatában – az XSD-vel összhangban – kötelezőként szerepel A strukturált mező hosszának 140 karakterben való korlátozása SCT IGL előírás. A 140-es korlát betartása érdekében csökkenteni kell az Issuer és/vagy a Creditor Reference mezőben szereplő érték hosszát, azaz nem lehet kihasználni a 2*35 karakteres maximumot. Az Issuer és a Reference mező hossza nem változik, nem változhat. Ha egy bank mind a két mezőt használni akarja, akkor döntenie kell, hogy melyik mező (tartalmának) hosszát csökkenti úgy, hogy az együttes hosszuk ne legyen több mint 46 karakter. (94 karakter a cimkék / tag-ek és a SCOR hossza + Issuer és Reference együttesen 46 karakter, azaz mindösszesen 140 karakter). A C2B munkacsoportban merült fel az igény a postai azonosítók SCT-beli elhelyezésére. A POSTA (5

Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt.

kérdés

U47.

A pacs.008-as üzenet definíciójában (XSD) szereplő, de EIS első kötetének 2.1.4 fejezetében nem részletezett, illetve a SEPA CREDIT TRANSFER SCHEME RULEBOOK DS-02 Interbank Payment Dataset-jében fel nem tüntetett mezők használata követelmény-e az IG2-es fejlesztésekkel kapcsolatban? Az EIS második kötet a teljes XSD leírását tartalmazza. Amennyiben fel kell készülni minden elemre, akkor kérnénk szépen egy leírást, ami minden adat leírását tartalmazza, mert a SEPA CREDIT TRANSFER SCHEME RULEBOOK-ban ez nem található meg.

U48.

Amennyiben visszahívásra kerül egy tranzakció, és vissza is utaljuk, akkor az IG2 a visszautalás során végez-e számszaki ellenőrzést az összegekre? Azaz az eredeti összegben szereplő adatot megnézi-e számszakilag, hogy az utalandó összeg és a levont jutalék összegének szummája megegyezik-e az eredeti összeggel? Nem lenne jó, ha ellenőrizne, ugyanis előfordulhat, hogy bizonyos esetekben nem fognak stimmelni a számok. Ez valószínűleg minden olyan esetben előfordul, ahol devizaszámlára jóváírt pénzt utalunk vissza, ugyanis itt árfolyamkülönbség miatt szinte mindig eltérés lesz az összegeknél.

válasz karakter) és a postai azonosító (max. 24 karakter) Issuer és Reference mezőben történő feltüntetésével ez az igény kielégíthető. A fenti két mező össz-hossza még így is csak 29 karakter, ami bőven belefér az 'engedélyezett' 46 karakterbe. Igen, az UNIFI üzeneteknek vannak olyan DS-02-ben fel nem sorolt elemei, amiknek használata követelmény az IG2-es fejlesztésekkel kapcsolatban. Az SCT Rulebook és az EIS I. kötete csak az SCT üzleti attribútumokat (AT-nn) és azok használatát, jelentését részletezi. Az UNIFI ISO 20022 szabványnak vannak az átutalásnál kötelezően és / vagy opcionálisan használható olyan címkéi, amelyeket az SCT RB nem jelölt attribútumként, illetve az egyes attribútumok alábontásában szerepelnek. Az IG2 befogad és továbbít minden, az SCT IGL (Implementation GuideLines) v5.0 -ban hivatkozott adatelemet, ezért részleteztünk minden adatelemet az EIS II. kötetében (és az XSD-ben). A SEPA átutalás az UNIFI (ISO 20022) szabványokat alkalmazza. Az SCT IGL szabályokat állapít meg az UNIFI ISO 200022 szabványok használatához a Rulebook-ban foglaltak megvalósítása érdekében. Az UNIFI üzenetek teljes körű leírása tartalmazza mindazt, amire a bankoknak szüksége van. Ezek a leírások, melyek elnevezése Message Definition Report a www.iso20022.org internetoldalon megtalálhatók és pdf formátumban letölthetők. Az SCT átutalásokhoz a • Payments - Maintenance 2009, és az • Exceptions and Investigations - Maintenance 2009 üzenetleírásokat kell használni. Fejlesztéshez ezeket a forrásokat az adatokat, adatelemeket verbálisan részletező, magyarázó EIS II. kötettel, ill. XML nyelven leíró XSD fájlokkal együtt kell használni. A pacs.004 tranzakcióban 3 ellenőrizendő összeg szerepel az SCT IGL v5.0-val összhangban: • hivatkozás az eredetileg átutalt összegre: +TxInf/++OrgnlIntrBkSttlmAmt, • visszautalt összeg: +TxInf/++RtrdIntrBkSttlmAmt, • költség: +TxInf/ ++ChrgsInf/+++Amt., ez csak csak FOCR-os visszautalásnál használható. Az IG2 általi ellenőrzések: Hivatkozás az eredeti átutalás összegére: +TxInf/++OrgnlIntrBkSttlmAmt. Ennek meg kell egyeznie a hivatkozott pacs.008 átutalás összegével. A visszahívások korlátozott ellenőrzésének megvalósításakor, a FOCR indokú visszautalásoknál ez az ellenőrzés elmarad. Visszautalt összeg: +TxInf/++RtrdIntrBkSttlmAmt • nem FOCR-os visszautalásnál a visszautalt összegnek meg kell egyeznie az eredeti átutalási összeggel +TxInf/++RtrdIntrBkSttlmAmt = +TxInf/++OrgnlIntrBkSttlmAmt

•

FOCR-os visszautalásnál a visszautalt összeg + a költség összegének meg kell egyeznie az eredeti átutalási összeggel: +TxInf/++RtrdIntrBkSttlmAmt plusz +TxInf/++ChrgsInf/+++Amt = +TxInf/++OrgnlIntrBkSttlmAmt

U49.

az EIS v2.3(v2.2) -ban a 18-19 oldalon a következő lehetséges elírás található(pacs.008):

Verzió: v6.0

A visszahívások korlátozott ellenőrzésének megvalósításakor, a FOCR indokú visszautalásoknál ez az ellenőrzés elmarad. A pacs.008 felépítése a bejövő (ICF) és a kimenő (SCF) fájlban azonos.

Dátum: 2011. 11. 17.

25. oldal

GIRO Zrt.

IG2 GYIK

kérdés GrpHdr/InstgAgt/FinInstnId/BIC - O-opcionálisként van jelölve. A táblázatban a Validation Conditions részben mind a header mind a tranzakciós rész helyesen írja le a használatát csak a header esetében írja O -ként. Ott lehet, hogy M-ként kellene jelölni.

U50.

Ha a pacs008-ban eredetileg nem volt AT-05 akkor a return-ban opció szerint sem kell megjeleníteni az unstructured és a structured mezőket? Ha eredetileg volt AT-05 (akár unstructured vagy structured ) akkor a return-ban mind a két mezőt meg kell küldeni, amit eredetileg fogadtunk, a másik mezőt meg üresen kell hagyni?

válasz A GIRO-ból kimenő (SCF) fájlban nincs Instructing Agent (hiszen a megbízások különböző közvetlen résztvevők által kezdeményezett különböző input fájlokból kerültek át a kimenő fájlba), a kezdeményező Instructing Agent szerepeltetése ezért nem mindig kötelező. Erre utal az EIS-ben az opcionálisan kitöltendő Instructing Agent mező magyarázata: Must be present for ICF. Will NOT be present for SCF. Megjegyzés: az SCT IGL v5.0 is opcionális kitöltésűként jelöli az Instructing Agent mezőt. A pacs.004 üzenetben a strukturált és strukturálatlan közleményre - a pacs.008 üzenettel összhangban kell hivatkozni, azaz vagy csak a strukturált, vagy csak a strukturálatlan közlemény adható meg.

1.1.6. E G Y É B kérdés

válasz

Hol található meg az IG2 szakmailag közérthető leírása?

EIS v2.1 I. kötetében, ami angol és magyar nyelven is 3 hozzáférhető a www.giro.hu/ig2 oldalon


EIS v2.2 angol nyelvű változata is elérhető

E2.

Vannak-e a BKR/CSÁT és HCT üzenetek egymáshoz rendelését szemléltető táblák?

Igen, az EIS v2.1 I. kötet 9.1 fejezetben

E3.

Az InterGIRO2, azaz a napközbeni elszámolás bevezetésével kezdődően két rendszert kell párhuzamosan üzemeltetni?

Igen, a jelenlegi InterGIRO1 rendszer a klasszikus BKR* szabványokkal továbbra is üzemben marad.

E4.

Ha a belső projekt várhatóan 2012.07.01-re nem zárul le, milyen támogatást tud nyújtani a GIRO, ez a támogatás a konverziót el tudja végezni?

A GIRO nem ad külön támogatást. Az intézményi projekt sikertelensége esetén is képesnek kell lennie a fogadásra. Amennyiben a bank erre sem képes, akkor időben intézkednie kell arról, hogy levelezett bankként folytassa tevékenységét.

E5.

Számlaszám-hordozhatóság téma kerül-e az IG2-höz kapcsolódva?

napirendre

Nem, a téma napirendre kerülése nincs tervezve az InterGIRO2-höz kapcsolódóan.

E6.

Hogyan kell jelezni a csoportos átutalások visszaigazolásait tartalmazó DETSTA állományban a visszahívást, illetve annak pozitív vagy negatív válaszát?

A DETSTA állomány ’kezelése’ az IG1-ben és az IG2-ben azonos módon történik a bankban. Az IG1 és az IG2 közötti különbség kizárólag a visszahívás, ill. annak válasza megvalósításában van. Az IG2-ben – ellentétben az IG1-gyel – létezik visszahívó tranzakció (camt.056), ill. a visszahívás elutasítása, ill. teljesítése, a visszakért összeg átutalása szintén önálló, erre a célra kifejlesztett SEPA tranzakcióval valósítható meg. (camt.029 – visszautasítás, pacs.004 – teljesítés)

E7.

Ha a GIROHálón fog működni a jövőben a KHR adatlekérdezés és adatküldés is, akkor: 1 . Ez hogyan és mit befolyásol? 2. Szükséges-e sávszélesség bővítés? 3. Ha igen, ez milyen feladatot jelent a bank számára?

1. A klíringtagoknak arra kell felkészülni, hogy a GIROHálón párhuzamosan több típusú adatkommunikáció folyhat. 2. Az előzetes mérések szerint a klíringtagok döntő többségénél valószínűleg nem lesz szükség sávszélességbővítésre. Ezt a tesztelés során a GIRO tovább vizsgálja

E1.

3

Az oldal jelszóvédett; amennyiben nem találja a belépési adatait, az [email protected] címen tudunk segítséget nyújtani!

26. oldal

Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

E8.

E9.

E10

GIRO Zrt. kérdés 4. Mely tételek fognak elsőbbséget élvezni? 5. Szükséges-e továbbra is bérelt vonalak használata, vagy várható-e VPN alapú, internetes vonalak használatának bevezetése?

válasz vonalterhelés-tesztek segítségével, amelyeknek tapasztalatait megosztja a klíringtagokkal. 3. Amennyiben valamely klíringtag esetén mégis szükséges a sávszélesség bővítése, akkor az adott klíringtagnak igényelnie kell a GIRO-nál a sávszélesség bővítést, megjelölve a kívánt kapacitást. 4. A GIRO nem tervezi a GIROHálón egyszerre folyó adattovábbítások között központi prioritások bevezetését, nehéz vagy lehetetlen lenne ugyanis olyan prioritási skálát felállítani, amely minden klíringtag igényeinek egyformán megfelel. Ezért amennyiben egy klíringtag igényli azt, hogy a GIROHálón futó adatforgalomban legyen prioritási sorrend akár állandóan, akár bizonyos napszakokban, akkor azt saját rendszereiben célszerű definiálnia és kezelnie. Amennyiben a 2011 őszén induló tesztek eredménye minden előzetes várakozásunk ellenére azt mutatja, hogy a sávszélesség kritikus kérdés lesz az IG2ben, abban az esetben a GIRO képes és kész központi megoldásokat tesztelni és bevezetni. 5. Jelenleg a GIRO nem tervezi az Interneten való kommunikáció bevezetését.

Konverziós tétel árfolyameltérés miatti eltérés esetén eltérő összeg visszautalására van-e lehetőség (visszahívás esetén)? Ha igen, milyen módon

Az árfolyam különbséget mely egy devizaszámlára jóváírt forint tételre érkező recall üzenet – jóváhagyás után – az eredetileg átutalt összeg visszautalása során keletkezik, a jelenlegi gyakorlat szerint kell kezelni, ugyanúgy, mint az IG1 esetében.


Igen, van lehetőség.

A Giro átállás kapcsán, novemberben tartandó teszthez, kell-e külön igényelni a Bankoknak a GIROHáló szolgáltatást? (Vagy használható esetleg az ”elszámolásforgalom-file teszt” szolgáltatás?) Illetve kell-e külön teszt tanúsítványt igényelni, vagy a GIRO központilag ad mindenkinek? Ha nem, akkor mi a módja annak, ha az pl. 2011.10.07-én lejár, és csak egy tanúsítvány jár teszt célra díjmentesen. Azaz igényelhető-e, hogy pl. 2011.10.10-től éljen az új teszt tanúsítvány?

Az "GIROHálón igénybe vett szolgáltatás megrendelőlap" új verziójába bele fognak kerülni az új tesztcsatornák (InterGIRO2-file és InterGIRO2-web), amely egyben azt is jelenti, hogy a jelenlegi csatornák mellett kerülnek ezek kialakításra. Ezeket az új adatlapokat várhatóan szeptember-október folyamán publikáljuk a szükséges tudnivalókkal egyetemben (a korábbi megrendelésekhez képest nem várható lényegi változás) és a klíringtagoknak ezen kell majd igényelniük az új csatornák kialakítását. Központi tanúsítványkiadás nem lesz, mivel a korábban kiadott teszttanúsítványok használhatók lesznek a teszteken. A lejáró teszttanúsítvány helyett újat kell igényelni (az élessel szemben a teszttanúsítványokat nem újítjuk meg automatikusan), amely már díjköteles lesz. Mivel az igénylést nem tudjuk előre ütemezni, kérjük, szeptember utolsó napjaiban küldjék be a tanúsítványigénylő adatlapot az átfedés biztosításához. Amennyiben az új teszttanúsítványra a novemberi tesztek előtt egészen biztosan nem lesz szükség más célból (pl. KHR) sem, abban az esetben nem feltétlenül szükséges már szeptemberben megrendelni az újat.

Előreláthatólag mikor lesz elérhető az SSR és SRR üzenetek részletes definíciója? Jól értelmezzük-e, hogy az október 26-án kezdődő validációs tesztelésre még az EIS 2.2-ben és GYIK 3.0–ban leírtak érvényesek?

Az EIS 2.3 verziója tartalmazza az SRR és SSR általános bemutatását (az I. kötetben) és a mezőnkénti részletes definíciót is (a II. kötetben). Az októberi validációs teszt forgatókönyve részletezni fogja, hogy milyen eredményfájlok fogadására és feldolgozására kell felkészülniük a bankoknak.

A 2012 januárjában induló kötelező Banki rendszerteszt esetében alkalmazásra fognak-e kerülni az SSR és SRR üzentetek?

A 2012 januárjában induló kötelező Banki rendszerteszt forgatókönyve részletezni fogja, hogy milyen eredményfájlok fogadására és feldolgozására kell felkészülnie a bankoknak A sikeres rendszertesztek után a GIRO honlapon elérhető mintaállományokat tovább bővítjük az SRR és SSR

Verzió: v6.0

Dátum: 2011. 11. 17.

27. oldal

GIRO Zrt.

IG2 GYIK kérdés

válasz fájlokkal és a bővítésről értesítjük az összes bankot.

1.1.7. IG2 MO N I T O R ( I N T E R A K TÍ V T E R M I N Á L ) ld. még G31 kérdés

válasz

M1.

Hogyan authentikálnak a DP Monitor userek? Smartcard és GIROLock?

Smartcard alapon, GIROLock tanúsítvánnyal, amelyet a GIRO biztosít.

M2.

Milyen felhasználói szerepkörök kialakításra a DP Monitorban?

kerülnek

Operátor, Banki admin, Banki jóváhagyó. Az elnevezések még esetleg változhatnak

M3.

Elkülöníthető-e az egyszerű monitoring funkció és a tranzakció visszahívási funkció?

A visszahíváshoz, illetve visszahívás jóváhagyásához többlet-jogosultság kell.

M4.

Hogyan történik a hozzáférési jogosultságok menedzsmentje a DP Monitor esetében?

GIROLock formanyomtatványon történő igényléssel.

M5.

Hogyan kérhetjük egy új user bejegyzését, egy meglévő törlését ill. egy létező user jogosultságainak módosítását? Hogyan garantálja a folyamat, hogy illetéktelenek nem kapnak hozzáférést a szolgáltatáshoz?

GIROLock formanyomtatványon történő (megjelölve a felhasználót/kártyaID-t).

M6.

A tranzakciók visszahívása a DP Monitorban a 4-szem elvhez kötött-e?

Igen.

M7.

Logolja-e a tranzakció visszahívásokat a DP Monitor és ez a log hozzáférhető-e számunkra?

Igen.

M8.

Rendelkezik-e a DP Monitor security log-gal (bejelentkezés, kijelentkezés, sikertelen bejelentkezés) és ez a log hozzáférhető-e számunkra?

Security log hozzáférhető.

igényléssel

Az illetéktelen hozzáférést a GIRO által végrehajtott megszemélyesítés biztosítja.

készül,

de

az

ügyfél

számára

nem

1.1.8. EIS 2.3 K É R D É S E K N Y O M Á N J A V Í T A N D Ó , P O N TO S Í TA N D Ó H I B Á I Ez a fejezet ideiglenes jellegű, az EIS v2.3 Hibaigazító (Errata) dokumentum megjelenését követő kiadásban törlésre fog kerülni. Hely

Javítást igénylő pont (várható javítás, pontosítás dőlt betűvel)

EIS vol I.

AM05 szerepel

4.5.1.3 pont

A helyes érték: AM04

W2.

EIS vol II. 12. o.

General Remarks 5) pont alatt a felsorolás nem teljes körű. A felsorolás törlésre kerül, mert a rendszer az eredeti üzenet pontos másolatának meglétét ellenőrzi..

W3.

EIS vol II. 14. o.

General Remarks 7) pont szerint a speciális karakterek helyigénye több, mint egy karakter.

W1.

A tesztelés során azt tapasztaltuk, hogy az xml-specifikus 'fura' karakterket az IG2 nem egy karakterként, hanem pl. ,6 karakternek (pl. ") értelmezte. A problémát jeleztük a fejlesztőnek, aki ki is javította, de tesztelni csak az EIS v2.3 kiadása után tudtuk. Az EIS következő változatában már nem szerepeltetjük a mező-hosszra vonatkozó kitételt. Tehát a 4-6 hosszú karakter-sorozatban ábrázolt XML-specifikus karakterek az üzenetben 1 karakternyi helyet foglalnak el. W4. 28. oldal

EIS vol II. 14. o.

General Remarks 9) pont alatt a GIRO-ból kimenő SCF-ekre is vonatkozik 10 000 tételes Dátum: 2011. 11. 17.

Verzió: v6.0

IG2 GYIK

GIRO Zrt. korlát. Pontosabban: az input fájl tranzakciókban mért mérete - minden Közvetlen Résztvevőre a rendszerparaméter értéke (jelenleg 10 000), a fogadó kötegben (SCF) pedig a Közvetlen Résztvevő által megadott paraméter-érték (default: 10 000) szerinti számú tranzakciót helyez az IG2

W5.

EIS vol II. 21. o.

+CdtTrfTxInf/ ++PmtTpInf/ +++LclInstrm/ ++++Cd értéke: Standard ISO code ‘SEPA’ Használata nem javasolt. A rendszer elfogadja ugyan a SEPA értéket, de annak nincs jelentése, és nem szerepel az ISO 20022 külső kódlistában sem (ill a SEPA érték a Service Level kódok között) található. Ennek ellenére a rendszer a SEPA-t elfogadja.

W6.

EIS vol II. 68. o.

InstrID Contents oszlopban szereplő magyarázat (utalás OrgnlInstrId-re) helytelen. Az InstrID az átutaló bankja által meghatározott tételazonosító (opcionális)

W7.

EIS vol II. 90. o.

Ustrd és Strd előfordulása az első oszlop szerint [1..1]. A helyes érték [0..1]

W8.

EIS vol II. 94. o.

Validation condition oszlopban a szöveg helyesen: „Pairing is only done if the reason code is other than FOCR (see General Remarks point 5)” A jelenlegi, helytelen megfogalmazás szerint FOCR-tól eltérő esetben nincs párosítás.

W9.

EOD fájl

Összegekben ezres elválasztó vesszők. Ezres elválasztó vesszők kiiktatásra kerülnek.

Verzió: v6.0

Dátum: 2011. 11. 17.

29. oldal

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

Recommend Documents