Operating Rules of the Central Bank of Montenegro Payment System

Pursuant to Article 44 paragraph 2 point 3 of the Central Bank of Montenegro Law (OGM 40/10, 46/10, 06/13) and Article 158 paragraph 3 of the Payment System Law (OGM 62/13), the Central Bank of Montenegro Council, at its meeting held on 10 November 2014, passed the following OPERATING RULES OF THE CENTRAL BANK OF MONTENEGRO PAYMENT SYSTEM
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 standardized 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:

• Real-Time Gross Settlement (hereinafter: the RTGS system) for executing
  individual payment transactions among participants following the real-time gross principle, and
• Deferred Net Settlement (hereinafter: the DNS system) for interbank
  payment transactions following the deferred net principle. The Central Bank shall be the operator and the owner of the payment system referred to in paragraph 1 above. II.RTGS SYSTEM RTGS system participants
  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 headquartered in Montenegro;

4. government authorities, local 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 Depository Agency, 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 Central Bank regulation.
    RTGS system participant account
    Article 4
    The Central Bank shall open and maintain RTGS system settlement accounts 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 accounts in line with the Central Bank regulation governing the opening of transaction accounts. In case of opening a transaction account for a new RTGS system participant, the Central Bank shall notify other participants thereof. Participant connection to the RTGS system
Article 5
In order to participate in the RTGS system, a participant shall submit to the Central Bank the connection request certified with the official seal and signed by the authorized person. The participant’s request for connection to the RTGS system shall be supported with the following:

1. report of the bank 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 forms for reporting persons referred to in paragraph 2 points 2) and 3) above are annexed hereto.

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 is considered to meet the technical requirements and standards for connecting to the RTGS system if it has:

1. ensured the connection to the information and communication system of
   the central and back-up location of the Central Bank;
2. provided necessary components of the ICT system in line with the
   specifications annexed hereto;
