natgillin/translations-raw huggingface dataset:
Deltagere der anvender internetbaseret adgang kan foretage dækningsbetalinger via TARGET2, dvs. betalinger der er foretaget af korrespondentbanker til at afvikle (dække) kreditoverførselsmeddelelser, der er fremsendt til en kundes bank på andre og mere direkte måder.
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.
Kundeoplysningerne i disse dækningsbetalinger vises ikke i ICM-modulet.
Customer details contained in these cover payments shall not be displayed in the ICM.
Dobbelt ordre kontrol
Double-entry check
Alle betalingsordrer skal igennem en dobbeltordre kontrol, som har til formål at returnere betalingsordrer, som ved en fejl er afgivet mere end én gang.
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.
Følgende felter i meddelelsestyperne kontrolleres:
The following fields of the message types shall be checked:
Detaljer
Details
Afsender
Sender
Modtager
Receiver
Transaktion Reference Nummer (TRN)
Transaction Reference Number (TRN)
Tekst Blok
Text Block
Relateret Reference
Related Reference
Valør Dato
Value Date
Hvis felterne beskrevet i stk. 2 i forbindelse med en senere afgivet betalingsordre er identisk med felterne i en allerede accepteret betalingsordre, returneres den senere afgivne betalingsordre som uafviklet.
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.
Fejlkoder
Error codes
Hvis en betalingsordre returneres som uafviklet, afgives en fejlmeddelelse, som angiver årsagen til returneringen ved anvendelse af fejlkoder.
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.
Fejlkoderne er defineret i kapitel 9.4.2 i UDFS.
The error codes are defined in Chapter 9.4.2 of the UDFS.
På forhånd fastsatte afviklingstidspunkter
Predetermined settlement times
For betalingsordrer, som anvender Earliest Debit Time Indicator, anvendes kodeordet »/FROTIME/«.
For payment orders using the Earliest Debit Time Indicator, the codeword “/FROTIME/” shall be used.
For betalingsordrer, som anvender Latest Debit Time Indicator, er der to mulige kodeord.
For payment orders using the Latest Debit Time Indicator, two options shall be available.
Kodeordet »/REJTIME/«
Codeword “/REJTIME/”
hvis betalingsordren ikke kan afvikles på det angivne debiteringstidspunkt, returneres betalingsordren som uafviklet.
if the payment order cannot be settled by the indicated debit time, the payment order shall be returned.
Kodeordet »/TILTIME/«
Codeword “/TILTIME/”
hvis betalingsordren ikke kan afvikles på det angivne debiteringstidspunkt, returneres betalingsordren ikke, men opretholdes i den relevante kø.
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.
I begge tilfælde bliver en meddelelse automatisk sendt via ICM, hvis en betalingsordre med Latest Debit Time Indicator ikke er afviklet 15 minutter forud for det deri angivne tidspunkt.
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.
Hvis kodeordet »/CLSTIME/« er anvendt, behandles betalingen på samme måde som en betalingsordre, nævnt i stk. 2, litra b).
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).
Der gennemføres modregningskontrol, og — hvis relevant — udvidet modregningskontrol (begge udtryk som defineret i stk. 2 og 3) af betalingsordrer, som er indført i entry disposition, for at sikre en hurtig og likviditetsbesparende bruttoafvikling af betalingsordrer.
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.
En modregningskontrol skal fastslå, hvorvidt betalingsmodtagerens betalingsordrer, som er forrest i den meget hastende kø (highly urgent queue) eller, hvis ikke relevant, i den hastende kø (urgent queue), er til rådighed til modregning i betalerens betalingsordre (herefter: »modregnende betalingsordrer«).
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”).
Hvis en modregnende betalingsordre ikke giver tilstrækkelige midler til den pågældende betalers betalingsordre i entry disposition, afgøres det, om der er tilstrækkelig likviditet til rådighed på betalerens PM-konto.
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.
Hvis modregningskontrollen ikke lykkes, kan [indsæt centralbankens navn] anvende den udvidede modregningskontrol.
If the offsetting check fails, the [insert name of CB] may apply an extended offsetting check.
Ved en udvidet modregningskontrol fastslås det, hvorvidt der er modregnede betalingsordrer til rådighed i nogen af betalingsmodtagerens køer, uden hensyn til, hvornår de kom i køen.
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.
Hvis der i betalingsmodtagerens kø er betalingsordrer med højere prioritet, som er adresseret til andre TARGET2 deltagere, kan FIFU-princippet dog kun fraviges, såfremt afvikling af en sådan modregnende betalingsordre vil medføre en likviditetsforøgelse for betalingsmodtageren.
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.
Afvikling af betalingsordrer i køen
Settlement of payment orders in the queue
Behandlingen af betalingsordrer i kø, afhænger af den prioritetskategori, som den ordregivende deltager har angivet.
The treatment of payment orders placed in queues depends on the priority class to which it was designated by the instructing participant.
Betalingsordrer i den meget hastende og i den hastende kø afvikles ved anvendelse af modregningskontrollen beskrevet i stk. 6, idet der begyndes med betalingsordren forrest i køen i de tilfælde, hvor der sker en forøgelse af likviditeten, eller hvor der foretages indgriben i køen (ændring af placering i køen, afviklingstidspunkt eller -prioritet, eller tilbagekaldelse af betalingsordren).
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).
Betalingsordrer i den normale kø afvikles løbende, herunder alle meget hastende og hastende betalingsordrer, som endnu ikke er afviklet.
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.
Der anvendes forskellige optimeringsmekanismer (algoritmer).
Different optimisation mechanisms (algorithms) are used.
Hvis en algoritme lykkes, bliver de omfattede betalingsordrer afviklet. Hvis en algoritme ikke lykkes, forbliver de omfattede betalingsordrer i køen.
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.
Der anvendes tre algoritmer (1 til 3) til modregning af betalingsstrømme.
Three algorithms (1 to 3) shall be applied to offset payment flows.
Afviklingsprocedure 5 (som denne er defineret i kapitel 2.8.1 i UDFS) kan — ved brug af algoritme 4 — anvendes til afvikling af afviklingssystemers betalingsordrer.
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.
For at optimere afviklingen af meget hastende transaktioner i afviklingssystemer på deltagernes afviklingskonti, anvendes en særlig algoritme (Algoritme 5).
To optimise the settlement of highly urgent ancillary system transactions on participants’ sub-accounts, a special algorithm (Algorithm 5) shall be used.
I Algoritme 1 (»all-or-nothing«) skal [indsæt centralbankens navn] for såvel alle modpartsforhold, for hvilke der er fastsat et bilateralt limit, som for de summen af modpartsforhold, for hvilke der er fastsat et multilateralt limit:
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:
beregne den samlede likviditetsposition for hver TARGET2 deltagers PM-konto ved at fastslå, hvorvidt den samlede sum af alle udgående og indgående betalingsordrer, som venter i køen, er negativ eller positiv, samt — såfremt den er negativ — kontrollere, om den overstiger den pågældende deltagers disponible likviditet (den samlede likviditet skal udgøre den »totale likvidetetsposition«), og
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
kontrollere, om limits og reserveringer, som er fastsat af hver TARGET2 deltager i relation til hver relevant PM-konto, overholdes.
check whether limits and reservations set by each TARGET2 participant in relation to each relevant PM account are respected.
Hvis resultatet af disse beregninger og kontroller er positivt for hver relevant PM- konto, skal [indsæt centralbankens navn] og andre centralbanker, som er involveret, afvikle alle betalinger samtidig på de pågældende TARGET2 deltageres PM-konti.
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.
Under Algoritme 2 (»partial«) skal [indsæt centralbankens navn]:
Under Algorithm 2 (“partial”) the [insert name of CB] shall:
beregne og kontrollere likviditetspositioner, limits og reservationer for hver relevant PM-konto, som under Algoritme 1, og
calculate and check the liquidity positions, limits and reservations of each relevant PM account as under Algorithm 1; and
hvis den samlede likviditetsposition på én eller flere relevante PM-konti er negativ, udtage enkelte betalingsordrer, indtil den samlede likviditetsposition på hver relevant PM-konto er positiv.
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.
Derefter skal [indsæt centralbankens navn] og de andre involverede centralbanker, i det omfang der er tilstrækkelige midler, afvikle alle tilbageværende betalinger (bortset fra de udtagne betalingsordrer) samtidig på de pågældende TARGET2 deltageres PM- konti.
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.
Ved udtagelse af betalingsordrer, begynder [indsæt centralbankens navn] med den TARGET2 deltagers PM-konto, som har den største negative likviditetsposition, og med den betalingsordre bagest i køen, som har lavest prioritet.
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.
Algoritmen løber kun i kort tid, som nærmere fastsat efter [indsæt centralbankens navn]'s skøn.
The selection process shall only run for a short time, to be determined by the [insert name of CB] at its discretion.
Under Algoritme 3 (»multiple«) skal [indsæt centralbankens navn]:
Under Algorithm 3 (“multiple”) the [insert name of CB] shall:
sammenligne TARGET2 deltageres PM-konti parvis for at fastslå, hvorvidt betalingsordrer i kø kan afvikles inden for den likviditet, som er til rådighed for de pågældende to TARGET2 deltageres PM-konti, og inden for de fastsatte limits, (idet der begyndes med det PM-konti par med den mindste forskel mellem betalingsordrer, som er adresseret til hinanden), og de(n) centralbank(er), som er involveret, bogfører disse betalinger samtidig hos de to TARGET2 deltageres PM-konti, og
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
såfremt der for et par PM-konti, som beskrevet under punkt i), ikke er tilstrækkelig likviditet til at finansiere den bilaterale position, udtage enkelte betalingsordrer, indtil der er tilstrækkelig likviditet.
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.
I dette tilfælde afvikler de(n) centralbank(er), som er involveret, de tilbageværende betalinger, (bortset fra de udtagne) samtidig på de to TARGET2 deltageres PM-konti.
In this case the CB(s) involved shall settle the remaining payments, except the extracted ones, simultaneously on the two TARGET2 participants’ PM accounts.
Efter gennemførelse af de kontroller, som er nævnt i underpunkt i) og ii), kontrollerer [indsæt centralbankens navn] de multilaterale afviklingspositioner (mellem en deltagers PM-konti og andre TARGET2 deltageres PM-konti, for hvilke der er sat multilaterale limits).
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).
Til brug herfor finder proceduren beskrevet i underpunkt i) til iii) tilsvarende anvendelse.
For this purpose, the procedure described under subparagraphs (i) to (ii) shall apply mutatis mutandis.
Under Algoritme 4 (»partial plus ancillary system settlement«) følger [indsæt centralbankens navn] samme procedure som for Algoritme 2, men uden at udtage betalingsordrer, der relaterer sig til afvikling i et afviklingssystem (idet disse afvikles samtidig og multilateralt).
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).
Under Algoritme 5 (»ancillary system settlement via sub-accounts«) følger [indsæt centralbankens navn] samme procedure som for Algoritme 1 med den ændring, at [indsæt centralbankens navn] starter Algoritme 5 via Ancillary System Interface og kun kontrollerer, hvorvidt der er tilstrækkelig midler til rådighed på deltagernes afviklingskonti.
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.
Der tages endvidere ikke hensyn til limits og reserveringer.
Moreover, no limits and reservations shall be taken into account.
Algoritme 5 løber også under natafvikling.
Algorithm 5 shall also run during night-time settlement.
Betalingsordrer, som er indført i entry disposition efter påbegyndelse af en af algoritmerne 1-4, kan dog afvikles straks i entry disposition, hvis positionerne og limits for de pågældende TARGET2 deltageres PM-konti er forenelige både med afvikling af disse betalingsordrer og med afvikling af betalingsordrer i den løbende optimeringsprocedure.
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.
To algoritmer må dog ikke løbe samtidig.
However, two algorithms shall not run simultaneously.
I dagfasen løber algoritmerne sekventielt.
During daytime processing the algorithms shall run sequentially.
Så længe der ikke er en udestående samtidig multilateral afvikling i et afviklingssystem, er rækkefølgen følgende:
As long as there is no pending simultaneous multilateral settlement of an ancillary system, the sequence shall be as follows:
algoritme 1
algorithm 1;
hvis algoritme 1 ikke lykkes, så algoritme 2
if algorithm 1 fails, then algorithm 2;
hvis algoritme 2 ikke lykkes, så algoritme 3, eller hvis algoritme 2 lykkes, gentagelse af algoritme 1.
if algorithm 2 fails, then algorithm 3, or if algorithm 2 succeeds, repeat algorithm 1.
Når der udestår en samtidig multilateral afvikling (»procedure 5«) i et afviklingssystem, skal Algoritme 4 løbe.
When simultaneous multilateral settlement (‘procedure 5’) in relation to an ancillary system is pending, Algorithm 4 shall run.
Algoritmerne skal løbe fleksibelt ved forhåndsfastsættelse af en tidsforsinkelse mellem anvendelsen af forskellige algoritmer, for derved at sikre et minimumsinterval mellem gennemførelse af to algoritmer.
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.
Tidssekvensen kontrolleres automatisk.
The time sequence shall be automatically controlled.
Der skal være mulighed for manuel indgriben.
Manual intervention shall be possible.
Når en betalingsordre er indeholdt i en løbende algoritme, må den ikke ændres (ændring af placering i en kø) eller tilbagekaldes.
While included in a running algorithm, a payment order shall not be reordered (change of the position in a queue) or revoked.
Anmodninger om ændring eller tilbagekaldelse af en betalingsordre placeres i kø, indtil algoritmen er færdig.
Requests for reordering or revocation of a payment order shall be queued until the algorithm is complete.
Hvis den pågældende betalingsordre afvikles som led i den løbende algoritme, afvises en anmodning om ændring eller tilbagekaldelse.
If the payment order concerned is settled while the algorithm is running, any request to reorder or revoke shall be rejected.
Hvis betalingsordren ikke bliver afviklet, bliver deltagerens anmodning straks taget i betragtning.
If the payment order is not settled, the participant’s requests shall be taken into account immediately.
ICM kan anvendes til afgivelse af betalingsordrer.
The ICM may be used for inputting payment orders.
ICM kan anvendes til at erhverve information og styre likviditet.
The ICM may be used for obtaining information and managing liquidity.
Bortset fra betalingsordrer, som er warehoused, og statisk data information, er det kun data i forbindelse med den aktuelle bankdag, der er tilgængelige via ICM.
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.
Der tilbydes kun skærme på engelsk.
The screens shall be offered in English only.
Information leveres i »pull« modus, dvs at hver deltager skal anmode om at få leveret information.
Information shall be provided in “pull” mode, which means that each participant has to ask to be provided with information.
Deltagere skal regelmæssigt i løbet af dagen kontrollere ICM for vigtige meddelelser.
Participants shall check the ICM regularly throughout the business day for important messages.
Kun user-to-application modus (U2A) er til rådighed for deltagere, der anvender internetbaseret adgang.
Only user-to-application mode (U2A) shall be available for participants using Internet-based access.
muliggør direkte kommunikation mellem en deltager og ICM.
permits direct communication between a participant and the ICM.
Informationen vises i en browser, som kører på et PC-system.
The information is displayed in a browser running on a PC.
ICM User Handbook indeholder yderligere detaljer.
Further details are described in the ICM User Handbook.
En deltager skal mindst have én arbejdsstation med internetadgang for at få adgang til ICM via U2A.
Each participant shall have at least one workstation with Internet access to access the ICM via U2A.
Adgangsrettigheder til ICM gives ved brug af certifikater, og brugen af disse er nærmere beskrevet i stk. 10-13.
Access rights to the ICM shall be granted by using certificates, the use of which is described more fully in paragraphs 10 to 13.
Deltagere kan også anvende ICM til at overføre likviditet:
Participants may also use the ICM to transfer liquidity:
[indsæt hvis relevant] fra deres PM-konto til deres konto uden for PM-modulet
[insert if applicable] from their PM account to their account outside the PM;
mellem PM-kontoen og deltagerens afviklingskonti, og
between the PM account and the participant’s sub-accounts; and
fra PM-kontoen til skyggekontoen, som administreres af afviklingssystemet.
from the PM account to the mirror account managed by the ancillary system.
UDSF og ICM User Handbook og »User Manual: Internet Access for the Public Key Certification Service«
The UDFS, the ICM User Handbook and the “User Manual: Internet Access for the Public Key Certification Service”
Yderligere oplysninger og eksempler, som forklarer ovennævnte regler, findes i den til enhver tid gældende UDFS- og ICM User Handbook, der er offentliggjort på engelsk på [indsæt centralbankens navn]'s og ECB's websted og i »User Manual:. Internet Access for the Public Key Certification Service«
Further details and examples explaining the above rules are contained in the UDFS and the ICM User Handbook, as amended from time to time and published on the [insert name of CB]’s website and the TARGET2 website in English, and in the “User Manual: Internet Access for the Public Key Certification Service”.
Udstedelse, suspension, reaktivering, tilbagekaldelse og fornyelse af certifikater
Issuance, suspension, reactivation, revocation and renewal of certificates
Deltagere skal anmode [indsæt centralbankens navn]] om udstedelse af certifikater, der giver dem mulighed for adgang til TARGET2 [indsæt centralbank/landereference] ved brug af internetbaseret adgang.
The participant shall request from [insert name of CB] the issuance of certificates to allow them to access TARGET2 [insert CB/country reference] using Internet-based access.