Region

Jurisdiction

Regulator

2020-01-01

Rules Amending Operating Rules of the Central Bank of Montenegro Payment System

The Council of the Central Bank of Montenegro issued rules amending the Operating Rules of its Payment System to update terminology, contact details, and technical standards. The amendments introduce ISO 20022 MX message formats, establish gridlock resolution procedures, and define clearing limits for the DNS system. Additionally, the rules mandate regular Business Continuity Plan testing and specify the annexes governing system operations.

Montenegro

Central Bank of Montenegro

Unofficial translation Pursuant to Article 44 paragraph (2) item 3) of the Central Bank of Montenegro Law (OGM 40/10, 6/13, 70/17, 125/23) and Article 158 paragraph (3) of the Payment System Law (OGM 62/13, 111/22, 15/25), the Council of the Central Bank of Montenegro, at its meeting held on 15 May 2025, passed the following RULES AMENDING OPERATING RULES OF THE CENTRAL BANK OF MONTENEGRO PAYMENT SYSTEM Article 1 In Operating Rules of the Central Bank of Montenegro Payment System (OGM 48/14, 57/14), in Article 3 item 9), the wording: “the Central Depository Agency” shall be replaced by the following: “Central Securities Depository and Clearing Company of Montenegro”. Article 2 In Article 6 paragraph (2) item 1) the words: “the central and back-up location” shall be replaced by the following: “the central, back-up and disaster location”. In item 3) the wording: “correctness of the transfer” shall be replaced by the word “integrity”. Article 3 In Article 11 after the word “policy” the following shall be added: “and rules”, while the words: “and the corresponding rules” shall be deleted. Article 4 In Article 17 the words “accounts opened” shall be replaced by the following: “settlement accounts”. Article 5 In Article 18 paragraph (1) item 3), after the word “participants” the following shall be added: “place and”. Article 6

In Article 24 paragraph (2) item 1) the words: “the existing SWIFT (Society for Worldwide Interbank Financial Telecommunication) format” shall be replaced by the following: “MX format, according to ISO 20022 Standard”. After paragraph (2) a new paragraph shall be added, worded as follows: “Notwithstanding paragraph (2) item 1) of this Article, the message shall be considered valid even if it is created in the SWIFT (Society for Worldwide Interbank Financial Telecommunication) format in accordance with these rules, using the functionality of the RTGS system that enables the conversion of the MT format into the MX format.”. Current paragraph (3) shall become paragraph (4). Article 7 In Article 25 paragraph (1) the full stop at the end of the text shall be replaced by a comma and the following shall be added: “in such a way that priority codes from 10 to 19 are considered high priority, from 20 to 49 medium priority, and from 50 to 99 low priority.”. Article 8 In Article 26 the words: “from 10 to 49” shall be replaced by the following: “from 10 to 99”. Article 9 In Article 27 the words: “with priorities 50 to 99” shall be deleted, and after the word "participants", the following shall be added: “by the end of the operational day”. Article 10 In Article 30 the words: “a message” shall be replaced by the following: “appropriate messages”. Article 11 In Article 32 the words: “with priorities 10 to 49” shall be deleted. Article 12 In Article 43 paragraph (4) the words: “e-mail-a (helpdesk@cbcg.me), phone (020/665-341)” shall be replaced by the following: “e-mail-a (servicedesk@cbcg.me), phone (020/403-148)”. Article 13 In Article 44 paragraph (4), the words “via fax” shall be replaced with the following: “via email”.

Article 14 In Article 50 paragraph (1) indent 1 the words: “regular annual tests” shall be replaced by the following: “of regular annual tests”. After indent 2 a new indent shall be added, worded as follows: “- of regular annual tests of the Business Continuity Plan of the Central Bank,”. Current indent 2 shall become indent 3. In paragraph (3) a new paragraph shall be added, worded as follows: “Within 30 days following the date of completion of the testing, the Central Bank shall submit to all participants a report on the key results of the testing, including relevant conclusions and suggestions for improving the security and reliability of the RTGS system.” Article 15 After Article 53, a new subheading and a new article shall be added, worded as follows: “Management of Operational and Financial Risk in the RTGS System” Article 53a A participant in the RTGS system shall be responsible for ensuring sufficient funds in the settlement account, or for reserving funds in that account, for the purpose of settling monetary obligations arising in the DNS system. A participant in the RTGS system may, through a request or independently, via the User Portal, monitor the status of its positions and payment messages during the business day. In the event of a delay in the settlement of payment transactions that are in the gridlock involving two or more participants, the Payment System Operator may activate one of the following systemic procedures to resolve the situation:

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

