natgillin/translations-raw huggingface dataset:
Когато се използва индикаторът за най-късен момент за извършване на дебит, приетото платежно нареждане се връща като неизпълнено, ако към посочения момент на дебит не може да се извърши сетълмент.
When the Latest Debit Time Indicator is used, the accepted payment order shall be returned as non-settled if it cannot be settled by the indicated debit time.
Инструктиращият участник бива информиран чрез модула за информация и контрол, 15 минути преди определения момент на дебит, вместо да получава автоматично уведомление през модула за информация и контрол.
15 minutes prior to the defined debit time, the instructing participant shall be informed via the ICM, rather than sent an automatic notification via the ICM.
Инструктиращият участник може също да използва индикатора за най-късен момент за извършване на дебит само като предупреждаващ индикатор.
Instructing participant may also use the Latest Debit Time Indicator solely as a warning indicator.
В тези случаи съответното платежно нареждане не се връща.“
In such cases, the payment order concerned shall not be returned.”
Член 21, параграф 4 се заменя със следния текст:
Article 21(4) is replaced by the following:
По искане на платец, [Посочете името на ЦБ] може да реши да промени мястото в опашката на много спешно платежно нареждане (с изключение на много спешни платежни нареждания във връзка с процедури за сетълмент 5 и 6), при условие че тази промяна не засяга гладкото извършване на сетълмент от спомагателните системи в TARGET2 или не би довела по друг начин до системен риск.“
At the request of a payer, the [insert name of CB] may decide to change the queue position of a highly urgent payment order (except for highly urgent payment orders in the context of settlement procedures 5 and 6) provided that this change would not affect the smooth settlement by ancillary systems in TARGET2 or would not otherwise give rise to systemic risk.”
Член 28 се изменя, както следва:
Article 28 is modified as follows:
Участниците, използващи интернет базиран достъп, осъществяват адекватен контрол за сигурност, посочен в допълнение IА към приложение V, за да защитят системите си срещу неразрешен достъп и използване.
Participants using Internet-based access shall implement adequate security controls, in particular those specified in Appendix IA to Annex V, to protect their systems from unauthorised access and use.
Участниците носят изключителна отговорност за адекватната защита на поверителността, целостта и наличността на техните системи.“
Participants shall be exclusively responsible for the adequate protection of the confidentiality, integrity and availability of their systems.”
Участниците, използващи интернет базиран достъп, информират незабавно [посочете име на ЦБ] за всяко събитие, което може да засегне валидността на сертификатите и, по-специално, за събитията, посочени в допълнение IА към приложение V, като например загуба или неправомерно използване.“
Participants using Internet-based access shall inform [insert name of CB] immediately of any event that may affect the validity of the certificates, in particular those events specified in Appendix IA to Annex V, including without limitation any loss or improper use.”
Член 29 се заменя със следния текст:
Article 29 is replaced by the following:
„Член 29
“Article 29
Използване на модула за информация и контрол
Use of the ICM
Модулът за информация и контрол:
The ICM:
позволява на участниците да въвеждат плащания;
allows participants to input payments;
позволява на участниците да имат достъп до информация, свързана с техните сметки, и да управляват ликвидността;
allows participants to access information relating to their accounts and to manage liquidity;
може да се използва за иницииране на нареждания за прехвърляне на ликвидност; и
may be used to initiate liquidity transfer orders; and
позволява на участниците да осъществяват достъп до системни съобщения.
allows participants to access system messages.
Допълнителни технически подробности, свързани с използването на модула за информация и контрол във връзка с интернет базирания достъп, се съдържат в допълнение IА към приложение V.“
Further technical details relating to the ICM to be used in connection with Internet-based access are contained in Appendix IA to Annex V.”
Член 32 се изменя, както следва:
Article 32 is modified as follows:
Параграф 1 се заменя със следния текст:
Paragraph 1 is replaced with the following:
Освен ако в настоящите условия не е предвидено друго, всички плащания и съобщения, свързани с обработка на плащане във връзка с TARGET2, като например потвърждения за дебит или кредит, или извлечения от сметки, между [посочете име на ЦБ] и участниците, се правят достъпни за участниците в модула за информация и контрол.“
Unless otherwise provided in these Conditions, all payment and payment processing-related messages in relation to TARGET2, such as confirmations of debits or credits, or statement messages, between the [insert name of CB] and participants shall be made available for the participant on the ICM.”
Ако връзката на участника се разпадне, участникът използва алтернативните средства за предаване на съобщения, предвидени в допълнение IА към приложение V. В тези случаи запазената или разпечатана форма на съобщението, изготвено от [посочете име на ЦБ], има доказателствена сила.“
If a participant’s connection fails, the participant shall use the alternative means of transmission of messages laid down in Appendix IA to Annex V. In such cases, the saved or printed version of the message produced by the [insert name of CB] shall be accepted as evidence.”
Член 34, параграф 4, буква в) се заменя със следното:
Article 34(4)(c) is replaced by the following:
След като съобщение, излъчено от модула за информация и контрол, е направено достъпно за участници, използващи интернет базиран достъп, последните се считат за уведомени относно прекратяването/временното спиране на участието на участника в TARGET2-[посочете ЦБ) държава] или в друг системен компонент на TARGET2.
Once such an ICM broadcast message has been made available to participants using Internet-based access, those participants shall be deemed informed of the termination/- suspension of a participant’s participation in TARGET2-[insert CB/country reference] or another TARGET2 component system.
Участниците понасят загубите, възникнали от подаването на платежно нареждане до участници, чието участие е било временно спряно или прекратено, ако платежното нареждане е въведено в TARGET2-[посочете ЦБ) държава] след като съобщението, излъчено от модула за информация и контрол, е направено достъпно.“
The participants shall bear any losses arising from the submission of a payment order to participants whose participation has been suspended or terminated if such payment order was entered into TARGET2-[insert CB/country reference] after the ICM broadcast message was made available.”
Преди да влязат в договорно отношение с доставчик на интернет услуги, участниците, използващи интернет базиран достъп, се запознават с политиката на доставчика на интернет услуги за възстановяване на данни.“
Prior to entering into a contractual relationship with an Internet service provider, participants using Internet-based access shall acquaint themselves with that Internet service provider’s data retrieval policy.”
Член 40, параграф 1 се заменя със следния текст:
Article 40(1) is replaced by the following:
Освен когато в настоящите условия е предвидено друго, всички уведомления, които се изискват или допускат съгласно настоящите условия, се изпращат чрез препоръчана поща, факсимиле или по друг начин в писмена форма.
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.
Уведомленията до [посочете име на ЦБ] се изпращат до ръководителя на [посочете дирекцията за платежни системи или съответния отдел на ЦБ] на [посочете име на ЦБ], [посочете съответния адрес на ЦБ] или на [добавете BIC адреса на ЦБ].
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].
Уведомления до участника се изпращат на адреса му, по факса или на BIC адреса му, които участникът съобщава периодично на [посочете име на ЦБ].“
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].”
Член 45 се заменя със следния текст:
Article 45 is replaced by the following:
„Член 45
“Article 45
Ограничаване
Severability
Ако някоя от разпоредбите в настоящите условия или в приложение V е или стане невалидна, това не засяга приложимостта на останалите разпоредби от настоящите условия или на приложение V.“
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.”
Допълнение IА
Appendix IA
ТЕХНИЧЕСКИ СПЕЦИФИКАЦИИ ЗА ОБРАБОТКА НА ПЛАТЕЖНИ НАРЕЖДАНИЯ ПРИ ИНТЕРНЕТ БАЗИРАН ДОСТЪП
TECHNICAL SPECIFICATIONS FOR THE PROCESSING OF PAYMENT ORDERS FOR INTERNET-BASED ACCESS
Освен Условията, при обработката на платежни нареждания с използване на интернет базиран достъп се прилагат следните правила:
In addition to the Conditions, the following rules shall apply to the processing of payment orders using Internet-based access:
Технически изисквания за участие в TARGET2-[посочете ЦБ/държава] относно инфраструктурата, мрежата и форматите
Technical requirements for participation in TARGET2-[insert CB/country reference] regarding infrastructure, network and formats
Всеки участник, използващ интернет базиран достъп, е задължен да се свърже с модула за информация и контрол на TARGET2 като използва местен клиент, операционна система и интернет браузър съгласно приложение „Интернет базирано участие — изисквания на системата за интернет достъп“ („Internet-based participation — System requirements for Internet access“) към Подробните функционални спецификации за потребителите (UDFS), с определени настройки.
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.
Всяка сметка в платежния модул на участник се идентифицира чрез осем- или единадесетцифрен BIC код.
Each participant’s PM account shall be identified by an eight- or 11-digit BIC.
Освен това всеки участник трябва да премине успешно поредица от тестове за доказване на неговата техническа и оперативна компетентност, преди да може да участва в TARGET2-[посочете ЦБ/държава].
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].
За подаване на платежни нареждания и обмен на платежни съобщения в платежния модул се използва BIC на платформата TARGET2, TRGTXEPMLVP, като подател и получател на съобщения.
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.
Платежните нареждания, изпратени до участник с интернет базиран достъп, следва да идентифицират този участник в полето за институция получател.
Payment orders sent to a participant using Internet-based access should identify that receiving participant in the beneficiary institution field.
Платежните нареждания, направени от участник с интернет базиран достъп, идентифицират този участник като нареждаща институция.
Payment orders made by a participant using Internet-based access will identify that participant as the ordering institution.
Участниците с интернет базиран достъп използват услуги на инфраструктурен публичен ключ съгласно спецификациите в „Ръководство на потребителите относно интернет достъп за услугата сертифициране на публичен ключ“.
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”.
Типове платежни съобщения
Payment message types
Интернет базираните участници могат да извършват следните видове плащания:
Internet-based participants can make the following types of payments:
клиентски плащания, т.е. кредитни преводи, при които клиентът наредител и/или клиентът бенефициент не са финансови институции;
customer payments, i.e. credit transfers for which the ordering and/or beneficiary customer are not financial institutions;
STP клиентски плащания, т.е. кредитни преводи, при които клиентът наредител и/или клиентът бенефициент не са финансови институции, и които се извършват в режим обработка от край до край (STP);
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;
преводи от типа банка-банка за прехвърляне на средства между финансови институции;
bank-to-bank transfers to request the movement of funds between financial institutions;
покриващи плащания за прехвърляне на средства между финансови институции, свързани с основен клиентски кредитен превод.
cover payments to request the movement of funds between financial institutions related to an underlying customer credit transfer.
Освен това, участниците, които използват интернет базиран достъп до сметка в платежния модул, могат да получават нареждания за директен дебит.
In addition, participants using Internet-based access to a PM account can receive direct debit orders.
Участниците спазват спецификациите на полетата съгласно определеното в глава 9.1.2.2 от Подробните функционални спецификации за потребителите, книга 1.
Participants shall comply with the field specifications, as defined in Chapter 9.1.2.2 of the UDFS, Book 1.
Съдържанието на полетата се валидира на ниво TARGET2-[посочете държава/ЦБ] в съответствие с изискванията на Подробните функционални спецификации за потребителите.
Field contents shall be validated at the level of TARGET2-[insert country/CB reference] in accordance with the UDFS requirements.
Участниците могат да се споразумеят помежду си за определени правила относно съдържанието на полетата.
Participants may agree among each other on specific rules regarding the field contents.
В TARGET2-[посочете държава/ЦБ] обаче не се извършват специални проверки във връзка с това дали участниците спазват тези правила.
However, in TARGET2-[insert country/CB reference] there shall be no specific checks as to whether participants comply with any such rules.
Участниците, използващи интернет базиран достъп, могат да извършват покриващи плащания през TARGET2, т.е. плащания, извършени от кореспондентски банки за сетълмент (покриване) на съобщения за кредитен превод, които се изпращат до банка на клиент с други по-директни средства.
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.
Съдържащите се в тези покриващи плащания данни за клиента не се показват в модула за информация и контрол.
Customer details contained in these cover payments shall not be displayed in the ICM.
Проверка за двойно въвеждане
Double-entry check
Всички платежни нареждания подлежат на проверка за двойно въвеждане, която има за цел да отхвърли платежни нареждания, които са били подадени по погрешка повече от веднъж.
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.
Проверяват се следните полета на типовете съобщения:
The following fields of the message types shall be checked:
Информация
Details
Част от съобщението
Part of the message
Изпращач
Sender
Основен заглавен блок
Basic Header
BIC-адрес
BIC Address
Тип съобщение
Message Type
Заглавен блок на приложението
Application Header
Получател
Receiver
Адрес на получателя
Destination Address
Референтен номер на транзакцията (TRN)
Transaction Reference Number (TRN)
Текст блок
Text Block
Свързана референция
Related Reference
Вальор
Value Date
Когато всички полета, описани в точка 2 във връзка с новоподадено платежно нареждане, са идентични с тези, отнасящи се до платежно нареждане, което вече е прието, подаденото ново платежно нареждане се връща.
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.
Кодове за грешка
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.
Кодовете за грешки са определени в глава 9.4.2 от Подробните функционални спецификации за потребителите.
The error codes are defined in Chapter 9.4.2 of the UDFS.
Предварително определен момент на сетълмент
Predetermined settlement times
За платежни нареждания, използващи индикатора за най-ранен момент на дебит (Еarliest Debt Time Indicator), се прилага кодовата дума „/FROTIME/“.
For payment orders using the Earliest Debit Time Indicator, the codeword “/FROTIME/” shall be used.
За платежни нареждания, използващи индикатора за най-късен момент на дебит (Latest Debt Time Indicator), съществуват две възможности:
For payment orders using the Latest Debit Time Indicator, two options shall be available.
Кодова дума „/REJTIME/“
Codeword “/REJTIME/”
ако платежното нареждане не може да бъде извършено до посочения момент на дебит, платежното нареждане се връща.
if the payment order cannot be settled by the indicated debit time, the payment order shall be returned.
Кодова дума „/TILTIME/“
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.
И при двете възможности се предоставя автоматично съобщение чрез модула за информация и контрол, при условие че платежното нареждане с индикатор за най-късен момент на дебит не бъде изпълнено 15 минути преди времето, посочено в него.
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.
Ако се използва кодова дума „/CLSTIME/“, плащането се третира по същия начин, както платежното нареждане, съгласно точка 2, буква б).
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).
Сетълмент на платежни нареждания, въведени за обработка незабавно след приемането им
Settlement of payment orders in the entry disposition
Проверки за прихващане и, ако е уместно, разширени проверки за прихващане (двата термина са определени в параграфи 2 и 3) се извършват спрямо платежни нареждания въведени за обработка незабавно след приемането им, за да се осигури бърз и спестяващ ликвидност брутен сетълмент на платежните нареждания.
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.
Проверката за прихващане установява дали платежните нареждания на получателя на плащането, които са най-отпред на опашката за много спешни или, ако е неприложимо, на опашката за спешни плащания, могат да се прихванат с платежното нареждане на платеца (по-нататък „платежни нареждания за прихващане“).
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”).
Ако дадено платежното нареждане за прихващане не предоставя достатъчно средства за съответното платежно нареждане на платеца, въведено за обработка незабавно след приемането му, се установява дали има достатъчна налична ликвидност по сметката на платеца в платежния модул.
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.
Ако проверката за прихващане е неуспешна, [посочете име на ЦБ] може да извърши разширена проверка за прихващане.
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.
Ако обаче на опашката на получателя на плащането има платежни нареждания с по-висок приоритет, адресирани до други участници в TARGET2, принципът FIFO може да се наруши, само ако извършването на такова прихващане би довело до увеличаване на ликвидността на получателя на плащането.
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.
Сетълмент на платежни нареждания, чакащи на опашка
Settlement of payment orders in the queue
Обработката на платежни нареждания, чакащи на опашките, зависи от класа приоритет, към който те са причислени от инструктиращия участник.
The treatment of payment orders placed in queues depends on the priority class to which it was designated by the instructing participant.
Сетълментът на платежни нареждания, чакащи на опашките, за много спешни и спешни плащания се извършва, като се прилага проверката за прихващане, описана в параграф 6, като се започне с платежното нареждане отпред на опашката, в случаите, когато е налице увеличаване на ликвидността или когато има намеса на ниво опашка (промяна на поредността в опашката, момента на сетълмент или приоритета или анулиране на платежното нареждане).
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).
Обработка на платежни нареждания, чакащи на опашката за нормални плащания, включително и всички много спешни и спешни платежни нареждания, които все още не са извършени, се извършва непрекъснато.
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.
Използват се различни механизми за оптимизация (алгоритми).
Different optimisation mechanisms (algorithms) are used.
Ако алгоритъмът е успешен, то включените платежни нареждания ще бъдат изпълнени. Ако алгоритъмът е неуспешен, включените платежни нареждания ще останат на опашката.
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.
За прихващане на платежни потоци се прилагат три алгоритъма (от 1 до 3).
Three algorithms (1 to 3) shall be applied to offset payment flows.