Regulation on Maintenance of Settlements Between Payment Service Providers

‘Approved’ Central Bank of the Republic of Azerbaijan Decision № 40/10 12 November 2025 Regulation on maintenance of settlements between payment service providers

1. General provisions This Regulation has been developed in accordance with Article 47.2 of the ‘Law of the Republic of Azerbaijan on the Central Bank of the Republic of Azerbaijan’ and govern rules for maintaining settlements among participants of the payment systems operated by the Central Bank of the Republic of Azerbaijan (hereinafter – the Central Bank) - Real Time Gross Settlement System (hereinafter – AZIPS), the Low-Value Payments Clearing and Settlement System (hereinafter – LVPCSS), and the Instant Payments System (hereinafter – IPS).
2. Definitions 2.1. The definitions used in this regulation bear the following meanings: 2.1.1. participant – a bank, the national postal operator, an electronic money institution, or a payment institution (excluding institutions that provide solely account information services and/or payment initiation services) that carries out payment operations in AZIPS, LVPCSS, and IPS (hereinafter collectively – the systems), as well as other legal entity whose bank accounts are serviced by the Central Bank. 2.1.2. issuer participant – the participant who pays the funds. 2.1.3. beneficiary participant – the participant who receives the funds. 2.1.4. direct participant – a participant that opens a correspondent or current account with the Central Bank for the purpose of settling with other system participants. 2.1.5. indirect participant – a participant that opens a correspondent or current account with a direct participant for the purpose of settling with other system participants. 2.1.6. intermediary – a payment service provider that, in accordance with the Law of the Republic of Azerbaijan ‘on Payment Services and Payment Systems,’ provides payment initiation services. 2.1.7. value date – the payment transaction execution date on the participant’s account. 2.1.8. Bank Identification Code (BIC) – the identification number issued to participants by the Society for Worldwide Interbank Financial Telecommunication (SWIFT) or by the Central Bank. 2.1.9. priority code – the number determined by the participant sending the payment order, used for managing the priority of processing the payment order. 2.1.10. payment order – a credit transfer (transfer instruction) or direct debit issued respectively by the issuer and beneficiary participants for payment transactions in the systems. 2.1.11. batch –a collection of payment orders grouped by type by participants within the systems.

2.1.12. payment file – a specially formatted file created on the basis of one or more batches and used for the exchange of payment orders among participants. 2.1.13. IPS settlement account – an account used in the IPS for executing transactions within the amount of funds pre-blocked in the direct participant’s correspondent account. 2.1.14. technical account – an account used in the IPS for executing the transactions of indirect participants. 2.1.15. payment request – a request initiated by the beneficiary participant in the IPS that enables funds to be debited from the payer’s account with the payer’s consent. 2.1.16. clearing account – an account opened for a participant in the LVPCSS for executing a payment transaction. 2.1.17. net position – the difference between total funds credited to and debited from the clearing account. 2.1.18. debit limit – the amount of funds blocked in the participant’s correspondent account in AZIPS for the settlement of debit net positions resulting from the clearing session. 2.1.19. clearing – the process in the LVPCSS during a clearing session by which claims and obligations arising from payment amounts that one or more participants owe to, or receive from, one or more other participants are converted into a single net claim or a single net obligation. 2.1.20. clearing session – the period during the operational day in the LVPCSS, based on established regulations, during which batches are received from participants, processed, and the resulting net settlement positions are determined. 2.1.21. mandate – an agreement registered in the LVPCSS for carrying out transactions based on direct debit between the beneficiary and issuer participants. 2.1.22. real-time mode – an operating mode in which settlements and data exchange for payment transactions in the systems are carried out immediately within the framework of the relevant system's regulations. 2.1.23. 24/7/365 mode – an operating mode in which settlements and data exchange for payment transactions in the systems are carried out at any time of day in real time, including on non-working days specified by legislation. 2.1.24. Interbank Card Center (ICC) – a component of the payment systems operated by the Central Bank. 3. Execution of payment orders 3.1. Settlements between direct participants in the systems are carried out through correspondent and current accounts opened with the Central Bank. 3.2. Payment orders in the systems are accepted and executed when the following conditions are met simultaneously: 3.2.1. the payment order complies with the requirements of the ‘Regulation on maintaining payment operations and on payment instruments’ approved by Decision No. 12/3 of the Management Board of the Central Bank dated 13.03.2024. 3.2.2. there is no decision (order) on seizure or suspension of operations regarding the accounts of the issuer and beneficiary participants. 3.2.3. the value date of the payment order corresponds to the time intervals defined in Items 3.7 and 3.8 of this Regulation. 3.2.4. there are sufficient funds in the issuer participant’s account for the execution of the payment order.