In Article 61, after the word “policy” the following shall be added: “and rules”, while the words: “and the corresponding rules” shall be deleted. Article 17 Article 67 shall be amended to read: “For the purpose of submitting orders and participating in the DNS system, the participant shall be required to define a clearing limit by reserving funds on its account in the RTGS system. The participant may increase or decrease the limit under paragraph (1) of this Article, depending on its needs, subject to the available balance in the participant’s account in the RTGS system and the value of its multilateral net position in the DNS system. The participant’s multilateral net position referred to in paragraph (2) of this Article shall be the sum of the value of all payment transactions received by the participant in the DNS system, reduced by the sum of the value of payment transactions sent by the participant to other participants, and may be either positive or negative. The participant shall not be permitted to reduce the established limit referred to in paragraph (1) of this Article below the amount of its current multilateral net position in the DNS system. In case the participant cannot set or change the coverage cap in paragraph (1) of this Article electronically, the information on the setting or changing of the coverage cap shall be submitted to the Department, no later than by 16:10 hours, on the prescribed template enclosed herewith.” Article 18 In Article 71 paragraph (1) item 2) the words: “In SWIFT format” shall be replaced by the following: “in MX format in accordance with the ISO 20022 Standard” In paragraph (1) a new paragraph shall be added, worded as follows: “Notwithstanding paragraph (1) item 2) of this Article, the message shall be considered valid even if it is created in the SWIFT format in accordance with these rules, using the functionality of the RTGS system that enables the conversion of the MT format into the MX format.”. Article 19 Article 74 shall be amended to read: “For sent messages that are covered in the DNS system account, the DNS system shall automatically send the sender an acknowledgment of message receipt and, in real time, forward a copy of the original message to the recipient.” Article 20

Article 75 shall be amended to read: “If the negative multilateral net position exceeds the established clearing limit, the sent messages shall be placed in the gridlock, and upon securing sufficient funds, they shall be executed in real time or in the next clearing cycle, depending on the time the message was submitted.” Article 21 After Article 76, a new article shall be added, worded as follows: “Article 76a The sender may not revoke a payment transaction message for which the payment recipient has received a copy of that message.” Article 22 In Article 77 paragraph (1) shall be amended to read: “The sender may revoke a payment transaction message, or one or more instructions within the message or group payment order that is in the gridlock, until 16:15 hours.” In paragraph (2) the words: “no later than 15:30 hours ” shall be replaced by the following: “no later than 16:00 hours ”. Article 23 Article 79 shall be amended to read: “A participant in the DNS system has the ability to monitor its multilateral net position in real time via the user portal.” Article 24 In Article 89 paragraph (4) the words: “no later than 15:30 hours” shall be replaced by the following: “no later than 15:45 hours”. Article 25 Article 91 shall be amended to read: “Annexes to these Rules make an integral part thereof and they are laid out under the following order:

Annex 1 – Registration of persons authorised for contact with the Central Bank and person authorised for security and safety of communication with the RTGS and the DNS system;
Annex 2 – Specification of ICT system components on the participants’ side necessary for connecting to the RTGS system;
Annex 3 – Core elements of transfer orders and the manner of completing core elements of transfer orders into corresponding electronic messages
Annex 4 – Messages in MX and MT format;
Annex 5 – Request for the change of message priority in the RTGS system;
Annex 6 – Requests for the cancelation of payment transaction messages in the RTGS and DNS systems;
Annex 7 – Requests for resending messages from the RTGS and DNS systems;
Annex 8 – Complaints regarding payment transactions executed in the RTGS and DNS systems;
Annex 9 – Daily Work Time Schedule of the RTGS and DNS system;
Annex 10 – Requests for the extension of operating hours of the RTGS and DNS systems;
Annex 11 – Request for determining or changing the limit for negative net position from the multilateral calculation in the DNS system.” Article 26 After Article 94, two new articles shall be added, worded as follows: “Article 94a The provisions of Article 24, paragraph (3), and Article 71, paragraph (2) of these Rules shall apply 12 months from the date these Rules enter into force.” Article 94b Until the successful production launch of the upgraded Payment System in accordance with these Rules, the Operating Rules of the Central Bank of Montenegro Payment System (OGM 48/14 and 57/14) shall apply.” Article 27 These Rules shall enter into force on the day of their publication in the Official Gazette of Montenegro. THE COUNCIL OF THE CENTRAL BANK OF MONTENEGRO CHAIRPERSON Decision number: 0101-4080-2/2025 G O V E R N O R Podgorica, 15 May 2025 Irena Radović, m.p.

