Operating Rules of the Central Bank of Montenegro Payment System

[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:

the Central Bank;
banks and other credit institutions;
branches of third-country credit institutions having their head offices in Montenegro.
government authorities, local self-government authorities, legal persons whose obligations are
subject to statutory guarantee by Montenegro, and legal persons exercising public authority;
the European Central Bank and third-country central banks;
international financial institutions;
the Deposit Protection Fund;
donor organisations;
the Central Securities Depository and Clearing Company of Montenegro, subject to the opening of
a cash pool account;
settlement agents;
clearing organisations;
payment system operators, and
other legal persons, in line with the law and regulation of the Central Bank.

report of the identification code (BIC code) which they will use in the RTGS system; and
report of the authorised persons to contact Central Bank regarding the payment transaction
execution in the RTGS system, and
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:
ensured the connection to the information and communication system of the central, back-up and
disaster location of the Central Bank;
provided necessary components of the ICT system in line with the specifications provided in Annex
to these Rules;
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;
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;
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 email).
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:

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;
exchange of digital certificates with the Central Bank;
providing the Central Bank with a written report on the application of safety and other measures, at
the Central Bank`s request;
maintaining information and communication infrastructure of the participant in the RTGS system,
and
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:

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;
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;
payment transactions through which the participants place and withdraw cash from the Vault of the
Central Bank, and
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.

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;
it has been sent and received pursuant to the RTGS system rules; and
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.

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.

if the participant has failed to act pursuant to these rules;
if the participant does not act according to the contract on connecting to the RTGS system
concluded with the Central Bank; and
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:

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;
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;
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.

the Central Bank;
banks and other credit institutions; and
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:
participate in the RTGS system;
meet technical requirements and standards for the connection to the DNS system;
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;
report to the Central Bank the authorised contact persons for the payment transaction’s execution
in the DNS system; and
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:
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;
provided the training for its employees with the Central Bank for using the DNS application
software;
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:

it has been sent by a participant in the DNS system;
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.

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;
Annex 2 – Specification of ICT system components on the participants’ side necessary for
connecting to the RTGS system;
Annex 3 – Core elements of transfer orders and the manner of completing core elements of transfer
orders into corresponding electronic messages
Annex 4 – Messages in MX and MT format:
Annex 5 – Request for the change of message priority in the RTGS system;
Annex 6 – Requests for the cancelation of payment transaction messages in the RTGS and DNS
systems;
Annex 7 – Requests for resending messages from the RTGS and DNS systems;
Annex 8 – Complaints regarding payment transactions executed in the RTGS and DNS systems;
Annex 9 – Daily Work Time Schedule of the RTGS and DNS system;
Annex 10 – Requests for the extension of operating hours of the RTGS and DNS systems;
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.

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

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

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

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.

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

Computer and communication device:

L3 device (router/firewall/switch), with a possibility to install L2L VPN tunnel.

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.

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) 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, nonexecuted messages MT 103 or MT 102 MT 292 Request for Cancellation is used for previously sent and, until the moment, nonexecuted 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:

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-2n20x PBO-2n20x 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

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-13n2n) / 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

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-2n20x PBO-2n20x 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

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-2n20x 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

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

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

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

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 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
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

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

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,

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

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

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

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

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

Operating Rules of the Central Bank of Montenegro Payment System

Lineage: In force

Similar documents from other regulators