3.3. A payment order sent by a participant becomes irrevocable and is deemed an unconditional order from the moment funds are debited from the participant’s account. 3.4. Account statements and other information regarding the participant’s relevant account are provided by the Central Bank electronically using technical capabilities of the systems or on paper upon written request by the participant. 3.5. Data formats used in the systems, as well as operational regulations of the systems, the procedure for conducting transactions through the ICC, and the rules for resolving disputes arising from such transactions, are approved by the Management Board of the Central Bank. The regulation defines time intervals for sending, receiving, and processing payment orders, requests, notifications, and information during the operational day; the procedure for temporary changes to system operating hours; the number of clearing sessions conducted in the LVPCSS during the operational day; the number of adjustments carried out between IPS settlement accounts and AZIPS based on account balances, and the maximum amount of a single payment order accepted in the LVPCSS and IPS. The operating regulation of the IPS also specifies the organization of activities of participants and intermediaries, including their rights and obligations, time limits for operations, service requirements for participants and intermediaries, and rules for resolving disputes related to system operations. The regulation is published on the official website of the Central Bank. 3.6. In the event of any change to the regulation, the Central Bank provides participants with written or electronic notice at least 1 (one) month before the effective date of changes. 3.7. A credit transfer sent by a participant with a value date identical to the operational day is accepted and processed on the same day by the Central Bank based on the regulations of the relevant payment system. 3.8. A direct participant in AZIPS and LVPCSS may send a credit transfer to the systems no more than 10 (ten) calendar days before the value date. In this case, information on the credit transfer is stored in the relevant systems and executed on the value date. 4. Settlements in AZIPS 4.1. AZIPS is used for conducting settlements between direct participants in real time based on the procedure approved in accordance with Item 3.5 of this Regulation. 4.2. Settlements in AZIPS are carried out through correspondent and current accounts of direct participants. 4.3. Settlements in AZIPS may be conducted using the following data exchange means: 4.3.1. through the Closed Telecommunications Network (hereinafter – CTN) established for information exchange in the systems. 4.3.2. through SWIFT (if the direct participant is a SWIFT member). 4.4. A direct participant may use the CTN or the SWIFT platform for information exchange with AZIPS by submitting relevant information (in electronic or paper form) to the Central Bank. 4.5. To execute operations in AZIPS via the CTN, the direct participant should be connected to the dedicated telecommunications network created for information exchange in payment systems. 4.6. To conduct operations in AZIPS via the CTN, the direct participant should install on appropriate server equipment the ‘STP-Adapter’ module provided by the Central Bank, taking into account technical and system requirements of the software.

4.7. A direct participant may send credit transfers to AZIPS in the following message formats: 4.7.1. customer payments (pacs.008); 4.7.2. bank payments (pacs.009, camt.050). 4.8. When a credit transfer is accepted for execution in AZIPS, the following is verified: 4.8.1. compliance of the value date with Items 3.7 and 3.8 of this Regulation. 4.8.2. non-duplication of the credit transfer number within the operating day. 4.8.3. compliance of the credit transfer with the formats specified for AZIPS. 4.8.4. accuracy of the direct participants’ BIC. 4.8.5. accuracy of the direct participants’ TIN. 4.8.6. accuracy of the correspondent (current) accounts. 4.8.7. consistency between direct participants’ BIC, TIN, and correspondent (current) accounts. 4.9. If any of the requirements specified in Item 4.8 herein are not met, AZIPS rejects the execution of the credit transfer and sends a notification (camt.029 or pacs.002, as applicable) to the direct participant indicating the reason. 4.10. If there is no deviation from the requirements specified in Item 4.8 herein: 4.10.1. AZIPS debits the account of the issuing participant and credits to the account of the beneficiary participant. 4.10.2. AZIPS sends a credit transfer notification to the beneficiary participant and, upon request, a payment execution confirmation (pacs.002) to the issuing participant. 4.11. To manage the queue order of payments, the issuing participant should indicate in the header of credit transfers a priority code reflecting their execution sequence. The priority code is set from 30 to 99. 4.12. A credit transfer sent by the issuing participant with a value date corresponding to the same day is kept in a pending (queue) mode by AZIPS when: 4.12.1. there is a decision (order) to freeze or suspend operations on the account of the issuing or beneficiary participant. 4.12.2. there are insufficient funds in the issuing participant’s account. 4.12.3. AZIPS operations are temporarily suspended. 4.13. In the cases specified in Item 4.12 herein, AZIPS sends a notification (pacs.002) to the issuing participant indicating the reason for placing the credit transfer in pending mode. 4.14. The priority code of a credit transfer in pending mode may be changed by sending a request (camt.087) from the issuing participant to AZIPS. 4.15. If, for whatever reason, it is not possible to change the priority code, AZIPS sends a notification (camt.029) to the direct participant indicating the reason. 4.16. A credit transfer in pending mode may be canceled by the sending participant by submitting a request (camt.056) to AZIPS. In this case, AZIPS sends a notification (pacs.002) to the sending participant. 4.17. If it is not possible to cancel a credit transfer for whatever reason, AZIPS sends a notification (camt.029) to the sending participant indicating the reason. 4.18. If the sending participant’s account does not have sufficient funds to execute settlements, any credit transfers scheduled for that day and still pending are canceled at the end of the operating day, and a pacs.002 notification is sent to the direct participant. 4.19. AZIPS sends notifications (camt.054) to direct participants regarding operations performed in their accounts within the authority granted to them in the system.

