natgillin/translations-raw huggingface dataset:
Except where otherwise provided for in these Conditions, all notices required or permitted pursuant to these Conditions shall be sent by registered post, facsimile or otherwise in writing.
E Feltételek eltérő rendelkezésének hiányában az e Feltételek alapján előírt vagy megengedett értesítéseket ajánlott levélben, faxon vagy egyéb írásos módon kell megtenni.
Notices to the [insert name of CB] shall be submitted to the head of the [insert payment systems department or relevant CB unit] of [insert name of CB], [include relevant address of CB] or to the [insert BIC address of the CB].
A(z) [a KB neve beillesztendő]-nak/-nek szóló értesítéseket a(z) [a KB neve beillesztendő] [írja be az adott KB fizetési rendszerekkel foglalkozó részlege vagy a megfelelő KB-részleg nevét] vezetőjének kell benyújtani a(z) [írja be a KB megfelelő címét] címre vagy pedig a(z) [írja be a KB BIC-címét] címre.
Notices to the participant shall be sent to it at the address, fax number or its BIC address as the participant may from time to time notify to the [insert name of CB].”
A résztvevőnek szóló értesítéseket az általa a(z) [a KB neve beillesztendő]-nak/-nek időről időre bejelentett címre, telefaxszámra vagy BIC-címre kell megküldeni.«
Article 45 is replaced by the following:
A 45. cikk helyébe a következő szöveg lép:
“Article 45
»45. cikk
If any provision in these Conditions or Annex V is or becomes invalid, this shall not prejudice the applicabilityof all the other provisions of these Conditions or Annex V.”
Ha e Feltételek vagy az V. melléklet valamely szabálya érvénytelen vagy azzá válik, ez nem érinti a Feltételek vagy az V. melléklet összes többi szabályának alkalmazhatóságát.«
Appendix IA
IA. függelék
TECHNICAL SPECIFICATIONS FOR THE PROCESSING OF PAYMENT ORDERS FOR INTERNET-BASED ACCESS
A FIZETÉSI MEGBÍZÁSOK FELDOLGOZÁSÁRA VONATKOZÓ MŰSZAKI ELŐÍRÁSOK
In addition to the Conditions, the following rules shall apply to the processing of payment orders using Internet-based access:
A Feltételeken túlmenően az internetalapú hozzáféréssel történő fizetési megbízások feldolgozására a következő szabályok vonatkoznak:
Technical requirements for participation in TARGET2-[insert CB/country reference] regarding infrastructure, network and formats
Műszaki követelmények a TARGET2-[a KB neve/országkód beillesztendő]-ban/-ben való részvételhez, az infrastruktúra, hálózat és formátumok tekintetében
Each participant using Internet-based access must connect to the ICM of TARGET2 using a local client, operating system and Internet browser as specified in the Annex “Internet-based participation – System requirements for Internet access” to the User Detailed Functional Specifications (UDFS), with settings defined.
Az internetalapú hozzáférést használó egyes résztvevőknek a TARGET2 ICM-jéhez a Részletes felhasználói műszaki leírás (UDFS) »Internetalapú részvétel – Az internetes hozzáférésre vonatkozó rendszerkövetelmények« című mellékletében meghatározott helyi ügyfélen, operációs rendszeren és internetes böngészőn keresztül, a meghatározott beállításokkal kell csatlakoznia.
Each participant’s PM account shall be identified by an eight- or 11-digit BIC.
Minden egyes résztvevő PM-számláját egy nyolc vagy tizenegy számjegyből álló BIC-kel azonosítják.
Furthermore, each participant shall pass a series of tests to prove its technical and operational competence before it may participate in TARGET2-[insert CB/country reference].
Továbbá minden résztvevőnek meg kell felelnie a technikai és üzemeltetési képességeit igazoló tesztsorozaton, mielőtt részt vehetne a TARGET 2-[a KB neve/országkód beillesztendő]-ban/-ben.
For the submission of payment orders and the exchange of payment messages in the PM the TARGET2 platform BIC, TRGTXEPMLVP, will be used as the message sender/receiver.
Fizetési megbízások benyújtásához és a PM-ben történő fizetési üzenetváltáshoz a BIC TARGET2-platformot, a TRGTXEPMLVP-t használják üzenetküldőként/-fogadóként.
Payment orders sent to a participant using Internet-based access should identify that receiving participant in the beneficiary institution field.
Az internetalapú hozzáférést használó résztvevőknek küldött fizetési megbízások ezt a fogadó résztvevőt nevezik meg a kedvezményezett intézmény mezőben.
Payment orders made by a participant using Internet-based access will identify that participant as the ordering institution.
Az internetalapú hozzáférést használó résztvevők által küldött fizetési megbízások ezt a résztvevőt megbízó intézményként nevezik meg.
Participants using Internet-based access shall use public key infrastructure services as specified in the “User Manual: Internet Access for the public-key certification service”.
Az internetalapú hozzáférést használó résztvevők »A nyilvános kulcsú tanúsítási szolgáltatás esetében történő internetes hozzáférésről szóló felhasználói kézikönyvben« meghatározott nyilvános kulcsú infrastruktúrát használnak.
Payment message types
A fizetési üzenetek típusai
Internet-based participants can make the following types of payments:
Az internetalapú hozzáférést használó résztvevők a következő fizetéstípusokat alkalmazhatják:
customer payments, i.e. credit transfers for which the ordering and/or beneficiary customer are not financial institutions;
ügyfélfizetés, vagyis olyan átutalások, amelyek esetében a megbízó és/vagy a kedvezményezett ügyfél nem pénzügyi intézmény;
customer payments STP, i.e. credit transfers for which the ordering and/or beneficiary customer are not financial institutions, executed in straight through processing mode;
STP ügyfélfizetés, vagyis olyan átutalások, amelyek esetében a megbízó és/vagy a kedvezményezett ügyfél nem pénzügyi intézmény, és a végrehajtás STP üzemmódban történik;
bank-to-bank transfers to request the movement of funds between financial institutions;
bankközi átutalás a pénzügyi intézmények közötti pénzeszköz-átutalások lekérése céljából;
cover payments to request the movement of funds between financial institutions related to an underlying customer credit transfer.
fedezeti fizetések a pénzügyi intézmények közötti olyan pénzeszköz-átutalások lekérése céljából, amelyek mögöttes ügyfélátutaláshoz kapcsolódnak.
In addition, participants using Internet-based access to a PM account can receive direct debit orders.
Ezenkívül a PM-számlához internetalapú hozzáférést használó résztvevők fogadhatnak közvetlen terhelési megbízásokat.
Participants shall comply with the field specifications, as defined in Chapter 9.1.2.2 of the UDFS, Book 1.
A résztvevőknek be kell tartaniuk az UDFS első kötetének 9.1.2.2. fejezetében meghatározott mezőleírásokat.
Field contents shall be validated at the level of TARGET2-[insert country/CB reference] in accordance with the UDFS requirements.
A mezőtartalom validálása a TARGET2-[KB neve/országkód beillesztendő] szintjén történik az UDFS követelményeknek megfelelően.
Participants may agree among each other on specific rules regarding the field contents.
A résztvevők egymás között megállapodhatnak egyedi szabályokról a mezőtartalom vonatkozásában.
However, in TARGET2-[insert country/CB reference] there shall be no specific checks as to whether participants comply with any such rules.
A TARGET2-[KB neve/országkód beillesztendő]-ban/-ben ugyanakkor nem történik külön ellenőrzés arra vonatkozóan, hogy a résztvevők betartják-e az ilyen szabályokat.
Participants using Internet-based access may make cover payments via TARGET2, i.e. payments made by correspondent banks to settle (cover) credit transfer messages which are submitted to a customer’s bank by other, more direct means.
Az internetalapú hozzáférést használó résztvevők a TARGET2-n keresztül végrehajthatnak fedezeti fizetéseket, azaz a levelező bankok által olyan átutalási üzenetek elszámolására (fedezésére) végrehajtott fizetéseket, amelyeket az ügyfél bankjához más, közvetlenebb eszközzel nyújtottak be.
Customer details contained in these cover payments shall not be displayed in the ICM.
Az ilyen fedezeti fizetésekben foglalt ügyféladatokat nem teszik közzé az ICM-ben.
Double-entry check
A kettős bevitel ellenőrzése
All payment orders shall pass a double-entry check, the aim of which is to reject payment orders that have been submitted more than once by mistake.
Minden fizetési megbízásnak meg kell felelnie a kettős beviteli ellenőrzésen, aminek célja az olyan fizetési megbízások visszautasítása, amelyek tévedésből többször kerültek benyújtásra.
The following fields of the message types shall be checked:
Az üzenettípusok alábbi mezői kerülnek ellenőrzésre:
Part of the message
Az üzenet része
Sender
Küldő
Basic Header
Alapfejléc
BIC Address
BIC-cím
Message Type
Üzenet típusa
Application Header
Alkalmazás fejléce
Receiver
Fogadó
Destination Address
Rendeltetési cím
Transaction Reference Number (TRN)
Tranzakciószám (Transaction Reference Number – TRN)
Text Block
Szövegtörzs
Related Reference
Kapcsolódó hivatkozás
Value Date
Értéknap
If all the fields described in subparagraph 2 in relation to a newly submitted payment order are identical to those in relation to a payment order that has already been accepted, the newly submitted payment order shall be returned.
Ha egy újonnan benyújtott fizetési megbízás vonatkozásában a 2. bekezdésben leírt minden mező megegyezik egy már elfogadott fizetési megbízás ilyen adataival, az újonnan bevitt fizetési megbízás visszaküldésre kerül.
Error codes
Hibakódok
If a payment order is rejected, an abort notification shall be provided via the ICM indicating the reason for the rejection by using error codes.
Ha egy fizetési megbízás visszautasításra kerül, az utasítást adó résztvevő az ICM-en keresztül egy visszautasítási értesítést kap, ami hibakódok használatával feltünteti a visszautasítás okát.
The error codes are defined in Chapter 9.4.2 of the UDFS.
A hibakódok meghatározása az UDFS 9.4.2. fejezetében történik.
For payment orders using the Earliest Debit Time Indicator, the codeword “/FROTIME/” shall be used.
A »Legkorábbi terhelési időpont magadása« funkciót használó fizetési megbízások tekintetében a »/FROTIME/« kódot kell használni.
For payment orders using the Latest Debit Time Indicator, two options shall be available.
A »Legkésőbbi terhelési időpont megadása« funkciót használó fizetési megbízások tekintetében két lehetőség áll rendelkezésre.
Codeword “/REJTIME/”
»/REJTIME/« kód
if the payment order cannot be settled by the indicated debit time, the payment order shall be returned.
ha a fizetési megbízás nem számolható el a megadott terhelési időpontig, a fizetési megbízás visszaküldésre kerül.
Codeword “/TILTIME/”
»/TILTIME/« kód
if the payment order cannot be settled by the indicated debit time, the payment order shall not be returned but shall be kept in the relevant queue.
ha a fizetési megbízás nem számolható el a megadott terhelési időpontig, a fizetési megbízása nem kerül visszaküldésre, hanem beállítják a megfelelő sorba.
Under both options, if a payment order with a Latest Debit Time Indicator is not settled 15 minutes prior to the time indicated therein, a notification shall automatically be provided via the ICM.
Mindkét lehetőség keretében, ha a »Legkésőbbi terhelési időpont megadása« funkcióval ellátott fizetési megbízás az abban megadott időpont előtt 15 perccel nem kerül elszámolásra, az ICM-en keresztül automatikusan értesítés kerül kiküldésre.
If the codeword “/CLSTIME/” is used, the payment shall be treated in the same way as a payment order referred to in subparagraph 2(b).
Ha a »/CLSTIME/« kódot használták, a fizetést ugyanolyan módon kezelik, mint a 2. bekezdés b) pontjában említett fizetési megbízást.
Settlement of payment orders in the entry disposition
A teljesítési sorban lévő fizetési megbízások kiegyenlítése
Offsetting checks and, if appropriate, extended offsetting checks (both terms as defined in paragraphs 2 and 3) shall be carried out on payment orders entered into the entry disposition to provide quick, liquidity-saving gross settlement of payment orders.
Beszámítási ellenőrzések és adott esetben bővített beszámítási ellenőrzések (mindkét kifejezés a 2. és 3. bekezdés értelmében) kerülnek végrehajtásra a teljesítési sorba kerülő fizetési megbízások vonatkozásában, a fizetési megbízások gyors, likviditáskímélő, bruttó kiegyenlítésének biztosítására.
An offsetting check shall determine whether the payee’s payment orders that are at the front of the highly urgent or, if inapplicable, the urgent queue are available to be offset against the payer’s payment order (hereinafter “offsetting payment orders”).
A beszámítási ellenőrzés meghatározza, hogy vannak-e a kedvezményezett nagyon sürgős vagy, ha ilyen nincs, sürgős sorának elején álló olyan fizetési megbízások, amelyek lehetővé teszik a fizető fizetési megbízásával szemben történő beszámítást (a továbbiakban: beszámítható fizetési megbízások).
If an offsetting payment order does not provide sufficient funds for the respective payer’s payment order in the entry disposition, it shall be determined whether there is sufficient available liquidity on the payer’s PM account.
Ha a teljesítési sorban lévő, beszámítható fizetési megbízás nem biztosít elegendő fedezetet a fizető megfelelő fizetési megbízására, meg kell állapítani, hogy rendelkezésre áll-e megfelelő likviditás a fizető PM-számláján.
If the offsetting check fails, the [insert name of CB] may apply an extended offsetting check.
Ha a beszámítási ellenőrzés nem hoz eredményt, a(z) [a KB neve beillesztendő] bővített beszámítási ellenőrzést hajthat végre.
An extended offsetting check determines whether offsetting payment orders are available in any of the payee’s queues regardless of when they joined the queue.
A bővített beszámítási ellenőrzés meghatározza, hogy a kedvezményezett bármelyik sorában vannak-e beszámítható fizetési megbízások, függetlenül attól, hogy azok mikor kerültek a sorban.
However, if in the queue of the payee there are higher priority payment orders addressed to other TARGET2 participants, the FIFO principle may only be breached if settling such an offsetting payment order would result in a liquidity increase for the payee.
Ha azonban a kedvezményezett sorában vannak más TARGET2-résztvevőknek címzett, magasabb prioritású fizetési megbízások, a FIFO elvet csak akkor lehet megszegni, ha az ilyen beszámítható kifizetési megbízás kiegyenlítése a kedvezményezettnél likviditásnövekedéshez vezetne.
Settlement of payment orders in the queue
A sorban lévő fizetési megbízások kiegyenlítése
The treatment of payment orders placed in queues depends on the priority class to which it was designated by the instructing participant.
A sorba állított fizetési megbízások kezelése függ attól a prioritási osztálytól, amelybe a fizetési megbízást az utasítást adó résztvevő besorolta.
Payment orders in the highly urgent and urgent queues shall be settled by using the offsetting checks described in paragraph 6, starting with the payment order at the front of the queue in cases where there is an increase in liquidity or there is an intervention at queue level (change of queue position, settlement time or priority, or revocation of the payment order).
A nagyon sürgős és sürgős sorokban lévő fizetési megbízásokat a 6. bekezdésben leírt beszámítási ellenőrzésekkel kell kiegyenlíteni, kezdve a sor elején álló fizetési megbízással, ha likviditásnövekedés vagy a sor szintjén való beavatkozás történik (megváltozik a fizetési megbízás sorban elfoglalt helye, kiegyenlítési időpontja vagy prioritása, illetve a fizetési megbízás visszavonásra kerül).
Payments orders in the normal queue shall be settled on a continuous basis including all highly urgent and urgent payment orders that have not yet been settled.
A normál prioritású fizetési megbízások kiegyenlítése folyamatosan történik, beleértve valamennyi még nem kiegyenlített, nagyon sürgős és sürgős fizetési megbízást.
Different optimisation mechanisms (algorithms) are used.
Különféle optimalizációs mechanizmusokat (algoritmusok) használnak.
If an algorithm is successful, the included payment orders will be settled; if an algorithm fails, the included payment orders will remain in the queue.
Ha egy algoritmus sikeres, az érintett fizetési megbízásokat teljesítik; ha egy algoritmus sikertelen, az érintett fizetési megbízások a sorban maradnak.
Three algorithms (1 to 3) shall be applied to offset payment flows.
Három (1–3. sz.) algoritmus kerül alkalmazásra a fizetési folyamatok beszámítására.
By means of Algorithm 4, settlement procedure 5 (as defined in Chapter 2.8.1 of the UDFS) shall be available for the settlement of payment instructions of ancillary systems.
A 4. sz. algoritmus alkalmazásával az (UDFS 2.8.1. fejezetében meghatározott) 5. sz. kiegyenlítési eljárás áll rendelkezésre a kapcsolódó rendszerek fizetési megbízásainak kiegyenlítésére.
To optimise the settlement of highly urgent ancillary system transactions on participants’ sub-accounts, a special algorithm (Algorithm 5) shall be used.
A kapcsolódó rendszerek nagyon sürgős tranzakcióinak a résztvevők alszámláin történő kiegyenlítése optimalizálására egy külön algoritmus (5. sz. algoritmus) kerül felhasználásra.
Under Algorithm 1 (“all-or-nothing”) the [insert name of CB] shall, both for each relationship in respect of which a bilateral limit has been set and also for the total sum of relationships for which a multilateral limit has been set:
Az 1. sz. algoritmus (»mindent vagy semmit«) keretében a(z) [a KB neve beillesztendő] – mind a kétoldalú limittel ellátott kapcsolatok mindegyike, mind pedig a többoldalú limittel ellátott kapcsolatok teljes összege vonatkozásában – a következőket teszi:
calculate the overall liquidity position of each TARGET2 participant’s PM account by establishing whether the aggregate of all outgoing and incoming payment orders pending in the queue is negative or positive and, if it is negative, check whether it exceeds that participant’s available liquidity (the overall liquidity position shall constitute the “total liquidity position”); and
i. kiszámítja minden TARGET2-résztvevő PM-számlájának teljes likviditási pozícióját annak megállapításával, hogy a sorban álló kimenő és bejövő összes fizetési megbízás összege negatív vagy pozitív, és ha ez negatív, ellenőrzi, hogy ez meghaladja-e az adott résztvevő rendelkezésre álló likviditását (az átfogó likviditás pozíció képezi a »teljes likviditási pozíciót«); és
check whether limits and reservations set by each TARGET2 participant in relation to each relevant PM account are respected.
ellenőrzi, hogy az egyes TARGET2-résztvevők által az egyes PM-számlák tekintetében meghatározott limiteket és elkülönített likviditást betartják-e.
If the outcome of these calculations and checks is positive for each relevant PM account, the [insert name of CB] and other CBs involved shall settle all payments simultaneously on the PM accounts of the TARGET2 participants concerned.
Ha e számítások és ellenőrzések eredménye minden PM-számla tekintetében pozitív, a(z) [a KB neve beillesztendő] és más érintett KB-k egyidejűleg kiegyenlítik az összes fizetést az érintett TARGET2-résztvevők PM-számláin.
Under Algorithm 2 (“partial”) the [insert name of CB] shall:
A 2. sz. algoritmus (»részleges«) alapján a(z) [a KB neve beillesztendő] a következőket teszi:
calculate and check the liquidity positions, limits and reservations of each relevant PM account as under Algorithm 1; and
i. az 1. sz. algoritmusban megadottak szerint kiszámítja és ellenőrzi minden egyes PM-számla likviditási pozícióját, limitjeit és elkülönített likviditását; és
if the total liquidity position of one or more relevant PM accounts is negative, extract single payment orders until the total liquidity position of each relevant PM account is positive.
ha egy vagy több PM-számla teljes likviditási pozíciója negatív, a kiegyenlítési körből elhagy egyesével fizetési megbízásokat mindaddig, amíg minden PM-számla teljes likviditási pozíciója pozitív nem lesz.
Thereafter, the [insert name of CB] and the other CBs involved shall, provided there are sufficient funds, settle all remaining payments (except the extracted payment orders) simultaneously on the PM accounts of the TARGET2 participants concerned.
Ezt követően a(z) [a KB neve beillesztendő] és a többi érintett KB, amennyiben elegendő fedezet áll rendelkezésre, egyidejűleg elszámolja az összes fennmaradó fizetést (a kihagyott fizetési megbízások kivételével) az érintett TARGET2-résztvevők PM-számláin.
When extracting payment orders, the [insert name of CB] shall start from the TARGET2 participant’s PM account with the highest negative total liquidity position and from the payment order at the end of the queue with the lowest priority.
A fizetési megbízások elhagyását a(z) [a KB neve beillesztendő] a legnagyobb negatív teljes likviditási pozícióval rendelkező TARGET2-résztvevő PM-számlájával és a legalacsonyabb prioritású sor végén álló fizetési megbízással kezdi.
The selection process shall only run for a short time, to be determined by the [insert name of CB] at its discretion.
A kiválasztási folyamat csak a(z) [a KB neve beillesztendő] által meghatározott, rövid ideig fut.
Under Algorithm 3 (“multiple”) the [insert name of CB] shall:
A 3. sz. algoritmus (»multiple«) alapján a(z) [a KB neve beillesztendő] a következőket teszi:
compare pairs of TARGET2 participants’ PM accounts to determine whether queued payment orders can be settled within the available liquidity of the two TARGET2 participants’ PM accounts concerned and within the limits set by them (by starting from the pair of PM accounts with the smallest difference between the payment orders addressed to each other), and the CB(s) involved shall book those payments simultaneously on the two TARGET2 participants’ PM accounts; and
i. összeveti a TARGET2-résztvevők PM-számlapárjait annak meghatározására, hogy a sorban lévő fizetési megbízások elszámolhatók-e a két érintett TARGET2-résztvevő PM-számláján rendelkezésre álló likviditásán és az általuk megállapított limiteken belül (kezdve azokkal a PM-számlapárokkal, amelyek esetében a legkisebb az egymásnak címzett fizetési megbízások különbsége), és az érintett KB(-k) egyidejűleg lekönyveli(k) ezeket a fizetéseket a két TARGET2-résztvevő PM-számláin; és
if, in relation to a pair of PM accounts as described under point (i), liquidity is insufficient to fund the bilateral position, extract single payment orders until there is sufficient liquidity.
ha az i. pontban leírtak szerint a két PM-számla viszonyában a likviditás nem elegendő a kétoldalú pozíció finanszírozására, mindaddig elhagy egyenként fizetési megbízásokat, amíg elegendő likviditás nem áll rendelkezésre.
In this case the CB(s) involved shall settle the remaining payments, except the extracted ones, simultaneously on the two TARGET2 participants’ PM accounts.
Ebben az esetben az érintett KB(-k) egyidejűleg elszámolja (elszámolják) a fennmaradó fizetéseket (a kivontak kivételével) a két TARGET2 résztvevő PM-számláin.
After performing the checks specified under subparagraphs (i) to (ii), the [insert name of CB] shall check the multilateral settlement positions (between a participant’s PM account and other TARGET2 participants’ PM accounts in relation to which a multilateral limit has been set).
Az i–ii. pontban meghatározott ellenőrzések végrehajtását követően a(z) [a KB neve beillesztendő] ellenőrzi a többoldalú kiegyenlítési pozíciókat (a résztvevő PM-számlája és más TARGET2 résztvevők olyan PM-számlái vonatkozásában, amelyek tekintetében többoldalú limit került meghatározásra).
For this purpose, the procedure described under subparagraphs (i) to (ii) shall apply mutatis mutandis.
Ebből a célból megfelelően alkalmazni kell az i–ii. pontban ismertetett eljárást.
Under Algorithm 4 (“partial plus ancillary system settlement”) the [insert name of CB] shall follow the same procedure as for Algorithm 2, but without extracting payment orders in relation to the settlement of an ancillary system (which settles on a simultaneous multilateral basis).
A 4. sz. algoritmus alapján (»részleges, valamint kapcsolódó rendszerekkel való kiegyenlítések«) a(z) [a KB neve beillesztendő] ugyanazt az eljárást követi, mint a 2. sz. algoritmus esetében, de anélkül, hogy kihagyna fizetési megbízásokat a kapcsolódó rendszerrel való kiegyenlítés vonatkozásában (amely párhuzamos többoldalú alapon számol el).