LogoRegulatory Alerts
2020-01-01

Operating Rules of the Central Bank of Montenegro Payment System

The Central Bank of Montenegro issues these rules to standardize procedures for the processing, clearing, and settlement of payment transactions within its RTGS and DNS systems. The document defines eligible participants, mandates technical and security requirements for system access, and establishes protocols for message validation, priority handling, and account management. It further regulates operational hours, the irrevocability of transfer orders upon settlement, and the mechanisms for reporting and resolving complaints regarding payment execution.

Central Bank of Montenegro logo

Montenegro

Central Bank of Montenegro

Click to view thumbnail

[unofficially consolidated translation] OPERATING RULES OF THE CENTRAL BANK OF MONTENEGRO PAYMENT SYSTEM (OGM 048/14 of 13 November 2014, 050/14 of 28 November 2014, 057/14 of 26 December 2014, 047/25 of 16 May 2025, 074/25 of 10 July 2025, 098/25 of 3 September 2025) I. BASIC PROVISIONS Article 1 The Operating Rules of the Payment System of the Central Bank of Montenegro (hereinafter: the Central Bank) shall regulate the standardised procedures and common rules for the processing, clearing and/or settlement of payment transactions among participants in this payment system. Article 2 The Payment System of the Central Bank consists of the following systems:

  • RTGS system for executing individual payment transactions among participants following the real-time gross principle - Real-Time Gross Settlement (hereinafter: the RTGS system), and
  • DNS system for interbank payment transactions following the deferred net principle - Deferred Net Settlement (hereinafter: the DNS system). The Central Bank shall be the operator and the owner of the payment system referred to in paragraph 1 of this Article. II. RTGS SYSTEM Participants in the RTGS system Article 3 Participants in the RTGS system may be:
  1. the Central Bank;
  2. banks and other credit institutions;
  3. branches of third-country credit institutions having their head offices in Montenegro.
  4. government authorities, local self-government authorities, legal persons whose obligations are subject to statutory guarantee by Montenegro, and legal persons exercising public authority;
  5. the European Central Bank and third-country central banks;
  6. international financial institutions;
  7. the Deposit Protection Fund;
  8. donor organisations;
  9. the Central Securities Depository and Clearing Company of Montenegro, subject to the opening of a cash pool account;
  10. settlement agents;
  11. clearing organisations;
  12. payment system operators, and
  13. other legal persons, in line with the law and regulation of the Central Bank.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 2 RTGS system participant account Article 4 The Central Bank shall open and maintain RTGS system settlement account for the execution and settlement of payment transactions. The Central Bank shall open and maintain the reserve requirement accounts in the RTGS system on behalf of banks and other credit institutions. The Central Bank shall open a transaction account in line with the Central Bank regulation governing the opening of transaction accounts. In the case of opening a transaction account for a new participant, the Central Bank shall submit the notification on opening of that account to all other participants. Participant connection to the RTGS system Article 5 In order to participate in the RTGS system, participants shall submit to the Central Bank the connection request certified with the official seal and signed by the authorised person. The participant’s request for connection to the RTGS system shall be supported with the following:

  1. report of the identification code (BIC code) which they will use in the RTGS system; and
  2. report of the authorised persons to contact Central Bank regarding the payment transaction execution in the RTGS system, and
  3. report of a person responsible for security and safety of communication with the RTGS system (hereinafter: system administrator). The templates for reporting persons referred to in paragraph 2 items 2) and 3) of this Article shall be provided in Annex to these Rules. Article 6 In order to participate in the RTGS system, participants shall meet the technical requirements and standards for connecting to the RTGS system. A participant shall meet the technical requirements and standards for connecting to the RTGS system if it has:
  4. ensured the connection to the information and communication system of the central, back-up and disaster location of the Central Bank;
  5. provided necessary components of the ICT system in line with the specifications provided in Annex to these Rules;
  6. obtained from the body of the Central Bank responsible for issuing electronic certificates (CA – Certification Authority) digital certificates that are intended for verification of authenticity and integrity of electronic messages in the RTGS system;
  7. provided the training for its employees with the Central Bank for working with application software to be delivered by the Central Bank and used for the communication with the RTGS system;
  8. successfully tested the connection on the Central Bank’s RTGS test system; Article 7 Prior to connecting to the RTGS system and within the period that shall not exceed 30 days following the day of submitting the request for connecting to the RTGS system, a participant shall run a test for participating in the RTGS system in cooperation with the Central Bank.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 3 The possibility of exchange of messages concerning the RTGS system functioning shall be tested through the simulation of different business situations. The Central Bank shall oversee and coordinate the running of tests for participating in the RTGS system. The Central Bank shall prepare documentation which describes the manner of exchange of messages via the RTGS system and it shall submit it together with the test scenario to the participant. Article 8 The Central Bank shall execute transfer orders for the purpose of executing payment transactions for the participant under the testing procedure until its connection to the RTGS system. Payment orders referred to in paragraph 1 of this Article shall be delivered to the Central Bank in writing in accordance with the Central Bank regulation governing the core elements of payment orders. The Central Bank shall notify a participant under the testing procedure on the balance in its account until its connection to the RTGS system in the manner agreed between the participant and the Central Bank, and a report on payment transactions executed after the completion of operating day shall be provided by the Central Bank in the manner agreed between the participant and the Central Bank (in writing, by fax or e￾mail). Article 9 Upon successful testing, the participant shall sign a contract with the Central Bank on connecting to the RTGS system. The Central Bank shall send a notification on the connection of the new participant to the RTGS system to all other participants in the RTGS system. Once the contract on connecting to the RTGS system has been signed, a participant shall accept operating rules concerning the RTGS system in effect at the moment of its connection. Security and safety measures and responsibilities Article 10 Participants in the RTGS system shall ensure appropriate security and safety measures aimed at providing safe execution of payment transactions in the RTGS system. Obligations referred to in paragraph 1 of this Article shall also refer to the employees participating in the execution of payment transactions in the RTGS system, including physical control of access to computer resources connected to the information system of the Central Bank. Article 11 Participants in the RTGS system shall be familiar with the information security policy and rules of the Central Bank and they shall sign a memorandum of understanding on accepting this policy. Article 12 Information and data available to the Central Bank employees during their daily performance of operations concerning the RTGS system shall be confidential. By way of derogation from paragraph 1 of this Article, information and data may be made available in cases specified by the law and internal general act of the Central Bank. Article 13 Participants in the RTGS system shall nominate and authorise an administrator for the RTGS system. The system administrator shall be responsible for the following:

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 4

  1. configuring and administering ICT components necessary for the RTGS system functioning and the system of its security at the side of the participant in the RTGS system;
  2. exchange of digital certificates with the Central Bank;
  3. providing the Central Bank with a written report on the application of safety and other measures, at the Central Bank`s request;
  4. maintaining information and communication infrastructure of the participant in the RTGS system, and
  5. participating in testing. The system administrator shall perform all activities at the side of the participant in the RTGS system exclusively in cooperation with the Central Bank. In case of replacement of the person authorised for contacting the Central Bank concerning payment transaction execution in the RTGS system or replacement of the system administrator, as well as in case of any change in the contact information (phone number, e-mail, and the like), the participant shall inform the Central Bank thereof. Article 14 Persons reported to the Central Bank as the authorised persons or system administrators are obliged to know and apply these rules. Consequences resulting from the ignorance or non-implementation of these rules by the authorised persons or system administrators shall be taken by the participant who reported those authorised persons to the Central Bank. Article 15 Participants in the RTGS system shall be responsible for the authenticity and content of messages sent, as well as for the timeliness of message sending in the RTGS system. Each participant shall be responsible for accurate and proper acceptance of authorised orders received from another participant in the RTGS system during the RTGS system working hours. Each participant shall be responsible for computer software and its functional compliance and connectivity to the RTGS system, as well as reliability so that it would not jeopardise the RTGS system. Participant recipient shall be responsible for verifying the authenticity of the order received. Article 16 For the purpose of system security, digital certificates in the RTGS system shall be regularly replaced, as a rule, once a year. When the security reasons require so, the replacement of digital certificates in the RTGS system may also be made prior to the expiry of the one-year deadline. Funds for executing payment transactions in the RTGS system Article 17 Funds available in the participants` settlement accounts opened in the RTGS system shall be used for the execution of payment transactions within the RTGS system. Payment transactions to be executed within the RTGS system Article 18 The following transactions shall be executed in the RTGS system:

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 5

  1. payment transactions in the amount or exceeding the minimum value of payment transactions that must be processed in the RTGS system as determined by the Central Bank’s regulation;
  2. payment transactions involving the payment of public revenues (taxes, contributions, duties, etc.) to the transaction accounts prescribed by the ministry responsible for financial affairs and payment transactions to credit and debit the State Treasury;
  3. payment transactions through which the participants place and withdraw cash from the Vault of the Central Bank, and
  4. payment transactions delivered by the DNS system based on negative net position. Payment transactions lower than the minimum value prescribed by the Central Bank’s regulation may be processed within the RTGS system at a payment service user’s request. Settlement of payment transactions in the RTGS system Article 19 Settlement of all payment transactions shall be made in the RTGS system. Payment transactions shall be settled in the RTGS system in real time following the gross principle. Payment transactions shall be settled individually in the amount indicated in the order up to the amount of coverage in the participant’s account. The participant may initiate payment transactions only to the debit of its account. The Central Bank, as the payment system operator, may initiate payment transactions to debit the accounts of each participant based on the respective participant’s order or based on the regulation. The manner of executing payment transactions in the RTGS system Article 20 Transfer orders in the RTGS system must contain the core elements specified in the Annex of these Rules that also governs the manner of completing certain elements of such order. Article 21 Communication among the RTGS system participants shall be accomplished by exchanging electronic messages for executing payment transactions that are provided in the Annex of these Rules. An electronic message (hereinafter: the message) shall be information which has been electronically generated, validated, sent, received, confirmed, stored, and digitally signed. Article 22 Messages between the Central Bank and an RTGS system participant may be exchanged if the participant realises the connection with the information and communication system of the Central Bank. By way of derogation from paragraph 1 of this Article, if due to technical reasons (connection failure, or similar) a participant is unable to submit orders for transfers in the RTGS system via the Central Bank’s information and communication system, it may submit them in another electronic format or in hard copy. Article 23 The public key infrastructure (PKI) of the Central Bank shall be used for the validation of authenticity of messages and the security of transfer of messages via the information and communication system. The Central Bank shall issue digital certificates to the RTGS system participants and prescribe the manner of using the public key infrastructure in communication between the Central Bank and the RTGS system participants.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 6 Article 24 The Central Bank shall prescribe in these Rules the format and the purpose of messages to be used in the RTGS system. A message shall be considered valid if it meets the following criteria:

  1. it has been created in the existing MX format, according to ISO 20022 Standard, in line with the format and the purpose of messages determined under these Rules;
  2. it has been sent and received pursuant to the RTGS system rules; and
  3. it has been sent and received pursuant to the RTGS system Daily Work Schedule. Notwithstanding paragraph 2 item 1 of this Article, the message shall be considered valid even if it is created in the SWIFT (Society for Worldwide Interbank Financial Telecommunication) format in accordance with these rules, using the functionality of the RTGS system that enables the conversion of the MT format into the MX format. An RTGS system participant shall assume obligations based on the valid message or on the basis of its changes or revocation. Article 25 Payment transaction messages shall be executed in the RTGS system with priorities ranked from 1 to 99, whereby 1 shall have the highest and 99 the lowest priority. Priorities from 1 to 9 shall be reserved for the Central Bank payment transactions, and priorities from 10 to 99 shall be used by other participants, according to their needs, in such a way that priority codes from 10 to 19 are considered high priority, from 20 to 49 medium priority, and from 50 to 99 low priority. Article 26 Payment transaction messages with priorities from 10 to 99 for which execution there is no positive balance in the participant’s account in the RTGS system shall be put in the queue and after the positive balance has been provided, they shall be executed as per the priority and time of sending by the end of the operating day. Article 27 For payment transaction messages, for which execution there is no positive balance in the participant’s account by the end of the operational day, the RTGS system shall transmit the appropriate message to the sender on rejecting the execution of these messages. Article 28 A participant may change the priority of a payment transaction message in the queue by the end of the operating day. If the participant is unable to change the message priority electronically, the request on the change of the priority shall be submitted to the competent organisational unit of the Central Bank (hereinafter: the Department) until 19:30 hours at the latest, on working days, or until 14:30 hours on Saturdays and Sundays (hereinafter: weekends) and on days that are non-working days in accordance with the law governing state and other holidays (hereinafter: holidays), in the template provided in the Annex to these Rules. Article 29 For messages sent for which it has been determined that they are not valid (such as incorrect BIC code of the RTGS system participant, incorrect account, incorrect transfer order date, and the like), the RTGS system shall transmit the appropriate message to the participant on rejecting the execution of these messages.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 7 Article 30 Immediately after the execution of a payment transaction, the RTGS system shall transmit to the participant appropriate messages on the settlement. Article 31 For messages sent with the instruction of executing individual transfer orders for which the execution requirements have not been met during the operating day, the RTGS shall transmit the message to the participant on rejecting the settlement of those orders, based on which the rejection of the settlement shall be considered final. Article 32 For payment transaction messages sent that cannot be executed by the end of the operating day due to the lack of positive balance in the account, the RTGS shall transmit the message to the participant on rejecting the settlement of those orders, based on which the rejection of the settlement shall be considered final. Article 33 A participant may cancel a queued payment transaction message by the end of the operating day. If the participant is unable to cancel the payment transaction message electronically, it shall send a request for cancelling the payment transaction in the RTGS to the Department until 19:30 hours on working days, or until 14:30 hours on weekends and holidays, in the template provided in the Annex to these Rules. Article 34 An RTGS system participant that has not received a message due to technical problems may request its resending by the Department, in the template provided in the Annex to these Rules. Moment of acceptance and irrevocability of transfer orders Article 35 Transfer order forwarded to the RTGS system shall be accepted and irrevocable from the moment of its settlement. Payment transaction shall be settled after the RTGS system participants` accounts have been credited and debited. Report on executed transactions Article 36 During a processing day, every participant shall receive a report on executed daily payment transactions in the RTGS system and a report on the daily charge of the Central Bank fee for executed payment transactions. The Central Bank shall send the reports referred to in paragraph 1 of this Article via messages provided in the Annex to these Rules. Complaints Article 37 A participant may submit a complaint referring to payment transactions in the RTGS system within three business days following that of the execution of the payment transaction.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 8 The complaints shall be submitted to the Department in the template provided in the Annex to these Rules. RTGS system business days, working hours, operating and processing days Article 38 Business days, within the meaning of these of Rules, shall be all days within a year. The working hours of the RTGS system shall be from 08:30 to 20:50 hours on working days, or until 15:50 hours on weekends and holidays. The working hours of the RTGS system shall be divided into an operating and a processing day. The operating day, within the meaning of these Rules, shall be a part of the working hours in which the RTGS system is open for starting and receiving and sending payment transaction messages and other messages, and it shall last from 08:30 to 20:00 hours on working days, or until 15:00 hours on weekends and holidays. The processing day, within the meaning of these Rules, shall be a part of working hours in which the RTGS system is open for rejecting non-executed messages and for processing and archiving messages, and it shall last from 20:00 to 20:50 hours on working days, or from 15:00 to 15:50 hours on weekends and holidays. RTGS system working schedule Article 39 The working schedule of the RTGS system shall be determined by the Daily Work Time Schedule of the RTGS system provided in the Annex to these Rules. Article 40 Activation of the RTGS system shall start with the Beginning of Day period and it shall end by activation of End of Day period. Periods established by the Daily Work Time Schedule of the RTGS system shall have the following meaning: a) Period: Beginning of Day The initiation of the “Beginning of Day” period shall start the RTGS system. b) Period: Exchange of payment transaction messages After activating the “Exchange of payment transaction messages” period, the RTGS system shall be available to participants for sending payment transaction messages and other messages. c) Period: Stop RTGS system “Stop RTGS system” period shall mean the end of sending payment transaction messages for that operating day in the RTGS system. d) Period: Rejecting non-executed messages The “Rejecting non-executed messages” period means a part of the processing day during which the system rejects non-executed payment transactions. e) Period: Creating reports on executed payment transactions in the RTGS system During this period, the RTGS system shall create reports on executed daily payment transactions in the RTGS system. f) Period: Creating reports on the daily charge of the Central Bank fee

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 9 Period during which the RTGS system creates reports on the daily charge of the Central Bank fee. g) Period: Archiving Data archiving period. h) Period: End of Day The “End of Day” period shall mean the end of the RTGS system operations and end of the business day. Changes to the Daily Work Time Schedule of the RTGS system Article 41 The Central Bank shall have the right to change the Daily Work Time Schedule of the RTGS system in emergency and contingency situations, and it shall inform thereof all participants in the RTGS system. The Central Bank may change the Daily Work Time Schedule of the RTGS system due to the following reasons: 1)necessary technical and application interventions for the purpose of resolving problems substantially affecting the functionality and/or security of RTGS system; 2)other reasons that may affect the security and efficiency of the RTGS system operations. The Central Bank may, as needed, change the Daily Work Time Schedule of the RTGS system at a participant’s request, whereby the participant may only request the extension of the “Exchange of the payment transaction messages” period. When extending the “Exchange of payment transaction messages” period, the subsequent periods of the Daily Work Time Schedule of the RTGS system shall be rearranged for the period of the granted extension. If the Daily Work Time Schedule of the RTGS system is changed at a participant’s request, the Central Bank shall charge the costs of changing the Daily Work Time Schedule of the RTGS system to the participant. The participant shall submit the Request for extending operations of the RTGS system to the Department until 19:30 hours on working days, or until 14:30 hours on weekends and holidays in the template provided in the Annex to these Rules. The Daily Work Time Schedule of the RTGS system may be extended at a participant’s request for no more than 60 minutes. Exceptionally, if the Central Bank has assessed that the Daily Work Time Schedule of the RTGS system requires the extension exceeding 60 minutes due to jeopardized functioning of the financial system or removal of systemic problems in the RTGS system operations, it shall approve the extension until the removal of causes for which it had been requested. Procedure in case of contingency situations Article 42 In the event of contingency situations in the RTGS system (e.g., problems in the communication of the participants with the RTGS system, technical problems in the RTGS system operations or force majeure event), the Central Bank shall notify the system participants thereof. The notification shall contain the following information:

  • a description of the contingency event;
  • an estimated time needed to resolve the problem, and
  • an instruction to participants for further actions.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 10 In the event of technical problems with the equipment in use, a participant shall notify the Central Bank thereof, remove deficiencies in the shortest period and ensure regular participation in the RTGS system. In the event of contingency situations at the participant’s side resulting in problems in their participation in the RTGS system, the participant shall notify the Central Bank thereof. The notification shall contain the following information:

  • a description of the contingency event; -an estimated time needed to resolve the problem, and
  • a notification on actions taken. In case of contingencies resulting in an inability of undisturbed RTGS system operations, the Central Bank may:
  • delay the beginning of operations or extend the operations of the RTGS system;
  • settle payment transactions submitted in electronic format or hard copy, and
  • transfer its work to a back-up location. “Service Desk” Article 43 The Central Bank shall set up and maintain the “Service Desk” for communication with all participants in the RTGS system. The “Service Desk” shall be the uniform database containing all reported incidents and problems concerning the RTGS system operations, and the method for their resolution. The “Service Desk” shall include:
  • reporting of problems that the RTGS system participants and operator encounter;
  • identification and description of problems (communication, software and hardware problems, and the like);
  • providing support and advice in resolving the reported incidents or problems;
  • keeping records on communication concerning the reported incidents and problems. When providing the “Service Desk” support, the communication with the participants and the operator shall be made via e-mail (servicedesk@cbcg.me), phone (069 860 019) or web application. Manner of participation of a participant not connected to the RTGS system Article 44 The Central Bank shall perform operations concerning the participation in the RTGS system for the participant that is not connected to the RTGS system. The participant that is not connected to the RTGS system shall deliver to the Central Bank transfer orders in hard copy in accordance with the Central Bank regulation governing the core elements of the payment order. The Central Bank shall provide notification on the balance in the account of the participant that is not connected to the RTGS system during the operating day, in the manner agreed between the respective participant and the Central Bank. The Central Bank shall deliver via email the report on executed payment transactions and the balance in the account of the participant that is not connected to the RTGS system upon the completion of the operating day.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 11 Suspension and exclusion of the participant from the RTGS system Article 45 The Central Bank may suspend an RTGS system participant in the following cases:

  1. if the participant has failed to act pursuant to these rules;
  2. if the participant does not act according to the contract on connecting to the RTGS system concluded with the Central Bank; and
  3. if it has been determined that the participant causes technical problems in the RTGS system operations. Article 46 The Central Bank shall pass a decision on the suspension and exclusion of an RTGS system participant. Exceptionally, if a participant causes technical problems in the operations of the RTGS system, and with a view to removing imminent threat to property, the Central Bank may pass an oral decision on suspending the participant from the RTGS system, provided that it passes a written decision within three days following the oral decision date. Article 47 The Central Bank shall reconnect the participant to the RTGS system once the reasons for suspension have ceased to exist. Article 48 The Central Bank shall exclude a participant from the RTGS system if a legally binding resolution has been passed on closing the bankruptcy or liquidation proceedings against the participant. Changes of data and information on participants Article 49 In case of any change of data and information (BIC, name and address, and the like), a participant shall notify the Central Bank thereof. The Central Bank shall notify all other participants on the change of data and information referred to in paragraph 1 of this Article. Testing in the RTGS system Article 50 In addition to tests referred to in Article 7 of these Rules, tests shall be also run in the RTGS system in the following cases:
  • of regular annual tests of the participants and operators;
  • of regular annual tests of the Business Continuity Plan of the Central Bank,
  • in accordance with the participant and operator needs. The Central Bank shall organise testing referred to in paragraph 1 indent 1 of this Article twice a year. In contingency situation, changes to the RTGS system or any other reason that requires the verification of the functionality with participants or operator, tests may be run also several times during one calendar year. The Central Bank shall, within 30 days following that of the completion of the testing, submit to all participants a report on the key results of the testing referred to in paragraph 1 indent 2 of this Article,

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 12 including relevant conclusions and suggestions for improving the security and reliability of the RTGS system. Article 51 The Central Bank may, where it deems necessary and for the purpose of safe and sound RTGS system functioning, request the participants to run additional tests. The Central Bank shall notify all participants on the testing conditions via message, e-mail or other adequate means of communication. Article 52 In case of testing needs, a participant shall provide the Central Bank with the request containing proposed testing schedule. The Central Bank shall accept the request of the participant if it deems that the proposed testing will not limit regular operations of the RTGS system. The Central Bank shall enable the participant testing in the proposed time and if it is not possible, it shall propose alternative time for testing. Statements at participant request Article 53 The Central Bank shall issue statements of keeping the accounts of participants in the RTGS system, account freezing of the participant at a specified date and in the specified period, balance at the account of the participant at a specified date and in the specified period. The Central Bank shall issue statements referred to in paragraph 1 of this Article to a participant pursuant to its written request. Management of operational and financial risk in the RTGS system Article 53a A participant in the RTGS system shall be responsible for ensuring sufficient funds in the settlement account, or for reserving funds in that account, for the purpose of settling monetary obligations arising in the DNS system. A participant in the RTGS system may, through a request or independently, via the User Portal, monitor the status of its positions and payment messages during the business day. In the event of a delay in the settlement of payment transactions that are in the gridlock involving two or more participants, the Payment system operator may activate one of the following systemic procedures to resolve the situation:

  1. Volume-based optimisation – the system shall execute the settlement of orders in the gridlock by prioritising the combination of orders that allows for the settlement of the largest number of orders within the available funds of the participants;
  2. Value-based optimisation – the system shall execute the settlement of orders in the gridlock by prioritising the settlement of those orders with the highest value within the available funds of the participants;
  3. Bypass FIFO – the system shall execute the settlement of orders in the gridlock by prioritising those orders that first entered the system, within the available funds of the participant.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 13 III. DNS SYSTEM Participants in the DNS system Article 54 Participants in the DNS system may be:

  1. the Central Bank;
  2. banks and other credit institutions; and
  3. branches of third-country credit institutions having their head offices in Montenegro. Conditions for participating in the DNS system Article 55 In order to participate in the DNS system, the participants should:
  4. participate in the RTGS system;
  5. meet technical requirements and standards for the connection to the DNS system;
  6. submit to the Central Bank the authorisations to debit the account in the RTGS system based on the negative net position arising from the multilateral clearing in the DNS system, up to the level of funds reserved for this purpose;
  7. report to the Central Bank the authorised contact persons for the payment transaction’s execution in the DNS system; and
  8. report to the Central Bank the person responsible for security and safety of communication with the DNS system. The forms for reporting persons referred to in paragraph 1 items 4) and 5) of this Article are provided in the Annex to these Rules. Article 56 A participant shall be considered to meet the technical requirements and standards for connecting to the DNS system, within the meaning of Article 55 paragraph 1 item 2) of these Rules, if it has:
  9. provided the components of the ICT system in line with the specifications provided in Annex to these Rules, needed for connecting to the DNS system;
  10. provided the training for its employees with the Central Bank for using the DNS application software;
  11. successfully tested the connection on the Central Bank’s DNS test system; Article 57 In order to participate in the DNS system, a participant shall submit to the Central Bank the connection request certified with the official seal and signed by the authorised person. Article 58 Prior to connecting to the DNS system and within the period that shall not exceed 30 days following the day of submitting the request for connecting to the DNS system, a participant shall run a test for participating in the DNS system in cooperation with the Central Bank. The possibility of exchange of messages concerning the DNS system functioning shall be tested through the simulation of different business situations. The Central Bank shall oversee and coordinate running of tests for participating in the DNS system.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 14 The Central Bank shall prepare documentation which describes the manner of exchange of messages via the DNS system and it shall submit it together with the test scenario to the participant. Article 59 Upon the successful testing, a participant shall sign a contract with the Central Bank on connecting to the DNS system. The Central Bank shall send a notification on participant connected to the DNS system to all other participants in the DNS system. Once the contract on connecting to the DNS system has been signed, a participant shall accept operating rules concerning the DNS system in effect at the moment of its connection. Security and safety measures and responsibilities Article 60 Participants in the DNS system shall ensure appropriate security and safety measures aimed at providing safe execution of payment transactions in the DNS system. Obligations referred to in paragraph 1 of this Article shall also refer to the employees participating in the execution of payment transactions in the DNS system, including physical control of access to computer resources connected to the information system of the Central Bank. Article 61 Participants in the DNS system shall be familiar with the information security policy and rules of the Central Bank and they shall sign a memorandum of understanding on accepting this policy. Article 62 Information and data available to the Central Bank employees during their daily performance of operations concerning the DNS system shall be confidential. By way of derogation from paragraph 1 of this Article, information and data may be made available in cases specified by the law and internal general act of the Central Bank. Article 63 System administrator for the RTGS system shall be responsible also for the security and safety of the communication with the DNS system. Article 64 Persons reported to the Central Bank as authorised persons are obliged to know and apply these rules. Consequences resulting from the ignorance or non-implementation of these rules by the authorised persons shall be taken by the participant who reported to the Central Bank those authorised persons. Article 65 Participants in the DNS system shall be responsible for the authenticity and content of messages sent, as well as for the timeliness of message sending in the DNS system. Each participant shall be responsible for accurate and proper acceptance of authorised orders received from another participant in the DNS system during the DNS system working hours. Each participant shall be responsible for computer software and its functional compliance and connectivity to the DNS system, as well as reliability so that it would not jeopardise the DNS system. Participant recipient shall be responsible for verifying the authenticity of the order received.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 15 Payment transactions to be executed within the DNS system Article 66 Payment transactions to be executed within the DNS system shall be payment transactions below the minimum amount of payment transactions mandatorily executed in the RTGS system, as determined by a Central Bank regulation. Coverage caps for negative net position in the DNS system Article 67 For the purpose of submitting orders and participating in the DNS system, the participant shall be required to define a clearing limit by reserving funds on its account in the RTGS system. The participant may increase or decrease the limit referred to in paragraph 1 of this Article, depending on its needs, subject to the available balance in the participant’s account in the RTGS system and the value of its multilateral net position in the DNS system. The participant’s multilateral net position referred to in paragraph 2 of this Article shall be the sum of the value of all payment transactions received by the participant in the DNS system, reduced by the sum of the value of payment transactions sent by the participant to other participants, and may be either positive or negative. The participant shall not be permitted to reduce the established limit referred to in paragraph 1 of this Article below the amount of its current multilateral net position in the DNS system. In case the participant is not able to set or change the coverage cap referred to in paragraph 1 of this Article electronically, the information on the setting or changing of the coverage cap shall be submitted to the Department, no later than by 19:15 hours on working days, or by 14:15 hours on weekends and holidays, on the prescribed template provided in the Annex to these Rules. Article 68 After the final clearing cycle during an operating day, the Central Bank shall release any unused funds reserved for the set coverage cap and they shall be available for use in the RTGS system. Acceptance of orders into the DNS system Article 69 Orders for transfer into the DNS system must contain elements specified in the Annex of these Rules governing also the manner of completing certain elements of such order. Article 70 The communication between the participants and the DNS system shall be via messages which may be delivered separately for every individual payment transaction or for a group of payment transactions, in line with the format and the purpose of messages provided in the Annex to these Rules. The format and the purpose of messages between the Central Bank and other participants in the DNS system shall be specified by the Central Bank herein. Article 71 A message shall be considered valid if it meets the following criteria:

  1. it has been sent by a participant in the DNS system;
  2. it has been created in MX format in accordance with the ISO 20022 Standard, in line with the format and the purpose of messages determined under these Rules;

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 16 3) the stated amount is below the minimum amount of payment transactions mandatorily executed in the RTGS system, as determined by the Central Bank regulation. 4) it has been sent and received pursuant to the DNS system rules; and 5) it has been sent and received pursuant to the DNS system Daily Work Schedule. Notwithstanding paragraph 1 item 2 of this Article, the message shall be considered valid even if it is created in the SWIFT format in accordance with these rules, using the functionality of the RTGS system that enables the conversion of the MT format into the MX format. Article 72 Payment transaction messages shall be executed in the DNS system with the priority 100. Article 73 For sent messages determined as invalid (e.g., incorrect BIC code, incorrect account, incorrect settlement date of the payment transaction order, etc.), the DNS system shall transmit the appropriate message to the sender on rejecting the execution of these messages. Article 74 For sent messages that are covered in the DNS system account, the DNS system shall automatically send the sender an acknowledgment of message receipt and, in real time, forward a copy of the original message to the recipient. Article 75 If the negative multilateral net position exceeds the established clearing limit, the sent messages shall be placed in the gridlock, and upon securing sufficient funds, they shall be executed in real time or in the next clearing cycle, depending on the time the message was submitted. Article 76 If the participant has not provided funds for the coverage of negative net position by the end of the final clearing cycle, the DNS system shall send messages to the sender on the rejection of any received messages in the queue. Article 76a The sender may not revoke a payment transaction message for which the payment recipient has received a copy of that message. Article 77 The sender may revoke a payment transaction message, or one or more instructions within the message or group payment order that is in the gridlock, until 19:30 hours on working days, or until 14:30 hours on weekends and holidays. If the sender is unable to cancel the payment transaction electronically, the information on the cancelation of the payment transaction in the DNS system shall be sent to the Department, no later than 19:15 hours on working days, or until 14:15 hours on weekends and holidays on the prescribed template provided in the Annex to these Rules. Article 78 A DNS system participant that has not received a message due to technical problems may request its resending by the Department, in the form provided in the Annex to these Rules. The manner of payment transaction execution in the DNS system

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 17 Article 79 A participant in the DNS system has the ability to monitor its multilateral net position in real time via the user portal. Article 80 In order to execute a participant’s multilateral net positions, the participant’s account in the RTGS system shall be debited in the amount of reserved funds and/or in order to execute the participant’s positive multilateral net positions, the participant’s account in the RTGS system shall be credited. Article 81 The execution of orders issued by the DNS system based on the netting shall be secured by funds reserved for the coverage of negative net position. Article 82 If a participant’s negative net position in the final clearing cycle exceeds the amount of funds reserved for the negative net position, the sent message shall not be executed, and the DNS system shall send a message on the rejection of these messages. Payment transactions calculation and settlement finality Article 83 The calculation of payment transactions of participants during one clearing cycle in the DNS system shall be final upon completing this cycle. The result of the calculation of payment transactions in the DNS system at the end of the clearing cycle shall be final net position for the respective cycle. Settlement finality of participants’ net positions in the DNS system shall be performed by the Central Bank in the RTGS system at the end of each clearing cycle. Informing the participants in the DNS system Article 84 After every clearing cycle, every participant shall be delivered the following: 1)report on all executed payment transactions; and 2)individual messages for executed payment transactions sent to the respective participant by other participants. The Central Bank shall submit the report and messages referred to in paragraph 1 of this Article via messages provided in the Annex to these Rules. Complaints Article 85 A participant in the DNS system may submit a complaint on the payment transaction executed in the respective system within three working days following that of the payment transaction execution. Complaints shall be submitted to the Department in the form provided in the Annex to these Rules. DNS system business days, working hours, operating and processing days

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 18 Article 86 Business days, within the meaning of these of Rules, shall be all days within a year. The working hours of the DNS system shall be from 08:30 to 20:50 hours on working days, or until 15:50 hours on weekends and holidays. The working hours of the DNS system shall be divided into an operating and a processing day. The operating day, within the meaning of these Rules, shall be a part of the working hours in which the DNS system is open for starting and receiving and sending messages for payment transactions and other messages and which shall last from 08:30 to 19:45 hours on working days, or until 14:45 hours on weekends and holidays. The processing day, within the meaning of these Rules, shall be a part of working hours in which the DNS system is open for rejecting non-executed messages and for processing and filing messages and which shall last from 19:45 to 20:50 hours on working days, or from 14:45 to 15:50 hours on weekends and holidays. DNS system work schedule Article 87 The working schedule of the DNS system shall be determined by the Daily Work Time Schedule of the DNS system provided in the Annex to these Rules. Article 88 Activation of the DNS shall start with the Beginning of Day period and it shall end by activation of End of Day period. Periods established by the Daily Work Time Schedule of the DNS system on working days shall have the following meaning: a) Period: Beginning of Day The initiation of the “Beginning of Day” period shall start the DNS system. b) Period: Exchange of payment transaction messages for the first cycle After activating the “Exchange of payment transaction messages” period, the system is available to participants for sending payment transaction messages and other messages. c) Period: Clearing (the first cycle) Period in which the calculation in clearing is performed, as well as settlement finality of net positions at the accounts in the RTGS system and drawing up reports on executed transactions in the DNS system. d) Period: Clearing (the second cycle) Period in which the calculation in clearing is performed, as well as settlement finality of net positions at the accounts in the RTGS system and drawing up reports on executed transactions in the DNS system. e) Period: Clearing (the third cycle) Period in which the calculation in clearing is performed, as well as settlement finality of net positions at the accounts in the RTGS system and drawing up reports on executed transactions in the DNS system. f) Period: Clearing (the fourth cycle) Period in which the calculation in clearing is performed, as well as settlement finality of net positions at the accounts in the RTGS system and drawing up reports on executed transactions in the DNS system.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 19 g) Period: Clearing (the fifth cycle) Period in which the calculation in clearing is performed, as well as settlement finality of net positions at the accounts in the RTGS system and drawing up reports on executed transactions in the DNS system. h) Period: Preparation for the sixth cycle (pre-clearing) Period “Preparation for the sixth cycle (pre-clearing)” means the period when the participants may check the balance on their net position from the multilateral calculation in the clearing and use it for sending payment transaction messages for that day in the DNS system. i) Period: Clearing (the sixth cycle) Period in which the last calculation in clearing is performed, as well as settlement finality of net positions at the accounts in the RTGS system and drawing up the Report on executed transactions in the DNS system. j) Period: Stop clearing The “Stop clearing” period means the period of releasing reserved funds from the DNS system for that day. k) Period: Rejecting non-executed messages The “Rejecting non-executed messages” period is a part of the processing day during which the system rejects non-executed payment transactions. l) Period: Creating reports in the RTGS system on net position in the DNS system In this period, the RTGS system creates reports on the participants’ net positions in the DNS system. m) Period: Archiving Data archiving period. n) Period: End of Day The “End of Day” period shall mean the end of the DNS system operations and end of the business day. Periods established by the Daily Work Time Schedule of the DNS system on weekends and on holidays shall have the following meaning: a) Period: Beginning of Day The initiation of the “Beginning of Day” period shall start the DNS system. b) Period: Exchange of payment transaction messages for the first cycle After activating the “Exchange of payment transaction messages” period, the system is available to participants for sending payment transaction messages and other messages. c) Period: Clearing (the first cycle) Period in which the calculation in clearing is performed, as well as settlement finality of net positions at the accounts in the RTGS system and drawing up reports on executed transactions in the DNS system. d) Period: Clearing (the second cycle) Period in which the calculation in clearing is performed, as well as settlement finality of net positions at the accounts in the RTGS system and drawing up reports on executed transactions in the DNS system. e) Period: Preparation for the third cycle (pre-clearing) The “Preparation for the third cycle (pre-clearing)” period means the period when the participants may check once more the balance on their net position from the multilateral calculation in the clearing and use it for sending payment transaction messages for that day in the DNS system. f) Period: Clearing (the third cycle)

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 20 Period in which the calculation in clearing is performed, as well as settlement finality of net positions at the accounts in the RTGS system and drawing up reports on executed transactions in the DNS system. g) Period: Stop clearing The “Stop clearing” period means the period of releasing reserved funds from the DNS system for that day. h) Period: Rejecting non-executed messages The “Rejecting non-executed messages” period means a part of the processing day during which the system rejects non-executed payment transactions. i) Period: Creating reports in the RTGS system on net position in the DNS system In this period, the RTGS system creates reports on the participants’ net positions in the DNS system. j) Period: Archiving Data archiving period. k) Period: End of Day The “End of Day” period means the end of the DNS system operations and end of the business day Changes to the Daily Work Time Schedule of the DNS system Article 89 The Central Bank shall have the right to change the Daily Work Time Schedule of the DNS system in emergency and contingency situations and it shall notify thereof all participants in the DNS system. The Central Bank may change the Daily Work Time Schedule of the DNS system due to the following reasons: 1)necessary technical and application interventions for the purpose of resolving problems substantially affecting the functionality and/or security of DNS system; 2)other reasons that may affect the security and efficiency of the DNS system operations. The Central Bank may, as required, change the Daily Work Time Schedule of the DNS system at a participant’s request, whereby the participant may only request the extension of the “Exchange of payment transaction messages for the sixth cycle” period. The participant shall submit the Request for extending the operations of the DNS system to the Department no later than until 19:15 hours on working days, or until 14:15 hours on weekends and holidays, in the template provided in the Annex to these Rules. The Daily Work Time Schedule of the DNS system may be extended at a participant’s request for no more than 15 minutes. Exceptionally, if the Central Bank has assessed that the Daily Work Time Schedule of the DNS system requires the extension exceeding 15 minutes due to jeopardized functioning of the financial system or removal of systemic problems in the DNS system operations, it shall approve the extension until the removal of causes for which it had been requested.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 21 Mutatis mutandis Article 90 Provisions of these Rules governing the respective actions in the RTGS system shall be applied mutatis mutandis to the actions in case of contingencies in the DNS system, establishing and maintaining services of the “Service Desk”, suspension and exclusion from the DNS system as well as testing in the DNS system. IV. ANNEXES Article 91 Annexes to these Rules make an integral part thereof and they are laid out under the following order:

  1. Annex 1 – Registration of persons authorised for contact with the Central Bank and person authorised for security and safety of communication with the RTGS and the DNS system;
  2. Annex 2 – Specification of ICT system components on the participants’ side necessary for connecting to the RTGS system;
  3. Annex 3 – Core elements of transfer orders and the manner of completing core elements of transfer orders into corresponding electronic messages
  4. Annex 4 – Messages in MX and MT format:
  5. Annex 5 – Request for the change of message priority in the RTGS system;
  6. Annex 6 – Requests for the cancelation of payment transaction messages in the RTGS and DNS systems;
  7. Annex 7 – Requests for resending messages from the RTGS and DNS systems;
  8. Annex 8 – Complaints regarding payment transactions executed in the RTGS and DNS systems;
  9. Annex 9 – Daily Work Time Schedule of the RTGS and DNS system;
  10. Annex 10 – Requests for the extension of operating hours of the RTGS and DNS systems;
  11. Annex 11 – Request for determining or changing the limit for negative net position from the multilateral calculation in the DNS system. V. FEES FOR EXECUTING PAYMENT TRANSACTIONS Article 92 The Central Bank shall charge fees for the payment transactions execution in the RTGS and DNS systems in the amount and manner prescribed under the decision regulating the tariffs for calculating fees for execution of services performed by the Central Bank. VI. DOCUMENT ARCHIVING Article 93 The Central Bank shall archive and keep documents on the executed payment transactions in the RTSG and the DNS system for five years, and it shall keep electronic data on these payment transactions ten years following that of their execution.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 22 VII. TRANSITIONAL AND FINAL PROVISION Article 94 Contracts on connection to the RTGS and the DNS system signed prior to the beginning of the implementation of these Rules shall remain in force and they shall be harmonised with these Rules within 60 days following that of their application. Article 94a The provisions of Article 24 paragraph 3, and Article 71 paragraph 2 of these Rules shall apply 12 months from the date these Rules enter into force. Article 94b Until the successful production launch of the upgraded Payment System in accordance with these Rules, the Operating Rules of the Central Bank of Montenegro Payment System (OGM 48/14, 57/14) shall apply. Article 95 On the enforcement day of these Rules, the Payment System Rules for Interbank Payment Transfers (OGM 24/09) shall be repealed. Article 96 These Rules shall enter into force on the eighth day following that of their publication in the “Official Gazette of Montenegro”, and they shall apply from 20 October 2025. THE COUNCIL OF THE CENTRAL BANK OF MONTENEGRO

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 23 ANNEX 1 REGISTRATION OF PERSONS AUTHORISED FOR CONTACT WITH THE CENTRAL BANK AND PERSON AUTHORISED FOR SECURITY AND SAFETY OF COMMUNICATION WITH THE RTGS SYSTEM AND THE DNS SYSTEM

Participant’s stamp a) REGISTRATION OF PERSONS AUTHORISED FOR CONTACT WITH THE CENTRAL BANK OF MONTENEGRO FOR PAYMENT TRANSACTION EXECUTION IN THE RTGS SYSTEM

(full participant’s name from the certificate on registration in the CRPS) Participant’s registration number: ______________________________ Authorised contact persons with the Central Bank of Montenegro for the payment transaction execution in the RTGS system are:

  1. First name and surname: _________________________________________ Telephone number _______________________________ E-mail address: _____________________________ Contact person’s signature ______________________
  2. First name and surname: ________________________________________ Telephone number _______________________________ E-mail address: _____________________________ Contact person’s signature: _____________________ Place and date: __________________________ Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 24

Participant’s stamp b) REGISTRATION OF PERSONS AUTHORISED FOR CONTACT WITH THE CENTRAL BANK OF MONTENEGRO FOR PAYMENT TRANSACTION EXECUTION IN THE DNS SYSTEM

(full participant’s name from the certificate on registration in the CRPS) Participant’s registration number: ______________________________ Authorised contact persons with the Central Bank of Montenegro for the payment transaction execution in the DNS system are:

  1. First name and surname: _________________________________________ Telephone number _______________________________ E-mail address: _____________________________ Contact person’s signature ______________________
  2. First name and surname: ________________________________________ Telephone number _______________________________ E-mail address: _____________________________ Contact person’s signature: _____________________ Place and date: __________________________ Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 25

Participant’s stamp c) REGISTRATION OF THE PERSON AUTHORISED FOR THE SECURITY AND SAFETY OF COMMUNICATION WITH THE RTGS AND DNS SYSTEMS

(full participant’s name from the certificate on registration in the CRPS) Participant’s registration number: ______________________________ The person authorised for security and safety of communication with the RTGS and DNS systems is:

  1. System administrator First name and surname: _________________________________________ Telephone number _______________________________ E-mail address: _____________________________ Contact person’s signature ______________________ Place and date: __________________________ Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 26 ANNEX 2 SPECIFICATION of ICT system components on the participant’s side necessary for connecting to the RTGS system A participant shall provide ICT components to be used for installing File Adapter (or RCCC component or Controller Workplace, depending on the type of connection to be used by the participant) and the realisation of computer communication with the information and communication system of the CBCG.

  1. Microsoft Windows OS; • Microsoft Windows OS; • OS version for which EOS does not expire for another year at a minimum and for which it is verified that current versions of File Adapter, RCCC component and Controller Workplace function.
  2. Hardware: • Compatible with Microsoft Windows OS, • Recommended configuration by Microsoft which enables undisturbed work of computer, • Hard disk: 10GB free space at a minimum, • Network: 1 Ethernet adapter 100Mbps at a minimum • VGA resolution
  3. Computer and communication device: • L3 device (router/firewall/switch), with a possibility to install L2L VPN tunnel.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 27 ANNEX 3 CORE ELEMENTS OF TRANSFER ORDERS AND THE MANNER OF COMPLETING CORE ELEMENTS OF TRANSFER ORDERS INTO CORRESPONDING ELECTRONIC MESSAGES The table below describes core elements of transfer orders and the manner of completing core elements of transfer orders into the corresponding electronic messages: No. Name of elements of data Manner of completing elements of data Electronic format Note 1 Name of payer Name and head office of a legal person or entrepreneur, or name, last name and the address of a natural person’s residence 335x 335x – alphabet, numerical and alphanumerical characters 2 Transaction account of payer Transaction account to be debited 18n As per decision regulating the structure of transaction account 18 numeric characters (3+13+2) It is not completed in payment orders 3 Name of recipient Name and head office of a legal person or entrepreneur, or name, last name and the address of a natural person’s residence 335x 335x – alphabet, numerical and alphanumerical characters 4 Transaction account of the recipient Transaction account to be credited 18n As per decision regulating the structure of transaction account 18 numeric codes (3+13+2) It is not completed in payout orders 5 Amount The amount of funds with two digits after the decimal comma 12n,nn Limited to 15 integers (the amount of 12 digits separated with a comma from two subsequent digits (decimals) 6 Payment purpose Purpose, or the basis for payment 535x 535x – alphabet, numerical and alphanumerical characters Completed for all purposes 7 Payment code Numeric data 3n Completed if needed

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 28 8 Model (model of debit reference number) Control number of the reference number calculated according to module 97. Writing of the control number is not prerequisite for the order execution, but if it is entered it must correspond to the prescribed module. The module number determined by a decree governing the manner of the payment of public revenues shall be written for the payment of obligations based on public revenues. 2n Completed if needed 9 Debit reference number Data in accordance with regulations or if needed for the purpose of obtaining additional information on payment transaction. The module number determined by a decree governing the manner of the payment of public revenues shall be written for the payment of obligations based on public revenues. 20x Completed if needed 10 Model (model of credit reference number) Control number of the reference number calculated according to module 97. Writing of the control number is not prerequisite for the order execution, but if it is entered it must correspond to the prescribed module. The module number determined by a decree governing the manner of the payment of public revenues shall be written for the payment of obligations based on public revenues. 2n Completed if needed 11 Credit reference number Data in accordance with regulations or if needed for 20x Completed if needed

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 29 the purpose of obtaining additional information on payment transaction. The module number determined by a decree governing the manner of the payment of public revenues shall be written for the payment of obligations based on public revenues. 12 Execution date Date when the order should be executed DDMMGG Numeric data

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 30 ANNEX 4 Messages in MX and MT format

  1. Messages in MX format Messages Purpose pacs.008 Credit transfer used for the execution of individual payment transactions in the RTGS system. pacs.008 Credit transfer used for the execution of group payment transactions in the DNS system. pacs.009 Payment transaction between participants: used for single payment transactions between participants in the RTGS system camt.054 Confirmation of debit/credit is used as the confirmation of debiting/crediting a participant’s account after executing the payment transaction (pacs. 008 or pacs. 009) camt.060 Account Report Request: used to request information on the participant’s account balance at a given point in time, account status, executed payment transactions, gridlock messages, configured limit, and the total of payment transactions. camt.053 Report provided by CBCG to participants: contains information on executed payment transactions in the RTGS/DNS system. camt.052 Report provided by CBCG to participants on account balance, sent automatically or in response to a query: used to deliver information on account balance and payment transactions executed in the RTGS / DNS system. camt.086 Report on the daily amount of fees payable to the Central Bank for executing payment transactions in the RTGS and DNS systems. camt.056 Request for the cancellation of a previously sent and not yet executed message pacs.008 and pacs.009. camt.029 Response to a cancellation request for a previously sent and not yet executed message (camt.056). pacs.028 Status inquiry regarding a previously sent message pacs.008 and pacs.009. camt.025 Response to camt.007 request, request on changing the priority of payment transaction that is not yet cleared. camt.007 Request to change the priority of a payment transaction that has not yet been settled. camt.033 Request for a copy of the pacs.008 and pacs.009 payment message. camt.034 Response to a request for a copy of a payment message (camt.033). camt.050 Request to set the clearing limit via the user portal. camt.051 Response to a request to set the clearing limit via the user portal (camt.050). camt.048 Request to set the clearing limit via STPA. camt.047 Confirmation and response to a request to set the clearing limit (camt.048) or to a request for information on the set clearing limit (camt.046). camt.046 Request for information on the set clearing limit. camt.018 Request for information on business day periods camt.019 Information and response to the request for information on business day periods (camt.018). pacs.002 Information on the status of the payment message pacs.008 and pacs.009. camt.010 Confirmation and information on the setting of clearing limits, overdraft, or debit cap.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 31 camt.009 Request for information on clearing limits, overdraft, or debit cap. camt.011 Confirmation and information on changes to clearing limits, overdraft, or debit cap. camt.998/ TEXTMESSAGE Free format text message camt.998 CHANGEPASSWORD Notification of a password change. camt.998 LOCKACCOUNT Notification of participant account locking for credit/debit. camt.998 PRTCPNT STATUS Notification of participant status. camt.998 UNLOCKACCOUNT Notification of participant account unlocking for credit/debit. admi.002 Notification on rejection of system-generated message in case the message contains incorrect input. admi.004 System notification of users about password expiration. The Central Bank provides participants in the Payment System with a guide for the implementation of MX messages in accordance with the ISO 20022 standard. 1.1 Characters defining the MX message format: Format Name 6!n Currency date [4!n] Entry date 1a Debit/Credit indicator

  • Funds Code 15d Amount 1!a3!c Transaction Type + Identification Code (Transaction Type + Identification Code) 16x Reference for account owner
  • Reference for participant where the account is opened 4!a2!a2!c[3!c] Additional details 1.2 Allowed characters in MX Messages Allowed characters in MX are: 0 1 2 3 4 5 6 7 8 9 ( ) , . - / ? ‘ : + Space A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 32 1.3 Priority The priority for payment transactions in the RTGS system may be from 0001 to 0099. The value 0001 has the highest priority, while value 0099 has the lowest priority. Priority for payment transactions in the DNS system is 0100. 1.4. Table of messages used in the RTGS and DNS systems - MX format Messages that a participant sends to the RTGS and the DNS systems Messages that the RTGS and the DNS systems sends to a participant pacs.008 – Credit transfer - group pacs.002/pacs.008 pacs.008 – Credit transfer - individual camt.054 (DBIT/CRDT) pacs.002 pacs.009 camt.054 (DBIT/CRDT) pacs.002 camt.060 camt.052 camt.056 camt.029 pacs.028 pacs.002 camt.007 camt.025 camt.033 camt.034 camt.050 camt 051 camt.048 camt.047 camt.046 camt.047 camt.018 camt.019 camt.009 camt.010 camt.011 camt.998 / TEXTMESSAGE camt.998 / TEXTMESSAGE camt.998 CHANGEPASSWORD camt.998 LOCKACCOUNT camt.998 PRTCPNT STATUS camt.998 UNLOCKACCOUNT camt.086 camt.053 admi.002 admi.004 2. Messages in MT format Messages Purpose MT 102 Multiple Customer Credit Transfer is used for multiple customer credit payment transactions of multiple payers within one message in the DNS system MT 103 Single Customer Credit Transfer is used for executing individual payment transactions MT 202 General Financial Institution Transfer is used for single payment transactions between participants at the RTGS system MT 900 Confirmation of Debit is used as the confirmation of debiting a participant’s account after executing the payment transaction (MT 103 or MT 202) MT 910 Confirmation of Credit is used as the confirmation of crediting a participant’s account after executing the payment transaction (MT 103 or MT 202)

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 33 MT 920 Request for Balance and Interim Transactions Reports is used either as a request for balance information of a participant at the defined moment or as a request for sending the report MT 940 Customer Statement Message contains information on payment transactions executed in the RTGS system MT 941 Balance Report is used for sending information on the balance at the account, as a response to MT 920 request requiring information on balance at the specific moment MT 942 Participant Interim Transaction Report contains data on payment transactions from previously submitted interim or daily report. For accounts of state authorities, it has the character of regular reports for their payment accounts MT 970 Netting Statement contains information on payment transactions executed in the DNS system during the specific clearing period MT 972 Interim Netting Statement contains information on payment transactions executed in the DNS system MT 985 Query Message is used as an enquiry on account status, on messages at the queuing list, limits set and totals of payment transactions in the DNS system MT 986 Report on Account Requests is used to respond to participant’s enquiry asked by the MT 985 MT 991 Request for Payment of Charges, Interest and Other Expenses is used for executing payment transaction in the RTGS and DNS systems MT 192 Request for Cancellation is used for previously sent and, until the moment, non￾executed messages MT 103 or MT 102 MT 292 Request for Cancellation is used for previously sent and, until the moment, non￾executed message MT 202 MT 195 Queries to Transfer on the status of previously sent message MT 103 or MT 102 MT 295 Queries to Transfer on the status of previously sent message MT 202 MT 196 Reports on Transfers to query MT 195 or system information on the status of previously sent message MT 103 or MT 102 MT 296 Reports on Transfers to query MT 295 or system information on the status of previously sent message MT 202 MT 999 Free Format Message 2.1 Message structure 2.1.1 MT message header Each instruction contains information on participant in the RTGS system as the sender or recipient from/to RTGS system and on the RTGS system itself. An example of “Message header” is given in the table below:

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 34 Participant → RTGS system No. of segment Name of field Participant → RTGS system 1: Sender HBBAMEPGXXX Hipotekarna banka AD Podgorica 2: Type of message 103 2: Recipient CBCGMEPGXIPSN RTGS - system Podgorica RTGS system → participant No. of segment Name of field RTGS system → participant 1: Recipient UNCBMEPGXXXX RTGS - system Podgorica 2: Type of message 103 2: Sender CBCGMEPGAIPS Hipotekarna banka AD Podgorica 2.1.2. Characters defining the MT message format: SWIFT field structure: Character Description Examples n Numeric field 18n – numeric field up to 18 characters ! Behind a number represents a fixed length determined by that number 18!n – field of fixed 18 numeric characters a Exclusively alphabetic field (capital letters) 4!a – exactly four alphabetic characters d Decimal field 15d – numeric field with two decimals up to 15 characters (12n,nn) x Alphabetic, numeric and sign field 35x – represents up to 35 alphabetic, numeric and sign characters c Alphabetic-numeric field 3c – field containing 3 alphabetic, 3 numeric or 3 alphabetic-numeric characters 335x First number determines the number of lines, and the second one the number of character per line 335x – 3 lines, each containing up to 35 characters [ ] Field in square brackets are optional [1!a] – in certain cases this field has fixed one character, otherwise it is left blank → ----I Fields between these two signs can be repeated several times

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 35 Allowed characters in SWIFT are: 0 1 2 3 4 5 6 7 8 9 ( ) , . - / ? ‘ : + Space A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f g h i j k l m n o p q r s t u v w x y z 2.1.3. Priority The priority for payment transactions in the RTGS system may be from 0001 to 0099. The value 0001 has the highest priority, while value 0099 has the lowest priority. Priority for payment transactions in the DNS system is 0100. 2.1.4. ACK/NAK confirmation ACK/NAK confirmation exists only in the XML format. ACK confirmation is sent to the participant in the case of successful pre-processing of a message. NAK confirmation is sent to the participant in the case of error in pre-processing of a message. 2.1.5. Table of messages used in the RTGS and DNS systems - MT format Messages that a participant sends to the RTGS and the DNS systems Messages that the RTGS and the DNS systems sends to a participant MT 102 MT 196 MT 970, MT 972 MT 103 MT 900, MT 910, MT 196 MT 202 MT 900, MT 910, MT 296 MT 985 MT 986 MT 920 MT 940, MT 941, MT 942 MT 192 MT 196 MT 195 MT 196 MT 292 MT 296 MT 295 MT 296 MT 999 MT 999 MT 991 3. Core messages according to MT standard 3.1 Message MT 102 – Multiple orders for payments in DNS system Message MT 102 is used for multiple transactions of funds for the account of multiple customers (for the account of participants in the DNS system). All transactions in a message need to have the same value date, whereby a participant - the sender is the same for all debits, and a participant – the recipient is the same for all credits. The sum of individual transactions has to correspond to the amount in the field 32A.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 36 The structure of elements is as follows: Field Elements of transfer order Format Mandatory Note Sender yes Recipient yes 113 Priority with value 100 determines whether payment transactions shall be executed in the DNS 4n yes Example: 113:0100 20 Message recipient 16x yes Message TRN 23 CREDIT 6!a yes CREDIT-fixed value 26T Payment transaction code type 3!n Default value is 001 71A SHA 3!a → 21 Payment transaction reference 16x yes 32B Currency code (EUR) and amount (12n,nn) 3!a15d yes Example: 32B:EUR100,00 50K Account of payer to be debited (3n￾13n-2n) / 18!n35x 3*35x yes Example: :50K:/580000000000123475 PAYER OF BENEFICIARY A Ul. Slobode br.2 PODGORICA Name of payer:

  • Name (of legal person or entrepreneur; natural person)
  • address
  • place 59 Account of recipient of payment to be credited (3n-13n-2n) / 18!n35x 3*35x yes Example: :59:/570000000000873444 RECIPIENT OF PAYMENT OF BENEFICIARY B Ul. Balšićeva br.5 BUDVA Name of recipient:
  • Name (of legal person or entrepreneur; natural person)
  • address
  • place 70 Information on remitting of funds:
  • Payment code
  • Field code PBZ followed by model of debiting reference and debiting reference separated by hyphens
  • Field code PBO followed by model of crediting reference and crediting reference separated by hyphens 435x SIF-3n PBZ-2n￾20x PBO-2n￾20x yes Example of proposed format: :70:SIF-120 PBZ-00-12345 PBO-00-4567-2008 77B Payment purpose 335x yes Example: :77B: PAYMENT PER INVOICE NO. 4567 ----I

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 37 32A - Execution date (YYMMDD),

  • Currency code (EUR for euro) and
  • amount – sum of all transactions (12n,nn) 6!n3!a15d yes Example (for 10 orders of EUR 20.00 each): :32A:0907029EUR200,00 53A Participant which account is debited: /D/ Participant’s account /D/18!n 4!a2!a2!c[3 !c] yes Example: :53A:/D/90700000000580013 8 BIC of the participant CKBCMEPG 54A Participant which account is credited: /C/ Participant’s account /C/18!n 4!a2!a2!c[3 !c] yes Example: :54A:/C/90700000000570013 1 BIC of the participant PDBPMEPG 3.2 Message MT 103 – Transfer of funds for the account of a beneficiary being a RTGS system participant Message MT 103 enables transfer of funds for the account of a beneficiary being a RTGS system participant. The structure of elements is as follows: Fiel d Elements of transfer order Format Mandatory Note Sender yes Recipient yes 113 For payment transactions in RTGS system, priority ranges between 0010 and 0099. Value 0010 is for highest priority; if the priority is not indicated, default value is 0099 4n Example: 113:0099 20 Message reference 16x yes Message TRN 23B CRED 4!c yes CRED-fixed value 23E SDVA 4!c[30x] yes SDVA 26T Transaction code type 3!n Default value is 001 32A Execution date (YYMMDD), currency code (EUR) and Amount (12n,nn) 6!n3!a15d yes Example: :32A:090123EUR453,6 9 50K Account of payer to be debited (3n-13n￾2n) / 18!n35x 3*35x yes Example: :50K:/58000000000012 3475 PAYER OF BENEFICIARY A Ul.Slobode br.23 PODGORICA Name of payer to be debited:
  • Name (of legal person or entrepreneur; natural person)
  • address
  • place

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 38 53A Participant which account is debited: /D/ Participant’s account /D/18!n 4!a2!a2!c[ 3!c] yes Example: :53A:/D/907000000005 800138 CKBCMEPG BIC of the participant 57A Participant which account is credited: /C/ Participant’s account /C/18!n 4!a2!a2!c[ 3!c] yes Example: :57A:/C/9070000000057 00131 PDBPMEPG BIC of the participant 59 Account of recipient of payment to be credited (3n-13n-2n) / 18!n35x 3*35x yes Example: :59:/5700000000008734 44 RECIPIENT OF PAYMENT OF BENEFICIARY B Ul.Balšićeva br.8 PODGORICA Name of recipient of payment to be credited:

  • Name (of legal person or entrepreneur; natural person)
  • address
  • place 70 Information on funds remitting:
  • Payment code
  • Field code PBZ followed by model of debiting reference and debiting reference separated by hyphens
  • Field code PBO followed by model of crediting reference and crediting reference separated by hyphens 435x SIF-3n PBZ-2n￾20x PBO-2n￾20x Yes Example of proposed format: SIF-132 PBZ-05-02731266 PBO-05-35092-09-001- 4000247 71A SHA 3!a Yes 72 Payment purpose Code CODTYPTR/001 is entered at the beginning 35x 535x Yes Example: :72:/ CODTYPRT/001 /customs debt NOTE: When paying public revenues, field 70 of message MT 103 is completed as follows: 70 Information on funds remitting:
  • Number of payment accounts (Tax Administration, Customs Administration, Ministry of Internal Affairs or Central Account of State Treasury)
  • Payment code (SIF- 3n) 4*35x SIF-3n PBZ-2n-20x Yes Example of proposed format: :70:/ TC/805000000000095502 SIF-132

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 39

  • Field code PBZ followed by model of debiting reference and debiting reference separated by hyphens
  • Field code PBO followed by model of crediting reference and crediting reference separated by hyphens PBO-2n￾20x PBZ-05-02731266 PBO-05-35092-09-001- 4000247 3.3 Message MT 202 – Payment transaction between participants in the RTGS system Message MT 202 is used for payment transaction between participants in the RTGS system. The structure of elements is as follows: Field Elements of payment transaction order Format Mandatory Note Sender Yes Recipient Yes 113 The priority for payment transactions in the RTGS system may be from 0010 to 0099. Value 0010 is for highest priority; if the priority is not indicated, default value is 0099 4n Yes Example: 113:0099 20 Message reference 16x Yes Message TRN 21 Related reference 16x Yes Reference to which the message refers or enter code NONREF 32A Execution date (YYMMDD), currency code (EUR) and
  • amount (12n,nn) 6!n3!a15d Yes Example: 32A:090126EUR150,39 53A Participant which account is debited: /D/ Participant’s account /D/18!n 4!a2!a2!c[3! c] Yes Example: :53A:/D/90700000000580 0138 CKBCMEPG BIC of the participant 58A Participant which account is credited: /C/ Participant’s account /C/18!n 4!a2!a2!c[3! c] Yes Example: :58A:/C/90700000000570 0131 PDBPMEPG BIC of the participant 72 Code CODTYPTR/001 is entered at the beginning Information on funds remitting: Payment transaction type code
  • Payment code (SIF- 3n) 5*35x (001) SIF-3n Yes Example of proposed format: :72:/CODTYPRT/001 //SIF-383

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 40

  • Field code PBZ followed by model of debiting reference and debiting reference separated by hyphens
  • Field code PBO followed by model of crediting reference and crediting reference separated by hyphens
  • Payment purpose (lines 2-5 have to be started with two slashes (//)) PBZ-2n20x PBO-2n20x 35x //PBZ-00 //PBO-00-00-401- 0115296-2 // PAYMENT OF LOAN INSTALMENT NOTE: The participants in the RTGS system shall complete field 72 of the message MT 202 with regard to cash payments to and from the account in banknotes and coins as follows:
  • For cash payments to and from the participant’s account in banknotes: 72 Code CODTYPTR/002 is entered at the beginning Information on funds remitting:
  • Payment transaction type code
  • Payment code
  • Field code PBZ followed by model of debiting reference and debiting reference separated by hyphens
  • Field code PBO followed by model of crediting reference and crediting reference separated by hyphens
  • Payment purpose (lines 2-5 have to be started with two slashes (//)) 5*35x (002) SIF-3n PBZ-2n20x PBO-2n20x 35x Yes Example of proposed format: :72:/CODTYPTR/002 //SIF-383 //PBZ-00 //PBO-00-00-401-0115296-2 // CASH PAYMENTS TO AND FROM THE ACCOUNT IN BANKNOTES
  • For cash payments to and from the participant’s account in coins 72 Code CODTYPTR/003 is entered at the beginning Information on funds remitting:
  • Payment transaction type code
  • Payment transaction code (SIF- 3n)
  • Field code PBZ followed by model of debiting reference 5*35x (003) SIF-3n PBZ-2n20x Yes Example of proposed format: :72:/CODTYPTR/003 //SIF-383 //PBZ-00

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 41 and debiting reference separated by hyphens

  • Field code PBO followed by model of crediting reference and crediting reference separated by hyphens
  • Payment purpose (lines 2-5 have to be started with two slashes (//)) PBO-2n20x 35x /PBO-00-00-401-0115296-2 // CASH PAYMENTS TO AND FROM THE ACCOUNT IN COINS Messages that do not contain valid CODTYPTR (/CODTYPTR/002 for banknotes and /CODTYPTR/003 for coins) shall be rejected. 4 Category 9 – Confirmation on receipt, account status and reports 4.1 Message MT 900 – Confirmation of account debiting Message MT 900 is used as a confirmation of account debiting after the executed payment transaction (MT 103 or MT 202). The RTGS system sends the message to participant. The structure of elements is as follows: Field Message element Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes TRN of the message to which the confirmation refers 25: Account of participant to be debited 18!n Yes :25:907000000005800138 32A Execution date (YYMMDD), currency code (EUR) and amount (12n,nn) 6!n3!a15d Yes Example: :32A:090123EUR453,69 52A BIC of participant executing payment transaction for a third party 4!a2!a2!c[ 3!c] :52A:CBCGMEPGRTG 72 Information from sender to recipient /3!a/ 16!n /8!a/ 12!c /7!c/ 26x 16x 4*35x MT 900 message for MT 103 and MT 202 payment messages does not contain fields 52A and 72 MT 900 message from clearing contains fields 52A and 72

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 42 4.2 Message MT 910 – Confirmation of account crediting Message MT 910 is used as a confirmation of account crediting after the execution of payment transaction (MT103 or MT 202). The RTGS system sends the message to the participant which account is credited. The structure of elements is as follows: Field Message element Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes TRN of the message to which the confirmation refers 25 Account of participant to be credited 18!n Yes :25:907000000005700131 32A Execution date (YYMMDD), currency code (EUR) and amount (12n,nn) 6!n3!a15d Yes Example: :32A: 090123EUR453.69 52A Account of participant to be credited BIC of the participant to be credited 18!n 4!a2!a2!c[3 !c] Yes Example: :52A:/D/90700000000580013 8 FFBMMEPG 72 Information from sender to recipient /3!a/ 16!n /8!a/ 12!c /7!c/ 26x 16x 4*35x 4.3 Message MT 920 – Request for account balances and transaction reports Message MT 920 is used as a request for information on account balances at the specific moment or request for the delivery of report on executed payment transactions of a participant. The participant sends this message to the RTGS system. The structure of elements is as follows: Field Message element Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN → 12 Identifies the type of message for which the request is sent 3!n Yes There has to be one of these message types: 940,941 and 942.

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 43 25 Number of account to which 18!n Yes 907000000005800138 34F currency code - EUR sign D (for debiting) or empty the limit below which transactions are not included in the report (12n,nn) 3!a[1!a]15d Example: :34F:EURD10, 34F currency code - EUR sign C (for crediting) or empty the limit below which payment transaction is not included in the report (12n,nn) 3!a Example: :34F:EURC10, If two fields of 34F are present, the first 34F field must contain sign D, while the latter 34F must contain sign C, while if only a single field 34F is used, signs C or D should not be used – it implies a debiting limit. 4.4 Message MT 940 – Report on executed payment transactions of the participant Message MT 940 is a daily report on executed payment transactions of the participant and it is the response to send request MT 920. The RTGS system sends the message MT 940 to the participant. The structure of elements is as follows: Fiel d Message element Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes TRN in SWIFT 25 Participant’s account number 18!n Yes Number of account to which the message refers 28C Report number 5n Yes 60F Opening balance in the form: debit / credit (D/C) date - YYMMDD, currency code – EUR amount – (12n,nn) 1!a6!n15d Yes Example: :60F:C090628EUR1000 , → 61 First report line:

  • execution date – YYMMDD,
  • debit (D), credit (C) ….,
  • amount (12n,nn),
  • code for identifying payment transaction type,
  • reference to account owner,
  • reference institution servicing the account Second report line:
  • number of account that caused the change 6!n2a15d1!a3 !c16x //16x 4!a2!a2!c[3!c ] 18!n

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 44 86 - first row – account of payer to be debited (code MT 103-field 50K and code MT 202 field 53A)

  • second row – account of client to be credited (code MT 103 – field 59 and code MT 202 field 58A)
  • next 4 lines of the report are field 70 of message MT103. 4!a2!a2!c[3!c ] 4!a2!a2!c[3!c ] 4!a[/6!n4!n1! x4!n]

-I 62F Closing balance:

  • debit / credit (D/C)
  • execution date - YYMMDD
  • currency code - EUR
  • amount – (12n,nn) 1!a6!n3!15d Yes Example: :62F:C091010EUR1000 , 4.5 Message MT 941 – Balance Report Message MT 941 is used for sending information on balance at the specific moment, as a response to MT

The structure of elements is as follows: Field Message element Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Connecting reference 16x Yes Reference of message МТ 920, with which this message was initiated 25 Account number 18!n Yes Number of account to which message refers 28 Balance number/Message sequence 5n Yes 13D Date and time of message creation 6!n4!n1!x4 !n No 2505060906+0200 60F Opening balance in the form:

  • debit/credit - D/C
  • date - YYMMDD,
  • currency code - EUR,
  • amount (12n,nn). 1!a 6!n 3!a 15d Yes Example: :60F:C090628EUR59577 1,00 90D - Number of debit payment transactions
  • currency code - EUR
  • amount debit payment transactions 5n3!a15d Yes Example: :90D:8EUR385920,00 90C - Number of credit payment transactions
  • currency code - EUR
  • amount credit payment transactions 5n3!a15d Yes Example: :90C:5EUR450000,00

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 45 62F Closing balance for date in the form:

  • debit / credit (D/C)
  • date - YYMMDD,
  • currency code – EUR
  • amount (12n,nn). 1!a 6!n 3!a 15d Yes Example: :62F:C091111EUR65985 1,00 64 Available balances in the form:
  • debit / credit (D/C)
  • execution date - YYMMDD
  • currency code – EUR
  • amount (12n,nn). 1!a 6!n 3!a 15d Example (in case EUR 179.226,00 has been reserved for clearing): :64:C091111EUR480625, 00 4.6 Message MT 942 –Participant Interim Transaction Report Message MT 942 contains data on payment transactions from previously taken interim or daily report, as a response to request МТ 920. The structure of elements is as follows: Field Message element Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Connecting reference 16x Reference of message МТ 920, with which this message was initiated 25 Account number 18!n Yes Number of account to which 28C Number of reports / page number of report 5n Yes 34F
  • currency code - EUR
  • sign D (for debiting) or empty
  • the limit below which transactions are not included in the report (12n,nn) 3!a[1!a]15d Yes Example: :34F:EURD10,00 34F
  • currency code - EUR
  • sign C (for crediting) or empty
  • the limit below which transactions are not included in the report (12n,nn) 3!a[1!a]15d Example: :34F:EURC10,00 13D Date and time of sending YYMMDDHHMM+0100 6!n4!n1!x4 !n Yes Example: 0908261050+0100 → 61 Report line:
  • execution date – YYMMDD,
  • debit (D), credit (C), expected debit (ED), expected credit (EC)
  • amount, 6!n 4!n 2a

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 46

  • code for identifying payment transaction type,
  • reference to account owner,
  • reference institution servicing the account
  • account number 15d 1!a3!c 16x //16x 18!n 86 - first row - account of client to be debited (code MT 103 - field 50K and code MT 202 field 53A)
  • second row – account of client to be credited (code MT 103 – field 59 and code MT 202 field 58A)
  • next 4 lines of the report are field 70 of message MT103. 6*65

I 90D - Number of debit payment transactions

  • currency code - EUR
  • amount 5n3!a15d Example: :90D:2EUR2000,00 90C - Number of credit payment transactions
  • currency code - EUR
  • amount 5n3!a15d Example: :90C:8EUR1000,00 If two 34F fields are present, the first 34F field must contain sign D, while the latter 34F must contain sign C, while if only a single field 34F is used, signs C or D should not be used – it implies a debiting limit. 4.7 Message MT 970 – Report on executed payment transactions in the DNS system and MT 972 - Interim report on executed payment transactions in the DNS system Message MT 970 is the report on executed payment transactions in the DNS system. It is sent automatically at the end of the cycle, while message MT 972 is sent at request and includes payment transactions from the last MT 970 or MT 972. The structure of elements is as follows: Field Message element Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 25 Participant’s account number 18!n Yes Number of account to which the message refers 28C Number of reports / page number of report 5n Yes 60F Opening balance in the form:
  • debit/credit - D/C
  • date - YYMMDD
  • currency code – EUR 1!a6!n15d Yes Example: :60F:C090126EUR0,

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 47 amount (12n,nn). → 61 First report line:

  • execution date – YYMMDD,
  • debit (D), credit (C) ….,
  • amount (12n,nn),
  • code for identifying payment transaction type,
  • reference to account owner,
  • reference institution servicing the account Second report line:
  • BIC of the participant 6!n 4!n 2a 1!a 15d 1!a3!c 16x //16x 34x 4!a2!a2!c[3! c] :61:090126D53,30S1028 90560000003832c//2441 6664 HBBAMEPG

I 62F Closing balance with the date of sending:

  • debit/credit - D/C
  • date - YYMMDD, currency code - EUR, amount (12n,nn). 1!a6!n3!c15 d Yes Example: :62F:C090126EUR1592, 76 4.8 Message MT 985 – Query message A participant sends the message MT 985 for enquiry on their account status to which the system responds with the MT 986 message. The structure of elements is as follows: Field Message element Format Mandatory Note 20 Message recipient 16x Yes Message TRN 57A BIC in RTGS system 4!a2!a2!c[3!c ] Example: :57A:CBCGMEPGIPS 59 Account of the participant to which the query of the BIC refers /18!n 4!a2!a2!c[3!c ] Yes Field “Account to which the query of the BIC refers” (/18!n) is not mandatory for following queries: PCLT, TTLS i TTLD Example: :59:ATLMMEP2 BIC of the participant 75 Queries Description of formats depending on request: Yes Type of query: 4!a STAT – account status

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 48 4!a SQDC – report on queue 4!a PCLT – set clearing limit 4!a [6!n/]16x

  • TTLS – clearing session totals in DNS system
  • YYMMDD, slash followed by session (e.g. MORNING, EVENING or FINAL) 4.9 Message MT 986 – Report on account request Message MT 986 is automatically generated and sent to the participant upon completion of the clearing cycle, and it also serves as a response to the query sent via the MT 985 message. Responses supported by the RTGS system are given in field 79. The structure of elements is as follows: Field Message element Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Message reference to which the response refers 16x Yes 59 Account of the participant to which the query refers /18!n 4!a2!a2!c[3!c] Yes Example: :59:PDBPMEPG BIC of the participant 79 Response Yes Possible responses to STAT query: /4!a/ / 6!n4!n1!x4!n 2!a /1!a/12a/15n STAT/ Possible responses to query on status (second line of response):
  • The account is not frozen
  • The account is frozen for debiting
  • The account is frozen for crediting
  • The account is frozen 2!a AA - code DA - code AC - code DC - code

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 49 Possible responses to SQDC query: Sum and number of suspended payment transactions debiting the account Sum and number of suspended payment transactions crediting the account Sum and number of suspended payment transactions in queue debiting the account Sum and number of suspended payment transactions in queue crediting the account

  • Sum and number of payment transactions that froze debiting of the account Sum and number of payment transactions that froze crediting of the account Current account balance (CC credit or CD debit) available account balance (AC credit or AD debit) 4!a[/6!n4!n1!x 4!n] 2!a3!a15d[/5n] 2!a3!a15d[/5n] 2!a3!a15d[/5n] 2!a3!a15d[/5n] 2!a3!a15d[/5n] 2!a3!a15d[/5n] 2!a3!a15d[/5n] 2!a3!a15d[/5n] SQDC/ Possible responses to query (second line of response): SDEUR153994,21/14 (code SD) SCEUR0,/0 (code SC) EDEUR153994,21/14 (code ED) ECEUR0,/0 (code EC) LDEUR0,/0 (code LD) LCEUR0,/0 (code LC) CCEUR1988850,07/3 (code CC,CD) ADEUR1988850,07/3 (code AC,AD) Response to query on set limit: PLCT/date and time
  • Account to which the query refers
  • value date, set limit
  • value date, value of field is 0
  • value date, net balance position in current session
  • current session 4!a[/6!n4!n1!x 4!n] /18!n 6!n3!a15d 6!n3!a15d 1!a6!n3!a15d PCLT/0901260901+0000 /907000000005800138 090126EUR150000, 090126EUR0, C090126EUR0, MORNING

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 50 Responses to TTLS queries contain data on query in the first line, number of received messages in the second line, number of accepted, settled, in queue and rejected messages. Date and section 4!a[/6!n4!n1!x 4!n] 5d/5d/5d 17d/5d/5d 6!n16x TTLS/ 5 Category n – Common Group Messages 5.1 Message MT n91 – Report on daily charge of the Central Bank fee for executing payment transactions in the RTGS and DNS systems Message MT 991 is sent as a Report on daily charge of the Central Bank fee for executing payment transactions in the RTGS and DNS systems. The structure of elements is as follows: Field Elements of transfer order Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes NONREF 32B Currency code (EUR) Amount (12n,nn) 3!a15d Yes Example: :32B:EUR6,76 52A BIC of the participant to be credited 4!a2!a2!c[3!c ] Yes Example: :52A:PDBPMEPG 57A BIC of the Central Bank of Montenegro to which the fee is paid 4!a2!a2!c[3!c ] Yes Example: :57A:CBCGMEPG 71B Details on debiting 4!c 6!n Yes 72 Information from sender to recipient 9!c :72:/INT/ 5.2 Message MT n92 – Request for Cancellation Message MT 192 is used as the request for cancelation of previously sent messages MT 103 and MT 202, and the message MT 292 is used for the cancelation of the MT 202 message. The message may be recalled as long as it has not been executed. The structure of elements is as follows: Field Elements of transfer order Format Mandatory Note

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 51 Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes TRN of message to which the request refers 11S MT number 3!n 6!n Yes Example: 11S:103 Date - YYMMDD 090104 79 BIC of the participant who sent the message 4!a2!a2!c[3! c] 6!n Yes Example: :79: PDBPMEPG 090104 Execution date - YYMMDD 5.3 Message MT n95 – Queries on previously sent messages Message MT 195 is used as enquiry on previously sent messages MT 103 and MT 102, and the message MT 295 is used as enquiry on previously sent message MT 202. The structure of elements is as follows: Field Elements of transfer order Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes TRN of message to which the request refers 75 Queries 4!a Yes Possible queries: STAT - Message status PRTY – priority change DUPL – Message duplicate 77A The field is used only when changing the priority (if the field :75: contains code PRTY) 4!a The field is mandatory only for query PRTY, Example: 77A:0020 11S MT number 3!n 6!n Example: :11S:103 Date - YYMMDD 090104 79 BIC of the participant who sent the message 4!a2!a2!c[3! c] 6!n Example: :79: PDBPMEPG Execution date 090104

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 52 5.4 Message MT n96 – Responses Message MT 196 is the response to requests and queries to previously sent messages MT 192 or MT 195, while message MT 296 is the response to requests and queries to previously sent messages MT 292 or MT 295. In addition to the aforementioned, the system automatically generates messages MT 196 and MT 296. The generated MT196 message informs the participant about the status of a previously sent MT102 or MT103 message, while the MT296 message informs about the status of a previously sent MT202 message. The structure of elements is as follows: Field Message element Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes TRN from field 20: of message n95 to which the response is made 76 Responses 4!a / 6!n4!n1!x4!n 4!c / 6!n4!n1!x4!n Yes Responses to requests: STAT – statuses given in the table below DUPL – message duplicate PRTY – priority change CANC – message is cancelled ERRC – message on error in request 77A Textual description of response (it refers to the error in request or query) 2!35x35x If the response contains error write the code in the first line, and the description of error in the last two lines 11R MT number – message number 3!n 6!n Yes Example: :11R:202 090628 Date - YYMMDD 20 Copy containing at least all mandatory fields of original message 16x 30 Date of the message for which the status is being provided 6!n Example: 250509 82A BIC of the sender 4!a2!a2!c[3!c] Example: CKBCMEPG In response to a status inquiry (STAT), field 76 may contain the following responses in the MT message:

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 53 STAT/date, time - first line of response REJT /date, time - second line of response Message was rejected with message MT n92 sent by the participant STAT/date, time - first line of response CANC/date, time - second line of response Message was cancelled due to the rules of the CBCG RTGS system, it is also sent when CBCG rejects the message without request STAT EXEC Payment transaction is being executed STAT SETL Payment transaction is executed STAT WAIT The message is in the queue STAT SUSP The message is suspended STAT ERRP There was an error STAT INAC A message with a future value date cannot be executed within the current business day. STAT AUTH The message is pending authorization. STAT ACSP The message has been published and a copy delivered to the recipient. STAT PROC The group credit transfer is suspended due to the business day schedule. Field 76 of Enquiry on message duplicate (DUPL) may contain the following responses: DUPL - first line of response OK - second line of response Requested message will be copied Field 76 of Enquiry on priority change (PRTY) may contain the following responses: PRTY - first line of response <changer priority> - second line of response Payment transaction priority is changed PRTY ERRC Error in priority changing Field 76 of Enquiry on message cancelling (CANC) may contain the following responses: CANC – payment transaction is cancelled OK - second line of message Payment transaction is cancelled CANC ERRC Error in request processing Message on error as a response to enquiry MT n95 or MT n92 in the field 76 gives only one row with the code ERRC, while field 77A gives the description of the error. 5.5 Message MT n99 – Free Format Message

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 54 Message MT 999 is a free format message. The structure of elements is as follows: Fiel d Elements of transfer order Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x 79 Message text: 3550x Yes /TEXTMESSAGE/BIC /11!c/4!a2!a2!c[3 !c] 3450x Example: /TEXTMESSAGE/ PDBPMEPG Notification of Account Locking: /LCKA/ /4!a/6!n4!n1!x4!n /ACNT/34x /LDBT/Y /LCDT/Y Example: :/LCKA/2403101748+0200 /ACNT/90700000000540011 0 /LDBT/Y /LCDT/Y Notification of Account unlocking: /ULKA/ /4!a//11!c/12x 6!n4!n1!x4!n /ACNT/34x /UDBT/Y /UCDT/Y /ULKA/2403101748+0200 /ACNT/90700000000540011 0 /UDBT/Y /UCDT/Y Setting the account limit: /SETACCOUNTLIMIT/CLEA RING /STATUS/ /ACTION/ /DIRECTION/I (for limit increase) or D (for limit decrease) /ACCOUNT/ account number /AMOUNT/ amount – new limit /15!a/12x /7!a/34x /6!a/15d Example: /SETACCOUNTLIMIT/CLE ARING /STATUS/ /ACTION/ /DIRECTION/I /ACCOUNT/ 907000000005050134 /AMOUNT/ 1000,00 Notification of Set Limit on Account: SETACCOUNTLIMIT/CLEA RING /8!a/ /15!a/12x /7!a/34x /6!a/15d /ACCOUNT/9070000000050 50134 /AMOUNT/800000.70

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 55 Request for information on the account limit. /GETACCOUNTLIMIT/ /15!a/ /7!a/34x /GETACCOUNTLIMIT/ /ACCOUNT/9070000000050 50134 Response to the Request for Information on Account Limit: /RETACCOUNTLIMIT/ /15!a/ /7!a/34x /7!c/12x /6!a/15d /RETACCOUNTLIMIT/ /ACCOUNT/9070000000050 50134 Request for report on the business day period: /GETBUSINESSDAYPERIOD / Notification on the business day period: /BUSINESSDAYPERIOD/ /20x/ /17a/ 335x Notification/Warning About Impending Password Expiry: /PASSWORDEXPIRATION/ /18!a/ 30x //48x /PASSWORDEXPIRATION / /PASSWORDEXPIRATION /User should change password in 3 days Notification That Password Has Expired: /PASSWORDEXPIRED/ /15!a/ 33x //48x /PASSWORDEXPIRED/ /PASSWORDEXPIRED/Use r must change password now or will be blocked Password Change Request: /CHANGEPASSWORD/ Password Change Confirmation CHANGEPASSWORD/OK /14!a/34x [1650x] /11!a/37x [16*50x] /14!a/ 2!a /CHANGEPASSWORD/800 00000712921E0E4C2C5468 ED3B /OLDPASSWORD/8000000 08E0E112A86ED8417B32F 2028A0 /CHANGEPASSWORD/ OK

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 56 ANNEX 5

Participant’s stamp REQUEST FOR CHANGING MESSAGE PRIORITY IN THE RTGS SYSTEM Participant: Participant’s account: Type of message which change in priority is requested: Existing message priority: Requested message priority: Message recipient Amount of payment transaction: Place and date:

Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 57 ANNEX 6 REQUEST FOR CANCELLING PAYMENT TRANSACTION MESSAGES IN THE RTGS AND DNS SYSTEM

Participant’s stamp a) REQUEST FOR CANCELLING PAYMENT TRANSACTION MESSAGES IN THE RTGS SYSTEM Participant: Participant’s account: Type of messages which cancellation is requested: Message recipient Amount of payment transaction: Place and date:

Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 58

Participant’s stamp b) REQUEST FOR CANCELLING PAYMENT TRANSACTION MESSAGES IN THE RTGS SYSTEM Participant: Participant’s account: Type of messages which cancellation is requested: Message recipient Amount of payment transaction: Place and date:

Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 59 ANNEX 7 APPLICATION FOR RESENDING MESSAGES FROM THE RTGS AND DNS SYSTEM

Participant’s stamp a) REQUEST FOR RESENDING MESSAGES FROM THE RTGS SYSTEM Participant: Participant’s account: Type of messages to be resent: Message recipient Amount of payment transaction: Place and date:

Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 60

Participant’s stamp b) REQUEST FOR RESENDING MESSAGES FROM THE DNS SYSTEM Participant: Participant’s account: Type of messages to be resent: Message recipient Amount of payment transaction: Place and date:

Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 61 ANNEX 8 COMPLAINT TEMPLATE FOR PAYMENT TRANSACTIONS EXECUTED IN THE RTGS AND DNS SYSTEM

Participant’s stamp a) COMPLAINT TEMPLATE FOR PAYMENT TRANSACTIONS EXECUTED IN THE RTGS SYSTEM Participant: Participant’s account: Subject of complaint: List of enclosed documents: Type of the message used for execution of payment transactions, message reference, other messages referring to the payment transaction in question, statement on executed payment transaction, and the like. Place and date:

Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 62

Participant’s stamp b) COMPLAINT TEMPLATE FOR PAYMENT TRANSACTIONS EXECUTED IN THE DNS SYSTEM Participant: Participant’s account: Subject of complaint: List of enclosed documents: Type of the message used for execution of payment transactions, message reference, other messages referring to the payment transaction in question, statement on executed payment transaction, and the like. Place and date:

Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 63 ANNEX 9 DAILY WORK TIME SCHEDULE OF RTGS AND DNS SYSTEMS a) DAILY WORK TIME SCHEDULE OF THE RTGS SYSTEM Beginning of Day 08.30-09.00 Exchange of payment transaction messages 09.00-20.00 Stop RTGS system 20.00-20.01 Rejecting non-executed messages 20.01-20.05 Creating reports on executed payment transactions 20.05-20.15 Creating reports on the daily charge of the Central Bank fee 20.15-20.25 Archiving 20.25-20.50 End of Day 20.50 b) DAILY WORK TIME SCHEDULE OF THE DNS SYSTEM Beginning of Day 08.30-09.00 Exchange of payment transaction messages 09.00-19.30 Clearing (the first cycle) 10.00-10.15 Clearing (the second cycle) 12.00-12.15 Clearing (the third cycle) 14.00-14.15 Clearing (the fourth cycle) 16.00-16.15 Clearing (the fifth cycle) 18.00-18.15 Preparation for the sixth cycle (pre-clearing) 19.15-19.30 Clearing (the sixth cycle) 19.30-19.45 Stop clearing 19.45 -20.00 Rejecting non-executed messages 20.01-20.05 Creating reports in the RTGS system on net position in the DNS system 20.05-20.15 Archiving 20.25 -20.50 End of Day 20.50

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 64 c) DAILY WORK TIME SCHEDULE OF THE RTGS SYSTEM ON WEEKENDS AND HOLIDAYS Beginning of Day 08.30-09.00 Exchange of payment transaction messages 09.00-15.00 Stop RTGS system 15.00-15.01 Rejecting non-executed messages 15.01-15.05 Creating reports on executed payment transactions 15.05-15.15 Creating reports on the daily charge of the Central Bank fee 15.15-15.25 Archiving 15.25-15.50 End of Day 15.50 d) DAILY WORK TIME SCHEDULE OF THE DNS SYSTEM ON WEEKENDS AND HOLIDAYS Beginning of Day 08.30-09.00 Exchange of payment transaction messages 09.00-14.30 Clearing (the first cycle) 10.00-10.15 Clearing (the second cycle) 12.00-12.15 Preparation for the third cycle (pre-clearing) 14.15-14.30 Clearing (the third cycle) 14.30-14.45 Stop clearing 14.45--15.00 Rejecting non-executed messages 15.01-15.05 Creating reports in the RTGS system on net position in the DNS system 15.05-15.15 Archiving 15.25--15.50 End of Day 15.50

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 65 ANNEX 10 REQUEST FOR EXTENDING OPERATIONS OF RTGS AND DNS SYSTEMS a) REQUEST FOR EXTENDING OPERATIONS OF THE RTGS SYSTEM Participant: Participant’s account: Reason for extending the operations: Time of extension of operations in minutes: Place and date:

Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 66 b) REQUEST FOR EXTENDING OPERATIONS OF THE DNS SYSTEM Participant: Participant’s account: Reason for extending the operations: Time of extension of operations in minutes: Place and date:

Stamp and signature of authorised person

[unofficially consolidated translation]

Operating Rules of the Central Bank of Montenegro Payment System (OGM 048/14, 050/14, 057/14, 047/25, 074/25, 098/25) 67 ANNEX 11

Participant’s stamp REQUEST FOR DETERMINING OR CHANGING THE LIMIT FOR NEGATIVE NET POSITION FROM THE MULTILATERAL CALCULATION IN THE DNS SYSTEM Participant: Participant’s account: Amount of limit for negative net position in EUR: Place and date:

Stamp and signature of authorised person

Share