4.20. A direct participant may submit a request (camt.060/BALR, camt.060/INTR) to AZIPS to receive real-time general information (camt.052/BALR) and interim information (camt.052/INTR) about their account during the operating day. 4.21. A direct participant may submit a request (pacs.028) to AZIPS to receive real-time information (pacs.002) during the operating day regarding credit transfers credited to, debited from, or expected to be debited from their account. 4.22. A direct participant may submit a request (camt.060/SOOR) to AZIPS to receive real-time general information (camt.052/SOOR) during the operating day regarding credit transfers in pending mode, as well as the status of their correspondent or current account. 4.23. A direct participant may submit a request (camt.060/DOOR) to AZIPS to receive real-time detailed information (camt.052/DOOR) about credit transfers in pending mode during the operating day. 4.24. If a direct participant’s requests are filled out incorrectly, AZIPS sends a related notification (camt.029) to the direct participant. 4.25. At the end of the operating day, AZIPS sends an account statement (camt.053) to the direct participant. 4.26. The security of information exchange in AZIPS is ensured as follows: 4.26.1. when SWIFT is used for information exchange, information security is maintained under the established rules of that telecommunications network. 4.26.2. when the CTN is used for information exchange, electronic certificates of the Central Bank’s Bank Certificate Services Center (BCSC) are used to ensure information security. In this case, data transmission channels are encrypted to protect against unauthorized external interference, and authentication is performed using registration codes of direct participants. 4.26.3. a direct participant verifies the integrity and authenticity of information received from AZIPS via CTN using the public key infrastructure provided by BCSC. Any detected deficiencies in the electronic signature of received information are immediately reported to the Central Bank (in electronic or paper form). 4.27. In the event of a technical problem with using AZIPS, a direct participant should notify the Central Bank (in electronic or paper form). In this case, based on the participant’s request, access to AZIPS is provided through a dedicated workstation at the Central Bank. Once the technical problem is resolved and the direct participant informs the Central Bank (in electronic or paper form), their activity in the system is immediately restored 5. Operations in LVPCSS 5.1. The LVPCSS is used for the collection of batches sent by direct participants in accordance with the regulation approved under Item 3.5 herein, for conducting clearing, and for carrying out final settlements in AZIPS based on the net positions received. 5.2. A direct participant of LVPCSS should connect to the QTŞ established for the purpose of information exchange. 5.3. Depending on the chosen information exchange scheme, a direct participant of LVPCSS should install the ‘STP-Adapter’ software provided by the Central Bank on the appropriate server equipment, taking into account its technical and system requirements. 5.4. Information exchange security in LVPCSS is ensured as follows:

5.4.1. BCSC’s electronic certificates are used to ensure information security. Communication channels are encrypted to protect against unauthorized external interference, and authentication is based on registration codes of direct participants. 5.4.2. a direct participant verifies the integrity and authenticity of information received from LVPCSS using capabilities of the public key infrastructure provided by BCSC. Any discrepancy detected regarding the electronic signature of received information should be reported immediately to the Central Bank (electronically or on paper). 5.5. In the event of a technical problem related to the use of LVPCSS, the direct participant should notify the Central Bank (electronically or on paper). In such cases, the Central Bank ensures participation in LVPCSS through a specially designated workstation based on the direct participant’s request. Once the technical problem is resolved and the direct participant notifies the Central Bank (electronically or on paper), their system access is immediately restored. 5.6. Settlements in LVPCSS are conducted through direct participants’ clearing accounts. 5.7. Settlements in LVPCSS are based on payment files (head.002) sent by direct participants. The content of payment files may consist of two types of batches: 5.7.1. batches consisting of credit transfers (pacs.008). 5.7.2. batches consisting of direct debits (pacs.003). 5.8. Batches included in the payment files sent to LVPCSS are executed on a first-in, first-out basis. 5.9. Direct participants can manage the debit limit on their clearing accounts in LVPCSS as follows: 5.9.1. Direct participants can initially set and increase the debit limit of a clearing account by sending a bank payment (camt.050) in the appropriate format in AZIPS. In this case, the limit is set based on the specified amount without debiting the participant’s correspondent account, and the specified amount is added to the clearing account’s debit limit for each bank payment sent. Real-time information on each order processed to change the debit limit of a direct participant’s clearing account is sent to LVPCSS from AZIPS. 5.9.2. Direct participants can set the debit limit of a clearing account in LVPCSS using a request in the appropriate format (camt.011). Debit limit management requests are initially processed in LVPCSS. If the request is intended for initial debit limit determination, or if the requested amount exceeds the participant’s current debit limit, the request is sent to AZIPS in real-time. If the requested amount in the request is intended to reduce the current debit limit, and the current position of the participant’s clearing account is lower than the newly specified debit limit, this information is sent to AZIPS. Otherwise, a rejection notification (camt.025) is sent for the debit limit reduction request. Requests to change the debit limit received by AZIPS are processed according to the funds available in the participant’s correspondent account, and the result is reported to LVPCSS. If the requested amount in the request meets the conditions set forth in this clause, the clearing account’s debit limit is set equal to that amount. Based on the result of processing the request in AZIPS, a notification on the debit limit change is sent to the direct participant (camt.010). 5.10. direct participant creates a batch through the internal General Ledger. 5.11. The payment file based on the batch prepared in the General Ledger is sent to LVPCSS using the STP-Adapter workstation.

