natgillin/translations-raw huggingface dataset:
Payment orders sent to a participant using Internet-based access should identify that receiving participant in the beneficiary institution field .
Platobné príkazy poslané účastníkovi , ktorý využíva prístup prostred ­ níctvom internetu , by mali označiť tohto prijímajúceho účastníka v poli pre príjemcu .
Payment orders made by a participant using Internet-based access will identify that participant as the ordering institution .
V platobných príkazoch uskutočnených účastníkom , ktorý využíva prístup prostredníctvom internetu , sa tento účastník označí ako príkazca .
( 3 ) 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 » .
3 . Účastníci , ktorí využívajú prístup prostredníctvom internetu , používajú služby infraštruktúry verejného kľúča , ako sú vymedzené v ‚Návode na požívanie prístupu prostredníctvom internetu na účely služby overovania prostredníc ­ tvom verejného kľúča » ( User Manual : Internet Access for the public-key certification service ) .
Payment message types ( 1 ) Internet-based participants can make the following types of payments : ( a ) customer payments , i.e. credit transfers for which the ordering and / or beneficiary customer are not financial institutions ;
Druhy platobných správ 1 . Účastníci , ktorí využívajú prístup prostredníctvom internetu , môžu uskutočňovať tieto typy platieb : a ) klientské platby , t. j. príkazy na úhradu , v prípade ktorých klient , ktorý je príkazcom , a / alebo klient , ktorý je príjemcom , nie je finančnou inštitúciou ;
( b ) 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 ;
b ) platby klientov typu STP , t. j. príkazy na úhradu , v prípade ktorých klient , ktorý je príkazcom , a / alebo klient , ktorý je príjemcom , nie je finančnou inštitúciou , a ktoré sa vykonávajú prostredníctvom modulu automatic ­ kého spracovania ;
( c ) bank-to-bank transfers to request the movement of funds between financial institutions ;
c ) medzibankové prevody za účelom vyžiadania presunu prostriedkov medzi finančnými inštitúciami ;
( d ) cover payments to request the movement of funds between financial institutions related to an underlying customer credit transfer .
d ) krycie platby za účelom vyžiadania presunu prostriedkov medzi finančnými inštitúciami , ktoré sa viažu na podkladové klientské príkazy na úhradu .
In addition , participants using Internet-based access to a PM account can receive direct debit orders .
Účastníci , ktorí využívajú prístup k PM účtu prostredníctvom internetu , môžu naviac prijímať príkazy na inkaso .
( 2 ) Participants shall comply with the field specifications , as defined in Chapter 9.1.2.2 of the UDFS , Book 1 .
2 . Účastníci dodržiavajú špecifikáciu polí , ako je vymedzená v kapitole 9.1.2.2 UDFS , knihe 1 .
( 3 ) Field contents shall be validated at the level of TARGET2 - [ insert country / CB reference ] in accordance with the UDFS requirements .
3 . Obsah polí sa potvrdí na úrovni TARGET2 - [ vložiť odkaz na CB / krajinu ] v súlade s požiadavkami UDFS .
However , in TARGET2 - [ insert country / CB reference ] there shall be no specific checks as to whether participants comply with any such rules .
V TARGET2 - [ vložiť odkaz na krajinu / CB ] však nie sú žiadne špecifické kontroly plnenia týchto pravidiel zo strany účastníkov .
( 4 ) Participants using Internet-based access may make cover payments via TARGET2 , i.e. payments made by corre ­ spondent banks to settle ( cover ) credit transfer messages which are submitted to a customer 's bank by other , more direct means .
4 . Účastníci , ktorí využívajú prístup prostredníctvom internetu , môžu uskutočňovať krycie platby cez TARGET2 , t. j. platby uskutočňované korešpondenčnými bankami na vybavenie ( krytie ) správ o úhrade , ktoré sú zadané banke klienta inými , priamejšími spôsobmi .
Customer details contained in these cover payments shall not be displayed in the ICM .
Údaje o klientovi obsiahnuté v týchto krycích platbách nebudú zobrazené v ICM .
( 2 ) The following fields of the message types shall be checked :
2 . Kontrolujú sa tieto polia jednotlivých typov správ :
Part of the message Field
Časť správy
Sender Message Type Receiver Transaction Reference Number ( TRN ) Related Reference Value Date Amount
Odosielateľ Typ správy Adresát Referenčné číslo transakcie ( TRN ) Súvisiace informácie Deň valuty Suma
Basic Header Application Header Application Header Text Block Text Block Text Block Text Block
Základné záhlavie Záhlavie aplikácie Záhlavie aplikácie Text Text Text Text
BIC Address Message Type Destination Address : 20 : 21 : 32 : 32
Adresa BIC Typ správy Adresa určenia : 20 : 21 : 32 : 32
( 3 ) 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 .
3 . V prípade , ak všetky polia uvedené v pododseku 2 , ktoré sa týkajú novozadaných platobných príkazov , sú rovnaké ako tie , ktoré sa týkajú už prijatého platobného príkazu , novozadaný platobný príkaz sa vráti .
Error codes 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 .
Kódy chýb V prípade , ak je platobný príkaz odmietnutý , účastník dostane prostredníctvom ICM oznámenie o zrušení , ktoré obsahuje dôvody odmietnutia vyjadrené použitím kódov chýb .
Predetermined settlement times ( 1 ) For payment orders using the Earliest Debit Time Indicator , the codeword « / FROTIME / » shall be used .
Vopred stanovené časy zúčtovania 1 . Kód ‚ / FROTIME / » sa použije pre platobné príkazy používajúce indikátor najskoršieho času zaúčtovania na ťarchu účtu .
( 2 ) For payment orders using the Latest Debit Time Indicator , two options shall be available .
2 . Pre platobné príkazy používajúce indikátor najneskoršieho času zaúčtovania na ťarchu účtu sú k dispozícii dve možnosti :
( a ) Codeword « / REJTIME / » : if the payment order cannot be settled by the indicated debit time , the payment order shall be returned .
a ) Kód ‚ / REJTIME / » : v prípade , ak platobný príkaz nemôže byť zúčtovaný do času stanoveného na zaúčtovanie na ťarchu účtu , platobný príkaz sa odmietne .
( b ) Codeword « / TILTIME / » : 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 .
b ) Kód ‚ / TILTIME / » : v prípade , ak platobný príkaz nemôže byť zúčtovaný do času stanoveného na zaúčtovanie na ťarchu účtu , platobný príkaz sa nevráti , ale zostane zaradený v príslušnom čakacom rade .
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 .
Pri oboch možnostiach , v prípade ak platobný príkaz s indikátorom najneskoršieho času zaúčtovania na ťarchu účtu nie je zúčtovaný 15 minút pred časom v ňom stanoveným , oznámenie sa automaticky zašle prostredníctvom ICM .
( 3 ) 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 ) .
Ak sa použije kód ‚ / CLSTIME / » , s platbou sa naloží rovnako ako s platobným príkazom uvedeným v pododseku 2 písm . b ) .
Settlement of payment orders in the entry disposition ( 1 ) 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 .
Zúčtovanie platobných príkazov vo vstupnej dispozícii 1 . Kontroly možnosti započítania , prípadne rozšírené kontroly možnosti započítania ( oba pojmy sú vymedzené v odsekoch 2 a 3 ) sa vykonávajú na platobných príkazoch zaradených do vstupnej dispozície na účely rýchleho hrubého zúčtovania platobných príkazov s využitím minimálnej likvidity .
( 2 ) 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 ") .
2 . Kontrola možnosti započítania určí , či platobné príkazy príjemcu platby , ktoré sú v čakacom rade pred veľmi naliehavými platobnými príkazmi alebo , ak to nie je možné použiť , naliehavými platobnými príkazmi , je možné započítať voči platobnému príkazu platcu ( ďalej len ‚platobné príkazy s možnosťou započítania ') .
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 .
V prípade , ak platobný príkaz s možnosťou započítania neposkytuje dostatok peňažných prostriedkov vzhľadom na príslušný platobný príkaz platcu vo vstupnej pozícii , určí sa , či je dostatok dostupnej likvidity na PM účte platcu .
( 3 ) If the offsetting check fails , the [ insert name of CB ] may apply an extended offsetting check . 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 .
3 . V prípade , ak sa kontrola možnosti započítania neuskutoční , [ vložiť názov CB ] môže uplatniť rozšírenú kontrolu možnosti započítania .
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 .
Rozšírená kontrola možnosti započítania určí , či sú platobné príkazy s možnosťou zapo ­ čítania k dispozícii v akomkoľvek čakacom rade príjemcu platby bez ohľadu na ich zaradenie do čakacieho radu . V prípade , ak sú v čakacom rade príjemcu platby platobné príkazy s vyššou prioritou určené iným účastníkom TARGET2 , princíp FIFO môže byť porušený iba v prípade , ak by zúčtovanie takéhoto započítateľného platobného príkazu viedlo k zvýšeniu likvidity príjemcu platby .
Settlement of payment orders in the queue ( 1 ) The treatment of payment orders placed in queues depends on the priority class to which it was designated by the instructing participant .
Zúčtovanie platobných príkazov v čakacom rade 1 . Spôsob spracovania platobných príkazov v čakacích radoch závisí od prioritnej triedy , ktorú im určil zadávajúci účastník .
( 2 ) 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 ) .
2 . Platobné príkazy v čakacích radoch veľmi naliehavých platobných príkazov a naliehavých platobných príkazov sú zúčtované formou kontrol možností započítania podľa odseku 6 , pričom sa začína s platobným príkazom na začiatku čakacieho radu v prípadoch zvýšenej likvidity alebo intervencie na úrovni čakacieho radu ( zmena pozície v čakacom rade , čas zúčtovania alebo priorita , alebo odvolanie platobného príkazu ) .
( 3 ) 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 .
3 . Platobné príkazy v bežnom čakacom rade sa zúčtovávajú priebežne , vrátane všetkých veľmi naliehavých platob ­ ných príkazov a naliehavých platobných príkazov , ktoré ešte neboli zúčtované .
To optimise the settlement of highly urgent ancillary system transactions on participants » sub-accounts , a special algorithm ( Algorithm 5 ) shall be used .
Na účely optimalizácie zúčtovania veľmi naliehavých transakcií v pridružených systémoch na podúčtoch účastníka sa použije osobitný algoritmus ( algo ­ ritmus č . 5 ) .
( a ) 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 : ( i ) 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 ( ii ) check whether limits and reservations set by each TARGET2 participant in relation to each relevant PM account are respected .
a ) Podľa algoritmu č . 1 ( ‚všetko alebo nič ') [ vložiť názov CB ] pre každý vzťah , pre ktorý bol stanovený bilaterálny limit , a tiež pre celkové množstvo vzťahov , pre ktoré bol stanovený mnohostranný limit : i ) vypočíta súhrnný stav likvidity každého PM účtu účastníka TARGET2 tak , že zistí , či súčet všetkých odchádzajúcich a prichádzajúcich platobných príkazov čakajúcich v čakacom rade je záporný alebo kladný , a ak je záporný , skontroluje , či prevyšuje účastníkovu dostupnú likviditu ( súhrnný stav likvidity vytvorí ‚celkový stav likvidity ') , a ii ) skontroluje , či sú dodržané limity a rezervácie stanovené každým účastníkom TARGET2 vo vzťahu ku každému príslušnému PM účtu .
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 .
V prípade , ak je výsledok týchto výpočtov a kontrol kladný pre každý PM účet , [ vložiť názov CB ] a iné dotknuté centrálne banky zúčtujú súčasne všetky platby na PM účtoch dotknutých účastníkov TARGET2 .
( b ) Under Algorithm 2 (" partial ") the [ insert name of CB ] shall : ( i ) calculate and check the liquidity positions , limits and reservations of each relevant PM account as under Algorithm 1 ;
b ) Podľa algoritmu č . 2 ( ‚čiastkový ') [ vložiť názov CB ] : i ) vypočíta a skontroluje stav likvidity , limity a rezervácie likvidity každého príslušného PM účtu tak , ako podľa algoritmu č .
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 .
[ vložiť názov CB ] a iné dotknuté centrálne banky potom za predpokladu , že je k dispozícii dostatok prostriedkov , zúčtujú súčasne všetky zostávajúce platby ( okrem vyradených platobných príkazov ) na PM účtoch príslušných účastníkov TARGET2 .
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 .
Pri vyraďovaní platobných príkazov začne [ vložiť názov CB ] od PM účtu účastníka TARGET2 s najvyšším záporným celkovým stavom likvidity a od platobného príkazcu na konci čakacieho radu s najnižšou prioritou .
( c ) Under Algorithm 3 (" multiple ") the [ insert name of CB ] shall : ( i ) 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
3 ( ‚viacnásobný ') [ vložiť názov CB ] : i ) porovná dvojice PM účtov účastníkov TARGET2 na účely určenia možnosti zúčtovania platobných príkazov v čakacom rade s dostupnou likviditou dvoch dotknutých PM účtov účastníkov TARGET2 a v rámci nimi stanovených limitov ( začínajúc dvojicou PM účtov s najmenším rozdielom medzi vzájomnými platobnými príkazmi ) ; a dotknutá (- é ) CB ( centrálne banky ) zaúčtuje (- ú ) tieto platby súčasne na PM účty dvoch účast ­ níkov TARGET2 , a
( ii ) 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 .
ii ) ak v prípade dvojice PM účtov podľa bodu i ) likvidita nie je dostatočná na krytie bilaterálnej pozície , vyraďuje jednotlivé platobné príkazy , až kým nie je likvidita dostatočná .
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 ) .
Po vykonaní kontrol uvedených v bodoch i ) a ii ) , [ vložiť názov CB ] skontroluje multilaterálne zúčtovacie pozície ( medzi PM účtom účastníka a inými PM účtami účastníkov TARGET2 , pre ktorých bol stanovený multilaterálny limit ) .
( d ) 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 ) .
4 ( ‚čiastkový a pridružený systém zúčtovania ') [ vložiť názov CB ] postupuje rovnakým spôsobom ako pri algoritme č . 2 , avšak bez vyraďovania platobných príkazov týkajúcich sa zúčtovania pridružených systémov ( ktoré zúčtováva súčasne medzi viacerými stranami ) .
( e ) Under Algorithm 5 (" ancillary system settlement via sub-accounts ") the [ insert name of CB ] shall follow the same procedure as for Algorithm 1 , subject to the modification that the [ insert name of CB ] shall start Algorithm 5 via the Ancillary System Interface and shall only check whether sufficient funds are available on participants » sub-accounts .
5 ( ‚pridružený systém zúčtovania prostredníctvom podúčtov ') [ vložiť názov CB ] postupuje rovnako ako pri algoritme č . 1 s prihliadnutím na rozdiel , že [ vložiť názov CB ] začne algoritmus č .
Algorithm 5 shall also run during night-time settlement .
Algoritmus č . 5 prebieha tiež počas nočného zúčtovania .
( 4 ) Payment orders entered into the entry disposition after the start of any of algorithms 1 to 4 may nevertheless be settled immediately in the entry disposition if the positions and limits of the TARGET2 participants » PM accounts concerned are compatible with both the settlement of these payment orders and the settlement of payment orders in the current optimisation procedure .
Platobné príkazy , ktoré sú zaradené do vstupnej dispozície po začiatku ktoréhokoľvek z algoritmov č . 1 až 4 , môžu byť napriek tomu okamžite zúčtované vo vstupnej dispozícii v prípade , ak pozície a limity príslušných PM účtov účastníkov TARGET2 sú zlučiteľné tak so zúčtovaním týchto platobných príkazov , ako aj so zúčtovaním platobných príkazov v prebiehajúcom optimalizačnom postupe .
( 5 ) During daytime processing the algorithms shall run sequentially .
5 . Počas denného spracovania prebiehajú algoritmy postupne .
As long as there is no pending simultaneous multilateral settlement of an ancillary system , the sequence shall be as follows : ( a ) algorithm 1 ;
Pokiaľ nie je potrebné vykonať simultánne multilate ­ rálne zúčtovanie pridruženého systému , postupnosť je takáto : a ) algoritmus č . 1 ;
( b ) if algorithm 1 fails , then algorithm 2 ;
b ) ak algoritmus č . 1 zlyhá , následne algoritmus č .
( c ) if algorithm 2 fails , then algorithm 3 , or if algorithm 2 succeeds , repeat algorithm 1 .
c ) ak algoritmus č . 2 zlyhá , následne algoritmus č .
When simultaneous multilateral settlement (' procedure 5 ') in relation to an ancillary system is pending , Algorithm 4 shall run .
Pokiaľ je potrebné vykonať simultánne multilaterálne zúčtovanie ( ‚postup č . 5 ') pridruženého systému , prebieha algoritmus č .
( 6 ) The algorithms shall run flexibly by setting a pre-defined time lag between the application of different algorithms to ensure a minimum interval between the running of two algorithms .
6 . S cieľom zabezpečiť minimálny časový odstup medzi dvoma prebiehajúcimi algoritmami , algoritmy prebiehajú flexibilne tak , že sa vopred stanoví časové obdobie medzi spustením jednotlivých algoritmov .
( 7 ) While included in a running algorithm , a payment order shall not be reordered ( change of the position in a queue ) or revoked .
7 . Platobnému príkazu nemožno zmeniť poradie ( zmena pozície v čakacom rade ) a ani ho nemožno odvolať , ak je predmetom prebiehajúceho algoritmu .
If the payment order concerned is settled while the algorithm is running , any request to reorder or revoke shall be rejected .
Ak je príslušný platobný príkaz zúčtovaný počas prebie ­ hajúceho algoritmu , akákoľvek požiadavka na zmenu poradia alebo odvolanie sa odmietne .
If the payment order is not settled , the participant 's requests shall be taken into account immediately .
Ak platobný príkaz nie je zúčtovaný , požiadavky účastníka sa zohľadnia okamžite .
Use of the ICM ( 1 ) The ICM may be used for inputting payment orders .
Používanie ICM 1 . ICM je možné použiť na zadávanie platobných príkazov .
( 2 ) The ICM may be used for obtaining information and managing liquidity .
2 . ICM je možné použiť na získavanie informácii a riadenie likvidity .
( 3 ) With the exception of warehoused payment orders and static data information , only data in relation to the current business day shall be available via the ICM .
3 . S výnimkou uložených platobných príkazov a statických údajov sú prostredníctvom ICM k dispozícii iba údaje týkajúce sa bežného pracovného dňa .
( 4 ) Information shall be provided in « pull » mode , which means that each participant has to ask to be provided with information .
4 . Informácie sa poskytujú v ‚pull » režime ( stiahnutie informácie na základe iniciatívy účastníka ) , čo znamená , že každý účastník musí o poskytnutie informácie požiadať .
Participants shall check the ICM regularly throughout the business day for important messages .
Účastníci kontrolujú pravidelne počas pracovných dní , či sa v ICM nezobrazujú dôležité správy .
( 5 ) Only user-to-application mode ( U2A ) shall be available for participants using Internet-based access .
5 . Pre účastníkov , ktorí využívajú prístup prostredníctvom internetu , je k dispozícii len režim ‚od užívateľa k aplikácii » ( U2A ) .
U2A permits direct communication between a participant and the ICM .
U2A umožňuje priamu komunikáciu medzi účastníkom a ICM .
The information is displayed in a browser running on a PC .
Informácia sa zobrazuje v prehliadači spustenom na počítači .
( 6 ) Each participant shall have at least one workstation with Internet access to access the ICM via U2A .
6 . Každý účastník má na prístup k ICM prostredníctvom U2A k dispozícii najmenej jednu pracovnú stanicu pripojenú na internet .
( 7 ) Access rights to the ICM shall be granted by using certificates , the use of which is described more fully in paragraphs 10 to 13 .
7 . Prístupové práva do ICM sa poskytnú použitím certifikátov , pričom ich použitie je v plnom znení opísané v odsekoch 10 až 13 .
( 8 ) Participants may also use the ICM to transfer liquidity : ( a ) [ insert if applicable ] from their PM account to their account outside the PM ;
8 . Účastníci môžu tiež použiť ICM na prevod likvidity : a ) [ vložiť v prípade potreby ] z ich PM účtu na ich účet mimo PM ;