ANNEX 1 REGISTRATION OF PERSONS AUTHORISED FOR CONTACT WITH THE CENTRAL BANK AND PERSON AUTHORISED FOR SECURITY AND SAFETY OF COMMUNICATION WITH THE RTGS AND THE DNS SYSTEM

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

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

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

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

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

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

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

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

ANNEX 2 SPECIFICATION of ICT system components on the participant’s side necessary for connecting to the RTGS system A participant shall provide ICT components to be used for installing File Adapter (or RCCC component or Controller Workplace, depending on the type of connection to be used by the participant) and the realisation of computer communication with the information and communication system of the CBCG.

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

ANNEX 3 CORE ELEMENTS OF TRANSFER ORDERS AND THE MANNER OF COMPLETING CORE ELEMENTS OF TRANSFER ORDERS INTO CORRESPONDING ELECTRONIC MESSAGES The table below describes core elements of transfer orders and the manner of completing core elements of transfer orders into the corresponding electronic messages: Numbe r Name of elements of data Manner of completing elements of data Electroni c 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 a natural person’s residence 335x 335x – alphabet, numerical and alphanumerical characters 2 Transaction account of payer Transaction account to be debited 18n As per decision regulating the structure of transaction account 18 numeric characters (3+13+2) It is not completed in payment orders 3 Name of recipient Name and head office of a legal person or entrepreneur, 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 Payment purpose Purpose, i.e. the basis for payment 535x 535x – 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. 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 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 10 Model (model of credit Control number of the reference number 2n Completed if needed

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. 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. 11 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 12 Execution date Date when the order should be executed DDMMGG Numeric data

ANNEX 4 Messages in MX and MT format

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

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

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

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

MT 910 Confirmation of Credit is used as the confirmation of crediting a participant’s account after executing the payment transaction (MT 103 or MT 202) MT 920 Request Message 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 Interim Transaction Report contains data on payment transactions from previously submitted interim or daily report. For accounts of state authorities, it has the character of regular reports for their payment accounts MT 970 Netting Statement contains information on payment transactions executed in the DNS system during the specific clearing period MT 972 Netting Interim Statement contains information on payment transactions executed in the DNS system MT 985 Status Enquiry 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 Status Report 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 on the status of previously sent message MT 103 or MT 102 MT 295 Queries on the status of previously sent message MT 202 MT 196 Answers to query MT 195 or system information on the status of previously sent message MT 103 or MT 102 MT 296 Answers to query MT 295 or system information on the status of previously sent message MT 202 MT 999 Free Format Message 2.1 Message structure 2.1.1 MT message header Each instruction contains information on participant in the RTGS system as the sender or recipient from/to RTGS system and on the RTGS system itself.

An example of “Message header” is given in the table below: 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 CBCGMEPGXIPSN RTGS - system Podgorica RTGS system  participant Number of segment Name of field RTGS system  participant 1: Recipient UNCBMEPGXXXX RTGS - system Podgorica 2: Type of message 103 2: Sender CBCGMEPGAIPS Hipotekarna banka AD Podgorica 2.1.2. Characters defining the MT message format: SWIFT field structure: Character Description Examples n Numeric field 18n – numeric field up to 18 characters ! Behind a number represents a fixed length determined by that number 18!n – field of fixed 18 numeric characters a Exclusively alphabetic field (capital letters) 4!a – exactly four alphabetic characters d Decimal field 15d – numeric field with two decimals up to 15 characters (12n,nn) x Alphabetic, numeric and sign field 35x – represents up to 35 alphabetic, numeric and sign characters c Alphabetic-numeric field 3c – field containing 3 alphabetic, 3 numeric or 3 alphabetic-numeric characters 335x First number determines the number of lines, and the second one the number of character per line 335x – 3 lines, each containing up to 35 characters [ ] Field in square brackets are optional [1!a] – in certain cases this field has fixed one character, otherwise it is left blank  ----I Fields between these two signs can be repeated several times

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

113 Priority with value 100 determines whether payment transactions shall be executed in the DNS 4n yes Example: 113:0100 20 Message recipient 16x yes Message TRN 23 CREDIT 6!a yes CREDIT-fixed value 26T Payment transaction code type 3!n Default value is 001 71A SHA 3!a  21 Payment transaction reference 16x yes 32B Value currency (EUR) and

amount (12n,nn) 3!a15d yes Example: 32B:EUR100,00 50K Account of payer to be debited (3n13n-2n) / 18!n35x 335x yes Example: :50K:/580000000000123475 PAYER OF BENEFICIARY A Ul.Slobode br.2 PODGORICA Name of payer: Name (of legal person or entrepreneur; natural person) address place 59 Account of recipient of payment to be credited (3n-13n-2n) / 18!n35x 335x yes Example: :59:/570000000000873444 RECIPIENT OF PAYMENT OF BENEFICIARY B Ul. Balšićeva br.5 BUDVA Name of recipient: Name (of legal person or entrepreneur; natural person) address place 70 Information on remitting of funds:
Payment code
Field code PBZ followed by model of debiting reference and debiting reference separated by hyphens
Field code PBO followed by model of crediting reference and crediting reference separated by hyphens 435x SIF-3n PBZ-2n-20x PBO-2n-20x yes Example of proposed format: :70:SIF-120 PBZ-00-12345 PBO-00-4567-2008 77B Payment purpose 335x yes Example: :77B: PAYMENT PER INVOICE NO. 4567 ----I 32A Execution date (YYMMDD), value currency (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 53A Participant which account is debited: /D/ Participant’s account /D/18!n 4!a2!a2!c[3! c] yes Example: :53A:/D/90700000000580013 8 CKBCMEPG BIC of the participant

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

Name of recipient of payment to be credited: Name (of legal person or entrepreneur; natural person) address place yes RECIPIENT OF PAYMENT OF BENEFICIARY B Ul.Balšićeva br.8 PODGORICA 70 Information on funds remitting:

Payment code
Field code PBZ followed by model of debiting reference and debiting reference separated by hyphens
Field code PBO followed by model of crediting reference and crediting reference separated by hyphens 435x SIF-3n PBZ-2n-20x PBO-2n-20x Yes Example of proposed format: SIF-132 PBZ-05-02731266 PBO-05-35092-09-001- 4000247 71A SHA 3!a Yes 72 Payment purpose Code CODTYPTR/001 is entered at the beginning 35x 535x Yes Example: :72:/ CODTYPRT/001 /customs debt NOTE: When paying public revenues, field 70 of message MT 103 is completed as follows: 70 Information on funds remitting:
Number of payment accounts (Tax Administration, Customs Administration, Ministry of Internal Affairs or Central Account of State Treasury)
Payment code (SIF- 3n)
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 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 3.3 Message MT 202 – General Financial Institution Transfer in RTGS system Message MT 202 is used for payment transaction between participants in the RTGS system. The structure of elements is as follows:

Fiel d Elements of payment transaction order Format Mandato ry Note Sender Yes Recipient Yes 113 The priority for payment transactions in the RTGS system may be from 0010 to 0099. Value 0010 is for highest priority; if the priority is not indicated, default value is 0099 4n Yes Example: 113:0099 20 Message reference 16x Yes Message TRN 21 Related reference 16x Yes Reference to which the message refers or enter code NONREF 32A Execution date (YYMMDD), value currency (EUR) and

amount (12n,nn) 6!n3!a15d Yes Example: 32A:090126EUR150,39 53A Participant which account is debited: /D/ Participant’s account /D/18!n 4!a2!a2!c[3! c] Yes Example: :53A:/D/90700000000580013 8 CKBCMEPG BIC of the participant 58A Participant which account is credited: /C/ Participant’s account /C/18!n 4!a2!a2!c[3! c] Yes Example: :58A:/C/90700000000570013 1 PDBPMEPG BIC of the participant 72 Code CODTYPTR/001 is entered at the beginning Information on funds remitting: Payment transaction type code
Payment code (SIF- 3n)
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 (001) SIF-3n PBZ-2n20x PBO-2n20x 35x Yes Example of proposed format: :72:/CODTYPRT/001 //SIF-383 //PBZ-00 //PBO-00-00-401-0115296-2 // PAYMENT OF LOAN INSTALMENT NOTE: The participants in the RTGS system shall complete field 72 of the message MT 202 with regard to cash payments to and from the account in banknotes and coins as follows:
For cash payments to and from the participant’s account in banknotes:

72 Code CODTYPTR/002 is entered at the beginning Information on funds remitting:

Payment transaction type code
Payment code
Field code PBZ followed by model of debiting reference and debiting reference separated by hyphens
Field code PBO followed by model of crediting reference and crediting reference separated by hyphens
Payment purpose (lines 2-5 have to be started with two slashes (//)) 5*35x (002) SIF-3n PBZ-2n20x PBO-2n20x 35x Yes Example of proposed format: :72:/CODTYPTR/002 //SIF-383 //PBZ-00 //PBO-00-00-401-0115296-2 // CASH PAYMENTS TO AND FROM THE ACCOUNT IN BANKNOTES
For cash payments to and from the participant’s account in coins 72 Code CODTYPTR/003 is entered at the beginning Information on funds remitting:
Payment transaction type code
Payment transaction code (SIF- 3n)
Field code PBZ followed by model of debiting reference 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 Yes 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. 4 Category 9 – Confirmation on receipt, account status and reports 4.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 structure of elements is as follows: Field Message element Format Mandato ry Note

Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes TRN of the message to which the confirmation refers 25: Account of participant to be debited 18!n Yes :25:907000000005800138 32A Execution date (YYMMDD), value currency (EUR) and amount (12n,nn) 6!n3!a15d Yes Example: :32A:090123EUR453,69 52A BIC of participant executing payment transaction for a third party 4!a2!a2!c[3!c ] :52A:CBCGMEPGRTG 72 Information from sender to recipient /3!a/ 16!n /8!a/ 12!c /7!c/ 26x 16x 4*35x MT 900 message for MT 103 and MT 202 payment messages does not contain fields 52A and 72 MT 900 message from clearing contains fields 52A and 72 4.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 structure of elements is as follows: Field Message element Format Compuls ory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes TRN of the message to which the confirmation refers 25 Account of participant to be credited 18!n Yes :25:907000000005700131 32A Execution date (YYMMDD), value currency (EUR) and amount (12n,nn) 6!n3!a15d Yes Example: :32A: 090123EUR453.69 52A Account of participant to be credited BIC of the participant to be credited 18!n 4!a2!a2!c[3! c] Yes Example: :52A:/D/90700000000580013 8 FFBMMEPG 72 Information from sender to recipient /3!a/ 16!n /8!a/ 12!c /7!c/ 26x

16x 4*35x 4.3 Message MT 920 – Request Message Message MT 920 is used as a request for information on account balances at the specific moment or request for the delivery of report on executed payment transactions of a participant. The participant sends this message to the RTGS system. The structure of elements is as follows: Field Message element Format Mandato ry Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN  12 Identifies the type of message for which the request is sent 3!n Yes There has to be one of these message types: 940,941 and 942. 25 Number of account to which 18!n Yes 907000000005800138 34F currency code - EUR sign D (for debiting) or empty the limit below which transactions are not included in the report (12n,nn) 3!a[1!a]15d Example: :34F:EURD10, 34F currency code - EUR sign C (for crediting) or empty the limit below which payment transaction is not included in the report (12n,nn) 3!a Example: :34F:EURC10, If two fields of 34F are present, the first 34F field must contain sign D, while the latter 34F must contain sign C, while if only a single field 34F is used, signs C or D should not be used – it implies a debiting limit. 4.4 Message MT 940 – Customer Statement Message Message MT 940 is a daily report on executed payment transactions of the participant and it is the response to send request MT 920. The RTGS system sends the message MT 940 to the participant. The structure of elements is as follows: Fiel d Message element Format Mandato ry Note Sender Yes Recipient Yes 20 Message recipient 16x Yes TRN in SWIFT 25 Participant’s account number 18!n Yes Number of account to which the message refers 28C Report number 5n Yes 60F Opening balance in the form: debit / credit (D/C) date - YYMMDD, 1!a6!n15d 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!n2a15d1!a3 !c16x //16x 4!a2!a2!c[3!c] 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 client to be credited (code MT 103 – field 59 and code MT 202 field 58A)
next 4 lines of the report are field 70 of message MT103. 4!a2!a2!c[3!c] 4!a2!a2!c[3!c] 4!a[/6!n4!n1!x 4!n]

I 62F Closing balance:

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

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

debit/credit - D/C
date - YYMMDD,
currency code - EUR, 1!a 6!n Yes Example: :60F:C090628EUR595771,00
amount (12n,nn). 3!a 15d 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!a 6!n 3!a 15d 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!a 6!n 3!a 15d Example (in case EUR 179.226,00 has been reserved for clearing) : :64:C091111EUR480625,00 4.6 Message MT 942 –Interim Transaction Report Message MT 942 contains data on payment transactions from previously taken interim or daily report, as a response to request МТ 920. The structure of elements is as follows: Field Message element Format Compul sory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Connecting reference 16x Reference of message МТ 920, with which this message was initiated 25 Account number 18!n Yes Number of account to which 28C Number of reports / page number of report 5n Yes 34F
currency code - EUR
sign D (for debiting) or empty
the limit below which transactions are not included in the report (12n,nn) 3!a[1!a]15d Yes Example: :34F:EURD10,00 34F
currency code - EUR
sign C (for crediting) or empty
the limit below which transactions are not included in the report (12n,nn) 3!a[1!a]15d Example: :34F:EURC10,00 13D Date and time of sending YYMMDDHHMM+0100 6!n4!n1!x4! n Yes Example: 0908261050+0100  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 4!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 message MT103. 6*65 ------I 90D - Number of debit payment transactions
currency code - EUR
amount 5n3!a15d Example: :90D:2EUR2000,00 90C - Number of credit payment transactions
currency code - EUR
amount 5n3!a15d Example: :90C:8EUR1000,00 If two 34F fields are present, the first 34F field must contain sign D, while the latter 34F must contain sign C, while if only a single field 34F is used, signs C or D should not be used – it implies a debiting limit. 4.7 Message MT 970 – Netting Statement and MT 972 - Netting Interim Statement Message MT 970 is the report on executed payment transactions in the DNS system. It is sent automatically at the end of the cycle, while message MT 972 is sent at request and includes payment transactions from the last MT 970 or MT 972. The structure of elements is as follows: Field Message element Format Mandatory Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 25 Participant’s account number 18!n Yes Number of account to which the message refers 28C Number of reports / page number of report 5n Yes 60F Opening balance in the form:
debit/credit - D/C
date - YYMMDD
currency code – EUR amount (12n,nn). 1!a6!n15d Yes Example: :60F:C090126EUR0,  61 First report line:
execution date – YYMMDD, 6!n
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 4!n 2a 1!a 15d 1!a3!c 16x //16x 34x 4!a2!a2!c[3!c ] :61:090126D53,30S1028 90560000003832c//2441 6664 HBBAMEPG ------I 62F Closing balance with the date of sending:
debit/credit - D/C
date - YYMMDD, currency code - EUR, amount (12n,nn). 1!a6!n3!c15 d Yes Example: :62F:C090126EUR1592, 76 4.8 Message MT 985 – Status Enquiry A participant sends the message MT 985 for enquiry on their account status to which the system responds with the MT 986 message. The structure of elements is as follows: Field Message element Format Mandato ry Note 20 Message recipient 16x Yes Message TRN 57A BIC in RTGS system 4!a2!a2!c[3!c] Example: :57A:CBCGMEPGIPS 59 Account of the participant to which the query of the BIC refers /18!n 4!a2!a2!c[3!c] Yes Field “Account to which the query of the BIC refers” (/18!n) is not compulsory for following queries: PCLT, TTLS i TTLD Example: :59:ATLMMEP2 BIC of the participant 75 Queries Description of formats depending on request: Yes Type of query: 4!a STAT – account status 4!a SQDC – report on waiting order 4!a PCLT – set clearing limit 4!a [6!n/]16x
TTLS – clearing session totals in DNS system
YYMMDD, slash followed by session (e.g. MORNING, EVENING or FINAL) 4.9 Message MT 986 – Status Report

Message MT 986 is automatically generated and sent to the participant upon completion of the clearing cycle, and it also serves as a response to the query sent via the MT 985 message. Responses supported by the RTGS system are given in field 79. The structure of elements is as follows: Field Message element Format Mandato ry Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Message reference to which the response refers 16x Yes 59 Account of the participant to which the query refers /18!n 4!a2!a2!c[3!c] Yes Example: :59:PDBPMEPG BIC of the participant 79 Response Yes Possible responses to STAT query: /4!a/ / 6!n4!n1!x4!n 2!a /1!a/12a/15n STAT/ Possible responses to query on status (second line of response):

The account is not frozen
The account is frozen for debiting
The account is frozen for crediting
The account is frozen 2!a AA - code DA - code AC - code DC - code

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
value date, set limit
value date, value of field is 0
value date, net balance position in current session
current session 4!a[/6!n4!n1!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/

5 Category n – Common Group Messages 5.1 Message MT n91 – Report on daily charge of the Central Bank fee for executing payment transactions in the RTGS and DNS systems. Message MT 991 is sent as a Report on daily charge of the Central Bank fee for executing payment transactions in the RTGS and DNS systems. The structure of elements is as follows: Field Elements of transfer order Format Mandator y Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes NONREF 32B Currency code (EUR) Amount (12n,nn) 3!a15d Yes Example: :32B:EUR6,76 52A BIC of the participant to be credited 4!a2!a2!c[3!c] Yes Example: :52A:PDBPMEPG 57A BIC of the Central Bank of Montenegro to which the fee is paid 4!a2!a2!c[3!c] Yes Example: :57A:CBCGMEPG 71B Details on debiting 4!c 6!n Yes 72 Information from sender to recipient 9!c :72:/INT/ 5.2 Message MT n92 – Request for Cancellation Message MT 192 is used as the request for cancelation of previously sent messages MT 103 and MT 202, and the message MT 292 is used for the cancelation of the MT 202 message. The message may be recalled as long as it has not been executed. The structure of elements is as follows: Field Elements of transfer order Format Mandato ry Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes TRN of message to which the request refers 11S MT number 3!n 6!n Yes Example: 11S:103 Date - YYMMDD 090104 79 BIC of the participant who sent the message 4!a2!a2!c[3! c] Yes Example: :79: PDBPMEPG 090104

Execution date - YYMMDD 6!n 5.3 Message MT n95 – Queries on previously sent messages Message MT 195 is used as enquiry on previously sent messages MT 103 and MT 102, and the message MT 295 is used as enquiry on previously sent message MT 202. The structure of elements is as follows: Field Elements of transfer order Format Mandato ry Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes TRN of message to which the request refers 75 Queries 4!a Yes Possible queries: STAT - Message status PRTY – priority change DUPL – Message duplicate 77A The field is used only when changing the priority (if the field :75: contains code PRTY) 4!a The field is compulso ry only for query PRTY, Example: 77A:0020 11S MT number 3!n 6!n Example: :11S:103 Date - YYMMDD 090104 79 BIC of the participant who sent the message 4!a2!a2!c[3! c] 6!n Example: :79: PDBPMEPG Execution date 090104 5.4 Message MT n96 – Answers Message MT 196 is the response to requests and queries to previously sent messages MT 192 or MT 195, while message MT 296 is the response to requests and queries to previously sent messages MT 292 or MT 295. In addition to the aforementioned, the system automatically generates messages MT 196 and MT 296. The generated MT196 message informs the participant about the status of a previously sent MT102 or MT103 message, while the MT296 message informs about the status of a previously sent MT202 message. The structure of elements is as follows: Field Message element Format Mandato ry Note Sender Yes

Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x Yes TRN from field 20: of message n95 to which the response is made 76 Responses 4!a / 6!n4!n1!x4!n 4!c / 6!n4!n1!x4!n Yes Responses to requests: STAT – statuses given in the table below DUPL – message duplicate PRTY – priority change CANC – message is cancelled ERRC – message on error in request 77A Textual description of response (it refers to the error in request or query) 2!35x35x If the response contains error write the code in the first line, and the description of error in the last two lines 11R MT number – message number 3!n 6!n Yes Example: :11R:202 090628 Date - YYMMDD 20 Copy containing at least all compulsory fields of original message 16x 30 Date of the message for which the status is being provided 6!n Example: 250509 82A BIC of the sender 4!a2!a2!c[3!c] Example: CKBCMEPG In response to a status inquiry (STAT), field 76 may contain the following responses in the MT message: STAT/date, time - first line of response REJT /date, time - second line of response Message was rejected with message MT n92 sent by the participant STAT/date, time - first line of response CANC/date, time - second line of response Message was cancelled due to the rules of the CBCG RTGS system, it is also sent when CBCG rejects the message without request STAT EXEC Payment transaction is being executed STAT SETL Payment transaction is executed STAT WAIT The message is in the queue STAT SUSP The message is suspended STAT ERRP There was an error STAT INAC A message with a future value date cannot be executed within the current business day. STAT The message is pending authorization.

AUTH STAT ACSP The message has been published and a copy delivered to the recipient. STAT PROC The group credit transfer is suspended due to the business day schedule. Field 76 of Enquiry on message duplicate (DUPL) may contain the following responses: DUPL - first line of response OK - second line of response Requested message will be copied Field 76 of Enquiry on priority change (PRTY) may contain the following responses: PRTY - first line of response <changer priority> - second line of response Payment transaction priority is changed PRTY ERRC Error in priority changing Field 76 of Enquiry on message cancelling (CANC) may contain the following responses: CANC – payment transaction is cancelled OK - second line of message Payment transaction is cancelled CANC ERRC Error in request processing Message on error as a response to enquiry MT n95 or MT n92 in the field 76 gives only one row with the code ERRC, while field 77A gives the description of the error. 5.5 Message MT n99 – Free Format Message Message MT 999 is a free format message. The structure of elements is as follows: Fiel d Elements of transfer order Format Mandato ry Note Sender Yes Recipient Yes 20 Message recipient 16x Yes Message TRN 21 Related reference 16x 79 Message text: 3550x Yes /TEXTMESSAGE/BIC /11!c/4!a2!a2!c[3! c] 3450x Example: /TEXTMESSAGE/ PDBPMEPG

Notification of Account Locking: /LCKA/ /4!a/6!n4!n1!x4!n/ ACNT/34x /LDBT/Y /LCDT/Y Example: :/LCKA/2403101748+0200 /ACNT/907000000005400110 /LDBT/Y /LCDT/Y Notification of Account unlocking: /ULKA/ /4!a//11!c/12x 6!n4!n1!x4!n /ACNT/34x /UDBT/Y /UCDT/Y /ULKA/2403101748+0200 /ACNT/907000000005400110 /UDBT/Y /UCDT/Y Setting the account limit: /SETACCOUNTLIMIT/CLEARI NG /STATUS/ /ACTION/ /DIRECTION/I (for limit increase) or D (for limit decrease) /ACCOUNT/ account number /AMOUNT/ amount – new limit /15!a/12x /7!a/34x /6!a/15d Example: /SETACCOUNTLIMIT/CLEARI NG /STATUS/ /ACTION/ /DIRECTION/I /ACCOUNT/ 907000000005050134 /AMOUNT/ 1000,00 Notification of Set Limit on Account: SETACCOUNTLIMIT/CLEARIN G /8!a/ /15!a/12x /7!a/34x /6!a/15d /ACCOUNT/907000000005050 134 /AMOUNT/800000.70 Request for information on the account limit. /GETACCOUNTLIMIT/ /15!a/ /7!a/34x /GETACCOUNTLIMIT/ /ACCOUNT/907000000005050 134 Response to the Request for Information on Account Limit: /RETACCOUNTLIMIT/ /15!a/ /7!a/34x /7!c/12x /6!a/15d /RETACCOUNTLIMIT/ /ACCOUNT/907000000005050 134 Request for report on the business day period: /GETBUSINESSDAYPERIOD/ Notification on the business day period: /BUSINESSDAYPERIOD/ /20x/ /17a/ 3*35x Notification/Warning About Impending Password Expiry: /PASSWORDEXPIRATION/ /18!a/ 30x //48x /PASSWORDEXPIRATION/ /PASSWORDEXPIRATION/Us er should change password in 3 days

Notification That Password Has Expired: /PASSWORDEXPIRED/ /15!a/ 33x //48x /PASSWORDEXPIRED/ /PASSWORDEXPIRED/User must change password now or will be blocked Password Change Request: /CHANGEPASSWORD/ Password Change Confirmation CHANGEPASSWORD/OK /14!a/34x [1650x] /11!a/37x [1650x] /14!a/ 2!a /CHANGEPASSWORD/800000 00712921E0E4C2C5468ED3B /OLDPASSWORD/800000008E 0E112A86ED8417B32F2028A0 /CHANGEPASSWORD/ OK

ANNEX 5

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