5.12. In LVPCSS, settlements based on direct debits can be carried out either with or without a mandate. Settlements based on direct debits without a mandate can, in turn, be executed in a clearing session or in real-time. 5.13. For the execution of payments with mandate, a request for mandate registration (pain.009) is sent to LVPCSS by the beneficiary participant at the instruction of the payee. Upon receipt, LVPCSS conducts an initial check of the mandate for compliance with the formats established by the Central Bank under Item 3.5 herein. After verification, a corresponding notification (pain.009) is sent to the issuer participant. The mandate becomes effective only after it is approved by the issuer participant (pain.012). 5.14. A batch consisting of direct debits under the mandate method (pacs.003) is prepared by the beneficiary direct participant and sent to LVPCSS within the payment file (head.002). Each payment within the direct debit should indicate the unique number of the associated mandate. In LVPCSS, direct debit details are matched against total amount specified in the mandate, maximum amount of each individual payment order, and total number of payments to be executed. The payment is accepted for processing only if all criteria are met; otherwise, a rejection notification (admi.002) is sent to the beneficiary participant. 5.15. For the execution of payments without a mandate, a batch of direct debits (pacs.003) is prepared by the beneficiary participant and sent to LVPCSS within the payment file (head.002). 5.16. A batch (pacs.003) is generated based on direct debits that have been received by LVPCSS and accepted for processing, and it is sent to the issuer participant within the payment file (head.002). 5.17. Direct participants using direct debits may operate in LVPCSS either under a mandatory or a non-mandatory authorization mode. By default, the mandatory authorization mode is set for all direct participants of the system. Each direct participant may determine or change its authorization mode by submitting a request to the Central Bank (electronically or on paper). 5.18. If an issuer participant operating under the mandatory authorization mode wishes to reject the execution of instructions contained in a batch of direct debits received from LVPCSS, it should send an appropriate notification (pacs.002) to the system. A batch that contains at least one direct debit intended for execution should be authorized by the issuer participant, and a corresponding notification (pacs.002) should be sent to LVPCSS. 5.19. If no authorization notification is received from an issuer participant operating under the mandatory authorization mode by the time of the final clearing session of the operating day for the batches consisting of direct debits sent to it, those batches are rejected by the system, and a notification (pacs.002) is sent to the beneficiary participant. 5.20. If an issuer participant operating under the non-mandatory authorization mode fails to send a rejection notification (pacs.002) during the session for direct debits contained in the batch or package received from LVPCSS, these items are included by the system in the next session’s clearing process. If batches sent to LVPCSS during the final clearing session are not rejected by the issuer participant, those batches are included in the clearing process of that session. 5.21. Only one payment order may be included in each batch for real-time, mandate￾free direct debits. Regardless of the issuer participant’s operating mode, confirmation is

required for the execution of these batches. If the issuer participant fails to confirm batches by the final session of the operating day, the system automatically rejects their execution. 5.22. A mandate-free direct debit processed in real time and confirmed by the issuer participant is immediately transmitted to AZIPS and processed without considering the debit limit set for the clearing account, provided that the required amount of funds is available in the direct participant’s correspondent (current) account. 5.23. The LVPCSS immediately sends a notification (pacs.002) to the issuer and beneficiary participants regarding the status of a completed mandate-free real-time batch. 5.24. When a payment file sent by a direct participant is accepted for execution, LVPCSS verifies the following: 5.24.1. completion of mandatory fields of the payment file and batches. 5.24.2. compliance of the batch value date with Items 3.7 and 3.8 of this Regulation. 5.24.3. uniqueness of the batch number. 5.24.4. compliance of the batch with the electronic payment order formats established by the Central Bank for LVPCSS. 5.24.5. accuracy of the participants’ BIC. 5.24.6. accuracy of clearing accounts. 5.24.7. accuracy of correspondent or current accounts. 5.24.8. consistency of participants’ BIC and correspondent accounts. 5.24.9. ensuring that the amount of each credit transfer within the batches does not exceed the maximum amount accepted in LVPCSS for a single credit transfer. 5.25. If any of the requirements listed in Item 5.24 are violated, the issuer participant is sent the following information indicating the reason: 5.25.1. notification of rejection of the payment file (admi.010). 5.25.2. notification of rejection of the batch (pacs.002). 5.25.3. notification of rejection of the payment order (camt.998). 5.26. If no inconsistencies are found in the payment file, LVPCSS sends a notification (admi.010, pacs.002) to the direct participant confirming acceptance of the payment file and its batches for execution. 5.27. A direct participant may obtain summary information (camt.052), reflecting total debit and credit operations and the balance of the clearing account, by sending a request (camt.060) to LVPCSS. 5.28. A direct participant may obtain the following information by sending a request to LVPCSS (admi.009, pacs.028, camt.033): 5.28.1. notification on the status of the payment file (admi.010). 5.28.2. notification on the status of the batch or the payment order within the batch (pacs.002). 5.28.3. a copy of the payment file (camt.034). 5.28.4. a copy of the batch or the payment order within the batch (camt.034). 5.29. A direct participant may obtain information on the status and copies of several payment orders included in a batch (pacs.002, camt.034) by sending a request (pacs.028, camt.033) to LVPCSS. 5.30. Payment operations in LVPCSS are carried out based on clearing sessions. Clearing sessions are divided into the following stages: 5.30.1. document exchange. 5.30.2. pre-clearing.