3. 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 correctness of the transfer of electronic messages in RTGS system;
4. 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;
5. successfully carried out adequate testing at 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. 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 messages exchange via the RTGS system and it shall submit it to the participant together with the test scenario.
   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. Orders under paragraph 1 above 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 inform 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 are obliged to ensure security and safety measures aimed at providing safe execution of payment transactions in the RTGS system. Obligations referred to in paragraph 1 above 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 of the Central Bank and the corresponding rules 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 above, the information and data may be made available in cases specified by the law and an internal general regulation 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:

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. The participant recipient shall be responsible for verifying the authenticity of the received order.
   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` 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
Transactions mandatorily processed in the RTGS system shall be as follows:

1. payment transactions equal to or exceeding the minimum value of
   payment transactions mandatorily processed in the RTGS system determined by the Central Bank 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 withdraw cash
   from the Vault of the Central Bank.
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 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 hereto that also governs the manner of filling in certain segments of such order.
Article 21
Communication among the RTGS system participants shall be accomplished by exchanging electronic messages for executing payment transactions enclosed hereto. 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 above, 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 other 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 PKI in communication between the Central Bank and the RTGS system participants.
Article 24
The Central Bank shall prescribe herein 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 SWIFT (Society for Worldwide Interbank
   Financial Telecommunication) format, in compliance with the format and the purpose of messages determined herein;
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.

An RTGS system participant shall assume obligations based on the valid message and/or on the basis of its amendment 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.
Article 26
Payment transaction messages with priorities from 10 to 49 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 with priorities 50 to 99, for which execution there is no positive balance in the participant’s account, 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 17:00 hours at the latest, in the form enclosed herewith.
Article 29
For messages for which it has been determined that they are not valid (such as a wrong BIC code of the RTGS system participant, a wrong account, a wrong transfer order date and the like), the RTGS system shall transmit the appropriate message to the participant on rejecting the execution of these messages.
Article 30

Immediately after the execution of a payment transaction, the RTGS system shall transmit a message on the settlement to the participant.
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 with priorities 10 to 49 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 17:00 hours, in the form enclosed herewith.
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 form enclosed herewith. 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 under paragraph 1 above via messages enclosed herewith. Complaints
Article 37
A participant may submit a complaint referring to payment transactions in the RTGS system within three working days following that of the execution of the payment transaction. Complaints shall be submitted to the Department in the form enclosed herewith. RTGS system working days, working hours, operating and processing days
Article 38
A working day, within the meaning of these of Rules, shall be every day except Saturday, Sunday and public holidays declared non-working days, provided that the Central Bank may decide, as required, to declare some of these days working days. The working hours of the RTGS system shall be from 08:30 to 19:00 hours every business day. 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 which shall last from 08:30 to 17:30 hours. 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 unexecuted messages and for processing and archiving messages and which shall last from 17:30 to 19:00 hours. RTGS system work schedule
Article 39
The working schedule of the RTGS system shall be determined by the Daily Work Time Schedule of the RTGS system enclosed herewith.
Article 40
Activation of the RTGS 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 mean as follows:
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 unexecuted messages The “Rejecting unexecuted messages” period shall mean the period of processing day during which the system rejects unexecuted 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 Period during which the RTGS system creates reports on the daily charge of the Central Bank fee. g) Period: Archiving The period of data archiving. 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. Amendments to the Daily Work Time Schedule of the RTGS system
Article 41
The Central Bank shall have the right to amend 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 amend 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 required, amend 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 amended at a participant’s request, the Central Bank shall charge the costs of amending 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 17:00 hours in the form enclosed herewith. 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:

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

In the event of technical problems with the equipment in use, a participant shall notify the Central Bank thereof and 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:

• description of the contingency event;
• estimated time needed to resolve the problem, and
• 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 (helpdesk@cbcg.me), phone (020/665-341) 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 fax 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. 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 inform the Central Bank thereof. The Central Bank shall inform all other participants on the change of data and information under paragraph 1 above. Testing in the RTGS system
Article 50
In addition to tests under Article 7 herein, tests shall be also run in the RTGS system in the following cases:

• regular annual tests of the participants and operators;
• in accordance with the participant and operator needs.
  Regular tests shall be run twice during calendar year at a maximum, in schedules proposed by the Central Bank. In contingency situation, amendments 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.
  Article 51
  If it deems necessary and for the purpose of safe and sound RTGS system functioning, the Central Bank may 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 under paragraph 1 above to a participant pursuant to its written request.
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 office 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 under paragraph 1 points 4) and 5) above are enclosed herewith.
   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 point 2) herein, if it has:

9. provided the components of the ICT system in line with the
   specifications annexed hereto, needed for connecting to the DNS system;

10. provided the training for its employees with the Central Bank for using
    the DNS application software; and

11. successfully carried out adequate testing at the Central Bank’s DNS
    test system
    Article 57
    In order to participate in the DNS system, participants shall submit to the Central Bank the connection request certified with the official seal and signed by the authorized person.
    Article 58
    Prior to connecting to the DNS system and within period that is no longer than 30 days following the day of submitting the request for connecting to the DNS system, a participant shall run test of 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. 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 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 is signed, a participant shall accept operating rules concerning the DNS system applicable in the moment of its connection. Security and safety measures and responsibilities
    Article 60
    Participants in the DNS system are obliged to ensure security and safety measures aimed at providing safe execution of payment transactions in the DNS system.

Obligations referred to in paragraph 1 above 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 familiarised with the security information policy of the Central Bank and corresponding rules and they shall sign memorandum of understanding on accepting such policy.
Article 62
Information and data available to the Central Bank employees within their daily performance of operations concerning the DNS system shall be confidential. By way of derogation from paragraph 1 above, information and data may be made available in cases specified by the law and internal general document of the Central Bank.
Article 63
System administrator for the RTGS 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 the 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 order received by other participant in the DNS system within working hours of the DNS system. Each participant shall be responsible for computer applications and their functional compliance and connectivity with 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.

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
A participant in the DNS system may determine the coverage cap for the negative net multilateral clearing positions in every clearing cycle by allocating reserve funds in the account in the RTGS system. The participant may increase or decrease the cap under paragraph 1 above, depending on its needs, subject to the available balance in the participant’s account in the RTGS system. In the period of preparations for the final clearing cycle, the participant may not reduce the established cap. In case the participant cannot set or change the coverage cap in paragraph 1 above electronically, the information on the setting or changing of the coverage cap shall be submitted to the Department, no later than by 16:10 hours, on the prescribed form enclosed herewith.
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 herein 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 enclosed herewith. 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 the existing SWIFT format, in line with the format
   and the purpose of messages determined under these Rules;
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 rules; and
5. it has been sent and received pursuant to the DNS system Daily Work
   Time Schedule.
   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. wrong BIC code, wrong account, wrong 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
   Sent messages shall be recorded in the DNS system, after which the DNS system shall transmit the message on the confirmation of the acceptance of these messages to the sender.
   Article 75
   If the negative net position exceeds the set limits in the clearing cycles preceding the final clearing cycle, sent messages shall be put in the queue, and once the coverage has been provided, they shall be executed in the next clearing cycle.
   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 77
   A sender may cancel the payment transaction message by 16:00 hours. 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 15:30 hours on the prescribed form enclosed herewith.

Article 78
A participant in the DNS system that has not received a certain message due to technical difficulties may ask the Department to resend the message on the prescribed form enclosed herewith. The manner of payment transaction execution in the DNS system
Article 79
After the expiry of the time envisaged for the acceptance of messages set by the DNS system Daily Work Time Schedule for every clearing cycle, multilateral net position of every DNS system participant shall be established. A participant’s multilateral net position is a sum of values of all payment transactions that the participant has received in the DNS system within a certain period of time minus the sum of payment transactions the participant has transmitted to other participants within the same period. If this value is positive so shall be the participant’s multilateral net position and if this value is negative so shall be the participant’s multilateral net position.
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;
2. individual messages for executed payment transactions sent to the
   respective participant by other participants.
   The Central Bank shall submit the report and messages under paragraph 1 above via messages enclosed herewith. 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 enclosed herewith. DNS system working days, working hours, operating and processing days
   Article 86
   Working days, within the meaning of these of Rules, shall be every working day except Saturday, Sunday and public holidays declared non-working days, provided that the Central Bank may decide, as required, to declare some of these days working days. The working hours of the DNS system shall be from 08:30 to 19:00 hours every working day. The working hours of the DNS system shall be divided into an operating day 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 16:30 hours. 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 unexecuted messages and

for processing and filing messages and which shall last from 16:30 to 19:00 hours. DNS system working hours schedule
Article 87
DNS system working hours schedule shall be determined by the Daily Work Time
Schedule of the DNS system enclosed herewith.
Article 88
Activation of the DNS system shall start with the Beginning of Day period and it shall end with activation of the End of Day period. Periods established by the Daily Work Time Schedule of the DNS system have the following meanings:
a) Period: Beginning of Day
The initiation of the “Beginning of Day” period starts the DNS system. b) Period: Exchange of payment transaction messages for the first cycle After activating the “Exchange of payment transaction messages for the first cycle” period, the DNS 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: Exchange of payment transaction messages for the second cycle After activating the “Exchange of payment transaction messages for the second cycle” period, the system is available to participants for sending payment transaction messages and other messages. e) 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. f) Period: Exchange of payment transaction messages for the third cycle

After activating the “Exchange of payment transaction messages for the third cycle” period, the system is available to the participants for sending payment transaction messages and other messages. g) Period: Preparation for the third cycle The “Preparation for the third cycle” period is a period during which the system notifies participants in the clearing on their net position form the multilateral calculation in clearing. h) 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. i) Period: Stop clearing The “Stop clearing” period means the ending of payment transaction messages sending to the DNS system for that day. j) Period: Rejecting unexecuted messages The “Rejecting unexecuted messages” period is a part of the processing day during which the system rejects unexecuted payment transactions. k) 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. l) Period: Archiving Data archiving period. m) Period: End of Day The “End of Day” period means the end of the DNS system operations and end of the working day. Changes of 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 the event of emergency and contingency situations and it shall inform all participants of the DNS system thereof. The Central Bank may change the Daily Work Time Schedule of the DNS system due to the following reasons:

1. a necessary technical and application intervention in order to resolve
   problems that substantially affect the functionality and/or safety of the DNS system;

2. other reasons that may affect the soundness 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 third cycle” period. The participant shall submit the Request for extending the operations of the DNS system to the Department no later than until 15:30 hours, in the form enclosed herewith. The Daily Work Time Schedule of the DNS system may be extended at a user’s request for no more than 30 minutes. Exceptionally, if the Central Bank has assessed that the Daily Work Time
   Schedule of the DNS system requires the extension exceeding 30 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. Governing provisions
   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:

3. Annex 1 – Daily Work Time Schedule of the RTGS system and Daily
   Work Time Schedule of the DNS system;

4. Annex 2 – Core elements of the transfer order and the manner of their
   completing;

5. Annex 3 – Messages in SWIFT format;

6. Annex 4 – Form for reporting authorised contact persons with the
   Central Bank of Montenegro for the payment transaction execution in the RTGS system and Form for reporting authorised contact persons with the Central Bank for the payment transaction execution in the DNS system

7. Annex 5 – Form for reporting person authorised for security and safety
   of communication with the RTGS and the DNS system;

8. Annex 6 – Specification of ICT system components on the
   participants’ side necessary for connecting to the RTGS system;

9. Annex 7 – Form for requesting the change of message priority in the
   RTGS system;

10. Annex 8 – Form for requesting cancelation of payment transaction
    messages in the RTGS system and Form for requesting cancelation of payment transaction messages in the DNS system;

11. Annex 9 – Request form for determining or changing the limit for
    negative net position from the multilateral calculation in the DNS system,

12. Annex 10 – Request form for resending messages from the RTGS
    system and Request form for resending messages from the DNS system,

13. Annex 11 – Complaint form for payment transactions executed in the
    RTGS system and Complaint form for payment transactions executed in the DNS system;

14. Annex 12 – Request form for extending operations of the RTGS
    system and Request form for extending operations of 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.
    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 harmonized with these Rules within 60 days following that of their application.

Article 95
Payment System Rules for Interbank Payment Transfers (OGM 24/09) shall be repealed from with effect from the date of entry into force of these rules.
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 9 January 2015. THE COUNCIL OF THE CENTRAL BANK OF MONTENEGRO CHAIRMAN G O V E R N O R, Decision number: 0101-4014/63-14 Podgorica, 10 November 2014 Milojica Dakić, m.p.

ANNEX 1
DAILY WORK TIME SCHEDULE OF THE RTGS SYSTEM Beginning of Day 08.30-09.00 Exchange of payment transaction messages Stop RTGS system 09.00-17.30 17.30-17.31 Rejecting unexecuted messages 17.31-17.35 Creating reports on executed payment transactions Creating reports on the daily charge of the Central Bank fee 17.35-18.00 17.35-18.00 Archiving 18.00-19.00 End of Day 19.00 DAILY WORK TIME SCHEDULE OF THE DNS SYSTEM Beginning of Day 08.30-09.00 Exchange of payment transaction messages for the first cycle 09.00-11.00 Clearing (the first cycle) 11.00-11.30 Exchange of payment transaction messages for the second cycle 11.30-13.30 Clearing (the second cycle) 13.30-14.00 Exchange of payment transaction messages for the third cycle 14.00-16.00 Preparation for the third cycle 16.00-16.15 Clearing (the third cycle) 16.15-16.30 Stop clearing 16.30-17.30 Rejecting unexecuted messages Creating reports in the RTGS system on net position in the DNS system 17.31-17.35 17.35-18.00 Archiving 18.00-19.00 End of Day 19.00

ANNEX 2
CORE ELEMENTS OF TRANSFER ORDERS AND THE MANNER OF COMPLETING CORE ELEMENTS OF TRANSFER ORDERS INTO CORRESPONDING ELELCTRONIC 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:
N o
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, and/or name, last name and the address of 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 accounts 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, and/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. Purpose of
payment
Purpose, i.e. the basis for payment
335x 335x – alphabet, numerical and alphanumerical characters Completed for all purposes
7. Payment
code
Numeric data
3n
Completed if needed
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. 2n Completed if needed

Number of module 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.
9. Debit
reference number
Data in accordance with regulations or if needed for the purpose of obtaining additional information on payment transaction. Number of module 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 . Model (model of credit reference number) Control number of the reference number calculated according to module 97. Writing in of the control number is not prerequisite for the order execution, but if it is entered it must correspond to the prescribed module. Number of module 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 . Credit reference number Data in accordance with regulations or if needed for the purpose of obtaining additional information on payment transaction. Number of module 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 . Execution date Date when the order should be executed DDMMYY Numeric data

ANNEX 3
MESSAGES IN SWIFT 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) 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 950 Statement Message contains information on payment transactions executed in the RTGS system 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 973 Netting Request Message is used as the request for sending reports on payment transaction 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 Changes, 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, unexecuted messages MT 103 or MT 102 MT 292 Request for Cancellation is used for previously sent and, until the moment, unexecuted message MT 202 MT 195 Queries to Transfer of previously sent message MT 103 or MT 102 MT 295 Queries to Transfer of previously sent message MT 202 MT 196 Reports to 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

1. Message structure
   1.1. 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:
   Participant  RTGS system
   Number of segment
   Name of field Participant  RTGS system 1: Sender HBBAMEPGXXX Hipotekarna banka AD Podgorica 2: Type of message 103 2: Recipient CBCGMEPGXXXX RTGS - system Podgorica RTGS system  Participant Number of segment Name of field RTGS system  participant 1: Sender CBCGMEPGXXXX RTGS - system Podgorica 2: Type of message 103 2: Recipient HBBAMEPGXXX Hipotekarna banka AD Podgorica
   1.2. Characters defining message format:
   Structure of SWIFT segments:

Type of character
Description Examples n Numeric field 18n – field of 18 integers ! Placed behind a number, it means fixed length determined by the number 18!n – field of fixed 18 integers

a Only letters (capital letters) 4!a – fixed four letters d Decimal field 15d – integer with two decimals up to 15 characters (12n,nn) x Letter, integer or sign character 35x – means up to 35 letters, integers sign characters c Letter numeric character 3c – field having 3 letters, 3 integers or 3 letter and numeric characters 335x First number determines the number of lines, while the latter determines number of characters per line 335x – 3 lines each containing maximum 35 characters [ ] Fields in square brackets are optional [1!a] – in specific conditions, the field has a fixed one character, while it is not completed in other conditions  ----I Fields between these two signs can be repeated several times Characters allowed in the SWIFT are:
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 0123456789 / - ? : ( ) . , + { }
1.3. Priority
Field: 113: it is placed in the third segment and it determines the payment transaction 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. 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.

1.5. Table of messages used in the RTGS and DNS systems
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 973 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 950 MT 192 MT 196 MT 195 MT 196 MT 292 MT 296 MT 295 MT 296 MT 999 MT 999 MT 991
2. Core messages according to SWIFT standard
2.1. Message MT 102 – Group payment orders 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 must 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. The message contains the following elements:
  Field Elements of payment transaction order Format Compulsory 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 reference 16x Yes TRN in SWIFT 23 CREDIT 6!a Yes CREDIT 26T Payment transaction code type 3!c It means the value 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

Account of payer to be debited (3n-13n￾2n) 50K Name of payer:

• Name (of legal person or entrepreneur;
  natural person)
• address
• place
  /18!n
  3*35x
  Yes Example:
  :50K:/580000000000123475
  PAYER OF PARTICIPANT A
  Ul.Slobode br.2
  PODGORICA
  Account of recipient to be credited (3n￾13n-2n) Name of recipient:
• Name (of legal person or entrepreneur;
  natural person)
• address
• place
  /18!n
  3*35x
  Yes Example:
  :59:/570000000000873444
  RECEPIENT OF PARTICIPANT
  B
  Ul. Balšićeva br.5
  BUDVA
  70 Information on remitting of funds:
• Payment code
• Field code PBZ followed by model of
  debit reference and debit references 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
  32A - Execution date (YYMMDD),
• Currency code (EUR for euros) and
• amount – sum of all transactions
  (12n,nn)
  6!n3!a15d
  Yes Example (for 10 orders of EUR
  20.00 each):
  :32A:0907029EUR200,00
  Participant which account is debited:
  /D/ Participant’s account
  53A
  Participant’s BIC
  /D/18!n
  4!a2!a2!c[3!c]
  Yes Example:
  :53A:/D/907000000005800138
  CKBCMEPG
  Participant which account is credited:
  /C/ Participant’s account
  54A
  Participant’s BIC
  /C/18!n
  4!a2!a2!c[3!c]
  Yes Example:
  :54A:/C/907000000005700131
  PDBPMEPG
  72 Information from sender to recipient with the transaction code First, the code CODTYPTR/001 or BNF is entered, and each other line has to begin with two slashes (//) 6*36 CODTYPRT/001

2. Message MT 103 – Transfer of funds for the account of a beneficiary
   being an RTGS system participant
   Message MT 103 enables transfer of funds for the account of a beneficiary being an RTGS system participant. The message contains the following elements:

Field Elements of transfer order Format Compulsory 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 TRN in SWIFT 23B CRED 4!c yes CRED 23E SDVA 4!c yes SDVA 26T Transaction code type 3!c Default value is 001 32A Execution date (YYMMDD), Currency code (EUR) and Amount (12n,nn) 6!n3!a15d yes Example:
:32A:090123EUR453,69
Account of payer to be debited (3n-13n￾2n) 50K Name of payer to be debited:

• Name (of legal person or entrepreneur;
  natural person)
• address
• place
  /18!n
  3*35x yes Example:
  :50K:/580000000000123475
  PAYER OF BENEFICIARY A
  Ul.Slobode br.23
  PODGORICA
  Participant which account is debited:
  /D/ Participant’s account
  53A
  Participant’s BIC
  /D/18!n
  4!a2!a2!c[3!c] yes Example:
  :53A:/D/907000000005800138
  CKBCMEPG
  Participant which account is credited:
  /C/ Participant’s account
  57A
  Participant’s BIC
  /C/18!n
  4!a2!a2!c[3!c] yes Example:
  :57A:/C/907000000005700131
  PDBPMEPG
  Account of recipient of payment to be credited (3n-13n-2n) Name of recipient of payment to be credited:
• Name (of legal person or entrepreneur;
  natural person)
• address
• place
  /18!n
  3*35x yes Example:
  :59:/570000000000873444
  RECIPIENT OF PAYMENT OF
  BENEFICIARY B
  Ul.Balšićeva br.8
  PODGORICA
  70 Information on funds remitting:
• Payment code (SIF- 3n)
• 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
  First, the code CODTYPTR/001 or BNF is entered, and each other line has to be started with two slashes (//) 335x 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)

• 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 4*35x TC-18!n SIF-3n PBZ-2n-20x PBO-2n-20x yes Example of proposed format:
  :70:/ TC/805000000000095502
  SIF-132
  PBZ-05-02731266
  PBO-05-35092-09-001-4000247
  2.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 message contains the following elements:
  Field Elements of payment transaction order Format Compulsory 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 4n yes Example:
  113:0099
  20 Message reference 16x yes TRN in SWIFT 21 Connecting 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
  Participant which account is debited:
  /D/ Participant’s account
  53A
  Participant’s BIC
  /D/18!n
  4!a2!a2!c[3!c] yes Example:
  :53A:/D/907000000005800138
  CKBCMEPG
  Participant which account is credited:
  /C/ Participant’s account
  58A
  Participant’s BIC
  /C/18!n
  4!a2!a2!c[3!c] yes Example:
  :58A:/C/907000000005700131
  PDBPMEPG
  72 First, enter code CODTYPTR/001 or BNF Information on remitted funds:

• Payment transaction type code

• Payment code (SIF- 3n)

• Field code PBZ followed by model of
  debiting reference and debiting reference separated by hyphens

• Field code PBO followed by model of
  5*35x
  (001)
  SIF-3n
  PBZ-2n20x yes
  Example of proposed format:
  :72:/CODTYPRT/001
  //SIF-383
  //PBZ-00

• Payment purpose
  (lines 2-5 have to be started with two slashes (//)) PBO-2n20x 35x //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 remitted funds:

• Payment transaction type code

• Payment code (SIF- 3n)

• 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 remitted funds:

• Payment transaction type code
• Payment code (SIF- 3n)
• 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 (003) SIF-3n PBZ-2n20x PBO-2n20x 35x da Example of proposed format:
  :72:/CODTYPTR/003
  //SIF-383
  //PBZ-00
  /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.

3. Category 9 – Confirmation on receipt, account status and reports
   3.1. Message MT 900 – Confirmation of Debit
   Message MT 900 is used as a confirmation of debit of account after the executed payment transaction (MT 103 or MT 202). The RTGS system sends the message to participant. The message contains the following elements:
   Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 21 Connected reference 16x yes TRN of message to which confirmation refers to 25: Account number 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 635
   3.2. Message MT 910 – Confirmation of Credit
   Message MT 910 is used as a confirmation of account credit after the execution of payment transaction (MT103 or MT 202). The RTGS system sends the message to the participant which account is credited. The message contains the following elements:
   Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 21 Connecting 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
   FFBMMEPG
   72 Information from sender to recipient 635

3.3. Message MT 920 – Requests for information on account balances and
for the delivery of report
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 message contains the following elements:
Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT  yes 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,942 or 950 25 Number of account to which the message refers 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[1!a]15d Example:
  :34F:EURC10,
  ------I
  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.
  3.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:
  Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 25 Account number of participant 18!n yes Number of account which report is sent 28C Number of reports / page number of report 5n[/3n] yes 60F Opening balance in the form:

• debit/credit - D/C

• date - YYMMDD 1!a6!n3!a15d
  yes Example:
  :60F:C090628EUR1000,

• currency code – EUR

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

• number of account that caused the
  change
  6!n
  2a
  15d
  1!a3!c
  16x
  [//16x]
  18!n
  86 - first row – account of payer to be debited (code MT 103-field 50K and code MT 202 field 53A)

• second row – account of recipient to be
  credited (code MT 103-field 59 and code MT 202 field 58A)

• next four lines of report are field 70 of
  message MT103.
  6*35x
  ------I
  62F Closing balance:

• debit / credit - D/C

• execution date - YYMMDD

• currency code - EUR

• amount – (12n,nn)
  1!a6!n3!n15d yes
  Example:
  :62F:C091010EUR1000,
  3.5. Message MT 941 – Current balance at the account
  Message MT 941 is used for sending information on balance at the specific moment, as respond to MT 920. The message contains the following elements:
  Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 21 Connecting reference 16x yes Reference of message МТ 920 – TRN, with which this message was initiated 25 Account number 18!n yes Number of account to which the message refers 28 Balance number/Message sequence 5n[/2n] yes 60F Opening balance in the form:

• debit/credit - D/C,

• date – YYMMDD,

• currency code - EUR,

• amount (12n,nn).
  1!a6!n3!a15d yes Example:
  :60F:C090628EUR595771,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

62F
Closing balance for date in the form:

• debit / credit (D/C)
• date - YYMMDD,
• currency code – EUR
• amount (12n,nn)
  1!a6!n3!n15d yes Example:
  :62F:C091111EUR659851,00
  64 Available balances in the form:
• debit / credit (D/C)
• execution date - YYMMDD,
• currency code – EUR
• amount (12n,nn)
  1!a6!n3!a15d
  Example (in case 179.226,00
  EUR has been reserved for clearing) :
  :64:C091111EUR480625,00
  3.6. Message MT 942 –Interim report on executed payment transactions of
  the participant
  Message MT 942 contains data on payment transactions from previously taken interim or daily report, as a response to request МТ 920. The message contains the following elements:
  Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 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 the message refers 28C Number of reports / page number of report 5n[/3n] 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 yes Example:
  :34F:EURC10,00
  13D Date and time of sending
  YYMMDDHHMM+0100
  6!n4!n1!4!n yes Example:
  0908261050+0100
  

Report line:

• execution date – YYMMDD,
• debit (D), credit (C), expected debit (ED),
  expected credit (EC)
• amount,
• code for identifying payment transaction
  type,
• reference to account owner,
• reference institution servicing the account
• account number
  6!n
  2a
  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
  6*65

message MT103.
------I

90D

• Number of debit payment transactions
• currency code - EUR
• amount (12n,nn)
  5n3!a15d
  Example:
  :90D:2EUR2000,00
  90C - Number of credit payment transactions
• currency code - EUR
• amount (12n,nn)
  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.
  3.7. Message MT 950 – Report on executed payment transactions
  Message MT 950 is the report on executed payment transactions at the end of the working day, according to participant’s choice. The message contains the following elements:
  Field Elements of transfer order Format Compulsory 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 Number of reports / page number of report 5n[/3n] yes 60F Opening balance in the form:
• debit/credit - D/C
• execution date - YYMMDD
• currency code – EUR
• amount – (12n,nn)
  1!a6!n3!a15d yes Example:
  :60F:C090628EUR1000,00
  
  61 Report line:
• execution date – YYMMDD,
• debit (D), credit (C) ….,
• amount,
• code for identifying payment transaction
  type,
• reference to account owner,
• reference institution servicing the account
• account number
  6!n
  2a
  15d
  1!a3!c
  16x
  [//16x]
  18!n
  ------I
  62F Closing balance with the date of sending:
• debit / credit - D/C
• date - YYMMDD,
• currency code – EUR
• amount (12n,nn)
  1!a6!n3!n15d yes
  Example:
  :62F:C090628EUR18910,00

3.8. 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 Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 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[/3n] yes 60F Opening balance in the form:

• debit/credit - D/C
• date - YYMMDD
• currency code – EUR
• amount – (12n,nn)
  1!a6!n3!a15d yes Example:
  :60F:C090126EUR0,
  
  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
  2a
  15d
  1!a3!c
  16x
  [//16x]
  4!a2!a2!c[3!c]
  :61:090126D53,30S102890
  560000003832c//24416664
  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!a15d yes
  Example:
  :62F:C090126EUR1592,76
  3.9. Message MT 973 – Request for sending reports from the DNS system
  Message MT 973 is used as a request for sending reports on payment transactions executed in the DNS system. The message contains the following elements:
  Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT  yes 12 Type of message to be requested 3!n yes Number of adequate message MT970 or MT972

25 Number of account to which the message refers 18!n yes -----I
3.10. 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 message contains the following elements:
Field Elements of transfer order Format Compulsory Note 20 Message reference 16x yes TRN in SWIFT 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 BIC of the participant /18!n 4!a2!a2!c[3!c] yes Field “Account to which the query refers” (/18!n) is not compulsory for following queries: PCLT, TTLS i TTLD Example:
:59:ATLMMEP2
Description of formats depending on request:
yes Type of query:
4!a STAT – account status
4!a SQDC – report on waiting order
4!a PCLT – set clearing limit
75 Queries
4!a
[6!n/]16x

• TTLS – clearing session totals in
  DNS system
• YYMMDD, slash followed by
  session (e.g. MORNING,
  EVENING or FINAL)
  3.11. Message MT 986 – Status Report
  Message MT 986 is used to respond to a participant’s enquiry set in message MT 985. Responses supported by the RTGS system are given in field 79. The message contains the following elements:
  Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 21 Message reference to which the response refers 16x yes Account of the participant to which the query refers Participant’s BIC /18!n 4!a2!a2!c[3!c] yes Example:
  :59:PDBPMEPG
  79 Response yes

Possible responses to STAT query: 4!a[/6!n4!n1!x4!n] 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
  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!x4!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
• date, value, set limit
• date, value, value of field is 0
• date, value, net balance
  position in current session
• current session
  4!a[/6!n4!n1!x4!n]
  /18!n
  6!n3!a15d
  6!n3!a15d
  1!a6!n3!a15d
  PCLT/0901260901+0000
  /907000000005800138
  090126EUR150000,
  090126EUR0,
  C090126EUR0,
  MORNING
  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!x4!n] 5d/5d/5d 17d/5d/5d 6!n16x TTLS/

4. Category n – Common Group Messages

4.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 message contains the following elements:
Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 21 Connected reference 16x yes NONREF 32B Currency code (EUR) Amount (12n,nn) 3!a15d yes Example:
:32B:EUR6,76
52A Account of participant to be debited Participant’s BIC [/1!a][/18!n] 4!a2!a2!c[3!c] yes Example:
:52A:PDBPMEPG
57A Account of the Central Bank of Montenegro to which the fee is paid Central Bank of Montenegro’s BIC [/1!a][/18!n] 4!a2!a2!c[3!c] yes Example:
:57A:CBCGMEPG
71B Details on debiting 635 yes
72 Information from sender to recipient 635 :72:/INT/

4.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 message contains the following elements:
Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 21 Connected reference 16x yes TRN of message to which the request refers MT number Date - YYMMDD 11S Number of series and the sequence of original message 3!n 6!n [4!n6!n] yes Example:
11S:103
090104
4444666666
BIC of the participant who sent the message Execution date - YYMMDD 4!a2!a2!c[3!c] 6!n yes Example:
:79: PDBPMEPG
090104

4.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 message contains the following elements:
Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 21 Connected reference 16x yes TRN of message to which the request refers Possible queries:
STAT - Message status
PRTY – priority change
75 Queries
4!a yes
DUPL – Message duplicate
77A The field is used only when changing the priority (if the field :75: contains code PRTY) 4!c The field is compulsory only for query PRTY, Example:
77A:0020
MT number
Date - YYMMDD
11S
Number of series and the sequence of original message 3!n 6!n [4!n6!n] Example:
:11S:103
090104
4444666666
BIC of the participant that sent the message Execution date 4!a2!a2!c[3!c] 6!n Example:
:79: PDBPMEPG
090104
4.4. Message MT n96 – Response to requests and queries
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 message MT 196 informs the participant on:

• previously sent message MT102,
• impossibility to execute MT103,
  while message MT 296 informs on the impossibility to execute message MT 202. The message contains the following elements:
  Field Elements of transfer order
  Format Compulsory Note

Sender yes
Recipient yes
20 Message reference 16x yes TRN in SWIFT 21 Connected 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] 4c[/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) 3*35x yes If the response contains error write the code in the first line, and the description of error in the last two lines MT number – message number Date - YYMMDD 11R Number of series and the sequence of original message 3!n 6!n [4!n6!n] yes Example:
:11R:202
090628
4444666666
Copy containing at least all compulsory fields of original message Field 76 of Status Report (STAT) may contain the following responses:
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 ERRC There was an error in processing message STAT WAIT The message is in the queue STAT SUSP The message is suspended STAT ERRP There was an error STAT NETR Message has been accepted for clearing. The participant may recall it. STAT NETS The message is settled before the clearing procedure. The recall is not possible. 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
DUPL
ERRC
Error in payment transaction copying
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.
4.5. Message MT n99 – Free Format Message
Message MT 999 is a free format message.
The message contains the following elements:
Field Elements of transfer order Format Compulsory Note Sender yes Recipient yes 20 Message reference 16x yes TRN in SWIFT 21 Connecting reference 16x 79 Message text: 3550x yes /TEXTMESSAGE/BIC /11!c/4!a2!a2!c[3!c] 3450x Example:
/TEXTMESSAGE/ PDBPMEPG
Change of user’s status:
/SETUSERLOCK/ code of user which status is being changed /DIRECTION/ /STATUS/ status to be assigned /11!c/12x 2*50 Example:
:79:/SETUSERLOCK/LLLLLL
/DIRECTION/
/STATUS/00

Setting the account limit:
/SETACCOUNTLIMIT/CLEARING
/STATUS/
/ACTION/
/DIRECTION/I (for limit increase) or
D (for limit decrease)
/ACCOUNT/ account number
/AMOUNT/ amount – new limit
15/!c/16x
5*50
Example:
/SETACCOUNTLIMIT/CLEARIN
G
/STATUS/
/ACTION/
/DIRECTION/I
/ACCOUNT/
907000000005050134
/AMOUNT/ 1000,00
Request for report on the business day period:
/GETBUSINESSDAYPERIOD/
/20!C/

ANNEX 4

---

Participant’s stamp
FORM FOR REPORTING
AUTHORISED CONTACT PERSONS 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:________________________________________
   Phone and fax number: _______________________________ E-mail address: _____________________________ Contact person’s signature ______________________
2. First name and surname:________________________________________
   Phone and fax number: _______________________________ E-mail address: _____________________________ Contact person’s signature ______________________ Place and date: __________________________

---

Stamp and signature of authorised person

---

Participant’s stamp
FORM FOR REPORTING
AUTHORISED CONTACT PERSONS WITH THE CENTRAL BANK OF MONTENEGRO FOR PAYMENT TRANSACTIONS 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:________________________________________
   Phone and fax number: _______________________________ E-mail address: _____________________________ Contact person’s signature ______________________
2. First name and surname:________________________________________
   Phone and fax number: _______________________________ E-mail address: _____________________________ Contact person’s signature ______________________ Place and date: __________________________ _____________________ Stamp and signature of authorised person

ANNEX 5

---

Participant’s stamp
FORM FOR REPORTING
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 CRBE) 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: _________________________________________ Phone and fax number: _______________________________ E-mail address: _____________________________ Contact person’s signature ______________________ Place and date: __________________________

---

Stamp and signature of authorised person

ANNEX 6
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. Operational system (OS) containing the following characteristics as a
   minimum:
    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.

ANNEX 7

---

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: (MT202, MT103) Existing message priority:
Requested message priority:
Message reference / field 20:
Amount of payment transaction:

Place and date:

---

Stamp and signature of authorised person

---

ANNEX 8

---

Participant’s stamp
REQUEST FOR CANCELLING PAYMENT TRANSACTION MESSAGES IN THE RTGS SYSTEM Participant:
Participant’s account:
Type of messages which cancellation is requested:
(MT103, MT202)
Message reference/field 20:
Amount of payment transaction:

Place and date:

---

Stamp and signature of authorised person

---

---

Participant’s stamp
REQUEST FOR CANCELLING PAYMENT TRANSACITON MESSAGES IN THE DNS SYSTEM Participant:
Participant’s account:
Type of messages which cancellation is requested:
(MT102)
Message reference/field 20:
Amount of payment transaction:
Place and date:

---

Stamp and signature of authorised person

---

ANNEX 9

---

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

---

ANNEX 10

---

Participant’s stamp
REQUEST
FOR RESENDING MESSAGES FROM THE RTGS SYSTEM Participant:
Participant’s account:
Type of messages to be resent:
Message reference / field 20:
Amount of payment transaction:
Place and date:

---

Stamp and signature of authorised person

---

---

Participant’s stamp
REQUEST
FOR RESENDING MESSAGES FROM THE DNS SYSTEM Participant:
Participant’s account:
Type of messages to be resent:
Message reference / field 20:
Amount of payment transaction:
Place and date:

---

Stamp and signature of authorised person

---

ANNEX 11

---

Participant’s stamp
COMPLAINT FORM FOR PAYMENT TRANSACTIONS EXECUTED IN THE RTGS SYSTEM Participant:
Participant’s account:
Subject of complaint:

List of enclosed documents:
SWIFT format 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

---

---

Participant’s stamp
COMPLAINT FORM FOR PAYMENT TRANSACTIONS EXECUTED IN THE DNS SYSTEM Participant:
Participant’s account:
Subject of complaint:

List of enclosed documents:
SWIFT format 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

---

ANNEX 12

REQUEST FOR EXTENDING OPERATIONS OF THE RTGS SYSTEM Participant:
Participant’s account:
Reason for extending the operation:
Time of extension of operations in minutes:
Place and date:

---

Stamp and signature of authorised person

---

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

---