5.30.3. clearing. 5.30.4. confirmation of clearing results. 5.30.5. clearing results. 5.30.6. clearing reporting. 5.31. Based on the LVPCSS regulation, a notification (camt.019) is sent to direct participants by LVPCSS at the beginning of each stage of the clearing session. 5.32. From the moment the document exchange stage begins, a direct participant may send to LVPCSS payment files, as well as requests for determining debit limits, cancellation of payment files, batches or payment orders, and other requests for obtaining various reports and notifications regarding system operations. 5.33. During the document exchange stage, a notification (pacs.002) is sent to the direct participant indicating the result of the initial processing and the current status of each batch included in the payment files submitted to LVPCSS. 5.34. During the pre-clearing stage, LVPCSS calculates the preliminary net position of each direct participant’s clearing account and sends a notification (admi.010) reflecting executed and unexecuted credit transfers, as well as the shortfall amount required for the execution of remaining credit transfers. In this stage of the clearing session, direct participants are allowed to increase the debit limit of their clearing accounts. 5.35. If the current execution status of pending packages changes during the pre￾clearing stage due to insufficient funds in the participant’s clearing account, a notification (pacs.002) is sent. 5.36. During the clearing stage, net positions of direct participants’ clearing accounts for the current clearing session are determined. 5.37. During the confirmation of clearing results stage, the package of net positions of direct participants’ clearing accounts (camt.052) is sent to AZIPS for final settlement. After final settlement of clearing results is completed in AZIPS, the following reports and notifications are sent to direct participants: 5.37.1. report on executed payments in the current clearing session (camt.053). 5.37.2. report reflecting the net position of the clearing account in the current clearing session (camt.052). 5.37.3. report reflecting the total amount of debit and credit operations of the clearing account in the current clearing session (camt.052). 5.37.4. notification on the current execution status of batches (pacs.002). 5.38. During the clearing results stage, payment files (head.002) for the clearing session are sent to direct participants. 5.39. During the clearing reporting stage, a final statistical report (camt.052) for the clearing session is sent to direct participants. 5.40. In LVPCSS, batches scheduled for value date on the current day that remain unexecuted in the current clearing session are carried over to the next clearing session of the same day. If no subsequent clearing session is scheduled, the unexecuted batches are cancelled. In this case, a notification (pacs.002) is sent to the direct participant. 5.41. At the end of the operating day, an account statement (camt.053) for the clearing account is sent to each direct participant. 5.42. Notifications and responses to requests related to operations performed in LVPCSS are sent to direct participants in real time.

6. Settlements in the IPS 6.1. IPS is used for conducting settlements between direct and indirect participants on a 24/7/365 basis in accordance with the procedure approved pursuant to Item 3.5 herein. 6.2. Settlements in the IPS are carried out through IPS settlement accounts of direct participants and technical accounts of indirect participants. 6.3. The technical account of an indirect participant is linked to the IPS settlement account of the direct participant that acts as its settlement bank. The relationship between the direct participant and the indirect participant arising from this Regulation is governed by an agreement concluded between the parties. 6.4. IPS participants should connect to the CTN established for the purpose of information exchange within the systems. 6.5. The participant and intermediary should integrate their relevant internal information resources with main and auxiliary components designated for information exchange in the IPS. 6.6. The security of information exchange in the IPS is ensured as follows: 6.6.1. electronic certificates of the BCSC are used to ensure information security. In this case, data transmission channels used to protect against unauthorized external interference are encrypted, and authentication is performed based on the registration codes of participants and intermediaries. 6.6.2. The participant and intermediary verify the integrity and authenticity of the data received from the IPS using the capabilities of the public key infrastructure provided by the BCSC. Any deficiency detected regarding the electronic signature of the received data should be immediately reported to the Central Bank (in electronic or paper form). 6.6.3. Direct participants in the IPS may manage the debit limit on their IPS settlement accounts as follows: 6.6.3.1. a direct participant may establish or increase the debit limit for its IPS settlement account by sending a request (camt.050) to AZIPS in the appropriate format. In this case, the limit is set based on the specified amount without any deduction from the direct participant’s correspondent account, and the amount indicated in each request is added to the debit limit. Information on each order processed in AZIPS regarding changes to this type of debit limit in the direct participant’s correspondent account is transmitted to the IPS in real time. 6.6.3.2. a direct participant may set a debit limit for its IPS settlement account by using the relevant request format (camt.011) in the IPS. The request for debit-limit management is initially processed in the IPS. If the requested amount exceeds the direct participant’s net debit position in the IPS settlement account, the request is transferred to AZIPS in real time; if it is lower, a rejection notice (camt.025/ERRC) is sent for the participant’s debit-limit change request. The request submitted to AZIPS for debit-limit modification is processed according to the funds available in the direct participant’s correspondent account, and the result is communicated to the IPS. Depending on the outcome of processing in AZIPS, the direct participant’s debit limit is updated in the IPS, and a notification (camt.010) is sent to the participant. 6.6.3.3. a direct participant may set a debit limit for its own or for the technical account of an indirect participant for which it acts as a settlement bank by using the relevant request format (camt.011) in the IPS. The request for debit-limit management is processed in the IPS.

If the requested amount exceeds the participant’s net debit position, the request is processed in the IPS; if it is lower, a rejection notice (camt.025/ERRC) is sent regarding the debit-limit change request for the technical account. If the request is successfully processed, the debit limit for the technical account is established, and a notification (camt.010) is sent to the participant. 6.6.3.4. during the day, in accordance with the system’s operating procedure, the operations carried out on participants’ settlement accounts within the IPS are settled directly through the participants’ correspondent and current accounts in AZIPS. 6.6.3.5. if the debit limit allocated for participants’ IPS settlement accounts falls below the threshold specified in the procedure approved in accordance with Item 3.5 of this Regulation, the IPS sends a notification (camt.010) to the relevant direct participant regarding the changes that have occurred in its accounts. The IPS also ensures that a corresponding notification is sent via SMS or email to the administrator(s) previously designated by the relevant participant, while informing the Central Bank. 6.6.3.6. to obtain information on the account balance, participants send a request (camt.009) to the IPS. If there is a discrepancy, the IPS sends a rejection notice (camt.025/ERRC) to the participant; if there is no discrepancy, a response (camt.010) is sent. 6.7. Information exchange related to payment operations in the IPS is carried out through the following exchange methods: 6.7.1. A credit transfer (pacs.008) is sent to the IPS. 6.7.2. A payment request (pain.001) is sent to the IPS. 6.7.3. A payment return instruction (pacs.004) is sent to the IPS. 6.7.4. A payment return request (camt.056) is sent to the IPS. 6.8. The following is verified in data formats sent by a participant to the IPS for payment operations: 6.8.1. completion of mandatory fields in the data formats. 6.8.2. compliance of the value date with Item 3.7 of herein. 6.8.3. non-duplication of the document number. 6.8.4. accuracy of the participant BIC. 6.8.5. accuracy of accounts. 6.8.6. consistency between the participant BIC and the accounts. 6.8.7. that the payment amount does not exceed the maximum amount of a single credit transfer as defined in the procedure approved pursuant to Item 3.5 herein. 6.9. If there is a deviation from the requirements specified in Item 6.8 herein, the participant that sent the document to the IPS is notified of the rejection of processing, with the reason indicated, through the following messages: 6.9.1. Notice of rejection of execution of the credit transfer (pacs.002 STAT/RJCT). 6.9.2. Notice of rejection of execution of the payment request (camt.025/RJCT). 6.9.3. Notice of rejection of execution of the payment return instruction (pacs.002 STAT/RJCT). 6.9.4. Notice of rejection of execution of the payment refund request (camt.029). 6.10. If there is a deviation from the electronic document formats established for the system in accordance with Item 3.5 herein in other data formats sent by participants for auxiliary purposes related to IPS operations (pacs.028, pain.998, camt.033, camt.060, camt.998, camt.011, camt.009), a rejection notice (camt.025/ERRC) is sent to the participant.

6.11. If there is no deviation from the requirements specified in Item 6.8 herein, payment orders submitted by direct and indirect participants are executed as follows: 6.11.1. Execution of credit transfers (pacs.008): 6.11.1.1. The originating participant sends the credit transfer (pacs.008) to the IPS. 6.11.1.2. The IPS blocks an amount equivalent to the value of the credit transfer on the originating direct participant’s settlement account, and, if there is no deviation from the requirements specified in Item 6.8, forwards the credit transfer to the beneficiary participant for confirmation. 6.11.1.3. In cases provided for in the procedure approved in accordance with Item 3.5 herein, the beneficiary participant sends a confirmation message (pacs.002/AUTH) to the IPS if it confirms the credit transfer, or a rejection message (pacs.002/NAUT) if it does not confirm. 6.11.1.4. In cases provided for in the procedure approved in accordance with Item 3.5 herein, when the IPS receives a confirmation message from the beneficiary participant, or when the credit transfer is deemed successful, the IPS debits the originating participant’s settlement account and credits the beneficiary participant’s settlement account and sends a confirmation notice (pacs.002/STAT) to both participants. 6.11.1.5. When the IPS receives a rejection message from the beneficiary participant, or when no response is received within the time interval specified for this purpose in the procedure approved in accordance with Item 3.5 herein, the IPS cancels the block placed on the originating participant’s settlement account in the amount of the credit transfer and sends a rejection notice (pacs.002/RJCT) to both participants. 6.11.1.6. At the request of a direct participant, copies of credit transfers (pacs.008) executed in the IPS on behalf of the indirect participants operating through that direct participant are sent to the direct participant. 6.11.2. Execution of a payment request (pain.001): 6.11.2.1. The beneficiary participant sends the payment request (pain.001) to the IPS. 6.11.2.2. The IPS validates and forwards the payment request to the originating participant. 6.11.2.3. The originating participant reviews the payment request and, if there is any deviation, sends a rejection message (pain.002/NAUT) to the IPS with the reason indicated; if there is no deviation, it approves the request and sends a credit transfer (pacs.008) to the IPS. 6.11.2.4. If the IPS receives a rejection message (pain.002/NAUT) from the originating participant, it sends a rejection notice (pain.002/RJCT) to the beneficiary participant. 6.11.2.5. When the IPS receives a credit transfer (pacs.008) from the originating participant, it blocks the corresponding amount on the originating participant’s settlement account in the IPS and forwards the credit transfer (pacs.008) to the beneficiary participant. 6.11.2.6. If the originating participant fails to have sufficient funds in its settlement account, or if no response is received within the time interval specified for this purpose in the procedure approved in accordance with Item 3.5 herein, the IPS refuses to execute the transaction and sends a rejection notice (pain.002 STAT/RJCT) to both participants. 6.11.2.7. The IPS sends the payment request status (pain.002 STAT) to the beneficiary participant, and in case of a successful transaction, it sends the payment status (pacs.002/STAT) to both participants. 6.12. If there is no deviation from the requirements specified in Item 6.8 herein, operations on payment requests submitted by intermediaries are executed as follows:

6.12.1. The intermediary sends the payment request (pain.001) to the IPS. 6.12.2. The IPS validates and forwards the payment request to the originating participant. 6.12.3. The originating participant reviews the payment request and, if there is any deviation, sends a notice (pain.002/NAUT) to the IPS with the reason indicated; if there is no deviation, it approves the request and sends a credit transfer (pacs.008) to the IPS. 6.12.4. When the originating participant sends a rejection, the IPS sends a rejection notice (pain.002 STAT/RJCT) to the intermediary; when it sends confirmation, the IPS blocks an amount equal to the value of the credit transfer on the originating participant’s settlement account and forwards the credit transfer (pacs.008) to the beneficiary participant for confirmation. 6.12.5. In cases specified in the procedure approved under Item 3.5 herein, when the beneficiary participant confirms the credit transfer, it sends a confirmation message (pacs.002/AUTH) to the IPS; otherwise, it sends a rejection message (pacs.002/NAUT). 6.12.6. When the IPS receives a confirmation message from the beneficiary participant, or when the credit transfer is deemed successful, the IPS debits the originating participant’s settlement account and credits the beneficiary participant’s settlement account, sending confirmation notices (pacs.002/STAT) to both the originating and beneficiary participants, and (pain.002/STAT) to the intermediary. 6.12.7. When the IPS receives a rejection message from the beneficiary participant, or when no response is received within the time interval specified for this purpose in the procedure approved in accordance with Item 3.5 herein, the IPS cancels the block, sends rejection notices (pacs.002/RJCT) to the originating and beneficiary participants, and (pain.002/RJCT) to the intermediary. 6.13. If there is no deviation from the requirements specified in Clause 6.8 of these Rules, the operations related to instructions for payment returns sent by participants are executed as follows: 6.13.1. The beneficiary participant sends the payment return instruction (pacs.004) to the IPS. 6.13.2. The IPS blocks an amount on the beneficiary participant’s settlement account equal to the value of the credit transfer and sends the payment refund instruction (pacs.004) to the originating participant for confirmation. 6.13.3. In cases provided for in the procedure approved in accordance with Item 3.5 herein, when the originating participant confirms the payment refund instruction, it sends a confirmation message (pacs.002/AUTH) to the IPS; if it does not confirm, it sends a rejection message (pacs.002/NAUT). 6.13.4. When the IPS receives a confirmation message from the originating participant and the payment refund is successful, it debits the beneficiary’s settlement account and credits the originating participant’s settlement account, sending a confirmation notice (pacs.002/STAT) to both participants. 6.13.5. When the IPS receives a rejection message from the originating participant, or when no response is received within the time interval specified for this purpose in the procedure approved in accordance with Item 3.5 herein, the IPS cancels the block on the beneficiary participant’s settlement account in the amount of the credit transfer and sends a rejection notice (pacs.002 STAT/RJCT) to both participants.

6.13.6. Upon request of a direct participant, copies of payment return instructions (pacs.004) related to payment operations executed in the IPS on behalf of indirect participants operating through that direct participant are sent to the direct participant. 6.14. If there is no deviation from the requirements specified in Item 6.8 herein, the operations related to payment return requests (camt.056) submitted by participants are executed as follows: 6.14.1. When the payment refund process is initiated by the originating participant: 6.14.1.1. The originating participant sends the payment return request (camt.056) to the IPS. 6.14.1.2. The IPS validates the payment return request (camt.056) and forwards it to the beneficiary participant. 6.14.1.3. If the beneficiary participant confirms the payment return request, it sends the payment return instruction (pacs.004) to the IPS; otherwise, it sends a rejection notice (camt.029). 6.14.1.4. When the IPS receives confirmation (pacs.004) from the beneficiary participant, it debits the beneficiary’s IPS settlement account by the amount of the credit transfer and credits the originating participant’s IPS settlement account, and sends the payment return instruction (pacs.004) to the originating participant. 6.14.1.5. When the IPS receives a rejection (camt.029) from the beneficiary participant, it does not execute the return request and sends a rejection notice (camt.029) to the originating participant. 6.14.1.6. The IPS sends a payment status message (pacs.002/STAT) to both participants regarding the successful operation, and additionally sends a notification (camt.029) to the beneficiary participant about the status of the payment return request. 6.14.2. When the payment return request process is initiated by an intermediary: 6.14.2.1. The intermediary sends the payment return request (camt.056) to the IPS. 6.14.2.2. The IPS validates the payment return request (camt.056) and forwards it to the beneficiary participant. 6.14.2.3. If the beneficiary participant confirms the payment return request, it sends the payment return credit transfer (pacs.004) or a rejection notice (camt.029) to the IPS. 6.14.2.4. When the IPS receives confirmation from the beneficiary participant, it places a block on the beneficiary participant’s settlement account in the credit transfer amount and sends the payment return order (pacs.004) to the originating participant for confirmation. 6.14.2.5. In cases specified in the procedure approved under Item 3.5 herein, when the IPS receives confirmation (pacs.002/AUTH) from the originating participant regarding the payment return order, it executes the payment return operation and sends the relevant notifications (pacs.002/STAT; camt.029) to the participants and the intermediary. 6.14.2.6. When the IPS receives a rejection (pacs.002/NAUT) from the originating participant, or when no response is received within the time interval specified for this purpose in the procedure approved under Item 3.5 herein, the IPS cancels the block on the beneficiary participant’s IPS settlement account in the credit transfer amount and sends the relevant notifications (pacs.002/STAT; camt.029) to the participants and the intermediary. 6.15. A participant may obtain the following information and documents from the IPS: 6.15.1. By sending a request (pacs.028), a notification on the execution status of a credit transfer (pacs.002/STAT).

6.15.2. By sending a request (pain.998), a notification on the execution status of a payment request (pain.002/STAT). 6.15.3. By sending a request (camt.033), a copy of a credit transfer executed in the system (camt.034). 6.15.4. By sending a request (camt.060), an IPS settlement account statement (camt.998/TRANSREP) for any day within the period defined by the Central Bank. 6.15.5. By sending a request (camt.009), information on the balance of the IPS settlement account (camt.010). 6.15.6. By sending a request (camt.018), information regarding the current operational day (camt.019). 6.16. A participant may send information to other participants in the IPS in a free-text format (camt.998/TEXTMESSAGE) on a 24/7/365 basis. 6.17. At the end of each operational day, an account statement (camt.998/TRANSREP) is sent to the participant. 7. Settlements for payment orders submitted on paper carriers 7.1. If a technical problem arises with the use of AZIPS and LVPCSS, payment orders are submitted to the Central Bank on paper carriers. Other participants are electronically informed by the Central Bank, and the participant’s operations in AZIPS and LVPCSS are carried out on behalf of the Central Bank. 7.2. When payment orders are submitted on paper carriers, settlements are conducted in accordance with the ‘Regulation on maintaining payment operations and on payment instruments’ approved by Decision No. 12/3 of the Management Board of the Central Bank dated 13.03.2024. 8. Connection of participants and intermediaries to the systems, temporary suspension of activity, and exclusion from the systems 8.1. A person willing to join the system(s) as a participant and/or intermediary signs and submits to the Central Bank the connection protocol (Annex 1) in electronic form or on paper. After the person fulfills the requirements specified in the system(s) operating procedure in accordance with Item 3.5 herein, the Central Bank, no later than the next business day, informs other participants and intermediaries electronically or on paper about the start of their activity in the system(s). 8.2. The Central Bank temporarily suspends a participant’s or intermediary’s activity in the systems in the following cases: 8.2.1. Upon receipt of a directive from a competent public authority to suspend the participant’s operations or a decision to freeze their account. 8.2.2. Upon receipt of a request from the participant or intermediary (in electronic form or on paper) to the Central Bank due to a technical problem related to the use of the system. 8.3. Once the circumstances that led to the suspension of a participant’s or intermediary’s activity are resolved, the Central Bank immediately restores their activity in the systems and notifies them electronically or on paper.

8.4. If a participant’s or intermediary’s license is revoked, or if the participant or intermediary is declared bankrupt or liquidated, the Central Bank excludes them from the systems without prior notice. 8.5. The Central Bank immediately informs other participants and intermediaries electronically or on paper about participants or intermediaries who have been excluded or have requested termination of their participation in the system. 8.6. In the cases specified in Item 8.4 herein, future-dated or pending payments of the participant in the system are canceled from the moment the participant is excluded from the system or their participation is terminated.

Annex 1 to the ‘Regulation on maintenance of settlements between payment service providers’ Protocol on joining the payment systems operated by the Central Bank of the Republic of Azerbaijan Date: __________________ The undersigned _____________________________________________________________ (Name of the institution) by signing this protocol, provides a written commitment that the institution will operate in accordance with the ‘Regulation on maintenance of settlements between payment service providers’, as well as the technical requirements and regulatory (procedural) documents of the respective payment system. The name of the system:

1. AZIPS - The Real Time Gross Settlement System (Direct participant □)
2. LVPCSS - The Low Value Payments Clearing and Settlement System (Direct participant □)
3. IPS – The Instant Payments System – (Direct participant □ Indirect participant □ Intermediary □) The authorized representative of the institution:

---

(Last, first names)

---

(position) Seal