‘Approved
The Central Bank of the Republic of Azerbaijan

Resolution № 33/1
18 July 2016

Regulations on organization of settlements in interbank centralized payment systems in the Republic of Azerbaijan

1. General provisions

These Regulations have been developed in accordance with Articles 44 and 45 of the Law of the Republic of Azerbaijan on the Central Bank of the Republic of Azerbaijan and govern rules for conducting settlements between participants of interbank centralized payment systems in the Republic of Azerbaijan – the Large-value Payment System (hereinafter – AZIPS), the Low Value Payments Clearing and Settlement System (hereinafter – LVPCSS) and the Instant Payment System (hereinafter – IPS).

2. Definitions

2.1. The definitions used herein bear the following meanings:
2.1.1. participant – a bank that conducts payment transactions in the AZIPS, the LVPCSS and the IPS (hereinafter collectively – systems), another legal entity whose bank accounts are serviced by the Central Bank of the Republic of Azerbaijan (hereinafter – the Central Bank) and a legal entity participating in IPS transactions by means of providing liquidity via the bank integrated to the AZIPS;
2.1.1-1. provision of liquidity – placing funds required for fulfillment of settlement obligations between IPS participants to a clearing account;
2.1.2. issuer participant – a payer of funds;
2.1.3. beneficiary participant – a recipient of funds;
2.1.3-1. direct participant – a participant integrated to the IPS that provides liquidity to the clearing account itself;
2.1.3-2. indirect participant - a participant integrated to the IPS, that provides liquidity to the clearing account via any bank that is the AZIPS member (hereinafter – the settlement bank);
2.1.3-3. intermediary - a legal entity that mediates sending of payment requests to the system on the accounts of customers of direct and indirect participants in the IPS;
2.1.4. value date – date of execution of a payment instruction on participant’s account;
2.1.5. bank identification code (BIC) - unique identification number issued by the Society for Worldwide Interbank Financial Telecommunication (SWIFT) or the Central Bank to members;
2.1.6. priority code – number identified by a payment instruction sender and used to manage the order of priority on payment instruction processing.
2.1.7. payment instruction – payment instruction or direct debit respectively issued by issuer and beneficiary participants to conduct payment transactions in systems;
2.1.8. batches – payment instructions grouped by participants at the LVPCSS;
2.1.9. payment file – specific format file created on the basis of one or several batches and used to share payment instructions among LVPCSS participants;
2.1.10. message type (hereinafter - MT) – format of electronic payment instructions, reports, inquiries and notifications in interbank centralized payment systems;
2.1.10-1. account used in the IPS to conduct transactions in the amount of funds with the same number as the direct participant’s correspondent account opened with the AZIPS and blocked in this account;
2.1.11. clearing account – account opened with the LVPCSS and the IPS for a participant;
2.1.12. net position – difference between total funds credited to a clearing account and total funds debited from a clearing account;
2.1.13. debit limit – size of funds blocked in a participant’s correspondent account with the AZIPS to conduct settlements on net debit position as a result of a clearing session;
2.1.14. clearing – transformation of claims and liabilities emerging on amounts one or several participants give to or receive from another or several participants to one net claim or one net liability that is their difference during a clearing session in LVPCSS;
2.1.15. clearing session – period of acceptance and execution of participants’ batches, and calculation of their net positions on settlements on the basis of a set procedural regulations at LVPCSS during a day;
2.1.16. mandate – agreement registered with the LVPCSS to conduct direct debit based transactions between beneficiary and issuer participants;
2.1.17. real time mode – mode implying immediate conduction of settlements and relevant data sharing on payment transactions in systems within the regulations of the relevant system;
2.1.17-1. 24/7/365 regime - a mode of operation in which settlements and data sharing on payment transactions in the systems are carried out in real time any time of the day, including non-working days defined by the legislation;
2.1.18. main center – the building where host servers of the systems are located;
2.1.19. backup center – the building where backup servers of the systems are located;
2.1.20. emergency cases – geologic, natural fires, meteorological explosions, fires, collapse of buildings and devices, problems in electro-energetic systems and other type natural and techno genic disasters;
2.1.21. systemically important participant – the participant that has over 2% (two) share in total value of transactions conducted by participants over one year in the AZIPS.

3. Execution of payment instructions

3.1. Settlements between participants in the systems are conducted through correspondent, current and clearing accounts opened with the Central Bank.
3.2. Payment instructions are accepted and executed in the systems when:
3.2.1. the payment instruction meets the requirements of the Guidelines on Cashless Settlements and Money Remittances in the Republic of Azerbaijan approved by Resolution# 19/1 of the Management Board of the Central Bank dated 17.09.2013;
3.2.2. there is no decision (order) on seizure of accounts of issuer and beneficiary participants or suspension of transactions;
3.2.3. payment instruction’s value date conforms to the timeframe set in Items 3.7 and 3.8 herein;
3.2.4. sufficient funds are available in issuer’s account to execute a payment instruction.
3.3. A participant’s payment instruction is considered irrevocable from the moment funds are written off from its account.
3.4. A statement or other data from a participant’s relevant account are delivered to it by the Central Bank in soft- or hardcopy.
3.5. Data formats used in the systems, as well as their operating procedural regulations are approved by the Management Board of the Central Bank. The procedural regulations determine time intervals on sending, acceptance and processing of payment instructions, queries, notices and data over a transaction day, the procedure for temporary suspension of systems’ operating time, as well as the number of clearing sessions in the LVPCSS per day, the number of regulations with the AZIPS on the balance of the clearing account in the IPS and maximum amount of one accepted payment instruction in the LVPCSS and the IPS. The operating procedural regulations of the IPS also determine rules on organization of operation of participants and intermediaries, including their rights and duties, time limits set on operations, as well as dispute resolution on operations conducted in the system.
3.6. In the event of any changes to the procedural regulations, the Central Bank sends a relevant notification to participants in soft- or hardcopy at least 3 (three) days prior to the day the changes have been introduced.
3.7. The payment instruction, whose value date coincides with the transaction day, sent in the systems by a participant is accepted and processed the same day by the Central Bank on the basis of the procedural regulations established on the relevant payment system.
3.8. A participant in the AZIPS or the LVPCSS may send a payment instruction to systems not more than 10 (ten) calendar days prior to the value date. In this case, information on the payment instruction is kept by the systems respectively and executed on the value date.

4. Settlements in the AZIPS

4.1. The AZIPS is used for settlements among participants in real time mode on the basis of the procedural regulations approved in accordance with Item 3.5 herein.
4.2. Settlements in the AZIPS are done via participants’ correspondent and current accounts.
4.3. Settlements in AZIPS may be conducted using the following data sharing facilities:
4.3.1. Closed Telecommunications Network (hereinafter – CTN) created for information sharing in the systems;
4.3.2. SWIFT (if a participant is a SWIFT member).
4.4. A participant may use the CTN or SWIFT platform for information sharing with the AZIPS upon notifying the Central Bank (in soft- or hardcopy).
4.5. To conduct transactions via CTN in AZIPS, a participant should be connected to a dedicated telecommunication network launched for data sharing in payment systems.
4.6. To conduct transactions via CTN in AZIPS, a participant should install a ‘STPAdapter’ module introduced by the Central Bank in relevant servers taking into consideration technical and system requirements of software.
4.7. A participant may send the following payment instructions to AZIPS via CTN or SWIFT in the following SWIFT message formats:
4.7.1. customer payments (MT102, MT103):
4.7.2. bank payments (MT205).
4.8. The following is verified when a payment instruction is accepted in AZIPS for execution:
4.8.1. compliance of the value date with Items 3.7 and 3.8 herein;
4.8.2. no recurrence of the payment instruction’s number over a transaction day;
4.8.3. compliance of a payment instruction with electronic payment instructions format established across AZIPS;
4.8.4. accuracy of participant BICs;
4.8.4-1. accuracy of participant TIN;
4.8.5. accuracy of correspondent (current) accounts;
4.8.6. compliance of participant BIC, TIN and correspondent (current) account.
4.9. In case of discrepancy from the requirements established in Item 4.8 herein or termination of operations of any or both of the participants, a payment instruction is rejected by AZIPS and a notice is sent to the participant indicating the reason for rejection (MT298/SMT900 or MT298/SMT701 respectively).
4.10. In case of non-discrepancy from the requirements established in Item 4.8 herein:
4.10.1. AZIPS debits issuer participant’s and credits beneficiary participant’s accounts;
4.10.2. AZIPS sends a payment instruction to a beneficiary participant, and a notice on payment execution to an issuer participant (MT298/SMT012), if required.
4.11. To manage payment’s order of priority, the issuer participant should indicate payment instructions’ priority codes in their headings. The priority code is set from 30 to 99.
4.12. A payment order sent by an issuer participant with the value date as of the current date, shall be stored by AZIPS in ‘Standby Mode’ without execution when:
4.12.1. there is a decision (order) on seizure of accounts of issuer and beneficiary participants or suspension of their transactions;
4.12.2. there are insufficient funds in the issuer participant’s account;
4.12.3. operation of AZIPS is suspended temporarily.
4.13. In the event of the cases specified in Item 4.12 herein, AZIPS delivers a notice (MT298 /SMT700) to an issuer participant stating the reason.
4.14. The issuer participant may change the pending payment instruction’s priority code, sending a request (MT298/SMT202) to AZIPS.
4.15. In the event the priority number cannot be changed for whatever reason, AZIPS sends a notice to the participant (MT298/SMT252) stating the reason.
4.16. The issuer participant may reject a pending payment instruction sending a query (MT298/SMT200) to AZIPS. In this case, the issuer participant sends a notice to AZIPS.
4.17. In the event a payment instruction cannot be annulled for whatever reason, AZIPS sends a notice (MT298/SMT250) to the participant stating the reason.
4.18. In the event of insufficient funds for settlements on the participant’s account, the pending, non-executed payment instruction with the value date as of the current date is annulled at the end of the transaction day and a notice is sent to the participant (MT298/SMT701).
4.19. AZIPS sends a notice to participants on transactions conducted in their accounts (MT900 in case of debiting, MT910 in case of crediting) within the authorities issued by other participants in the system.
4.20. Sending a query (MT920) to AZIPS the participant may obtain general (MT941) and interim information (MT942) on its account in a real time mode over a transaction day.
4.21. Sending a query (MT298/SMT800) to AZIPS the participant may obtain information on payment instructions incoming to and written off from the account, as well as payment instructions to be written off (MT298/SMT850) over a transaction day.
4.22. Sending a query to AZIPS (MT298/SMT801) the participant may obtain real time general information (MT298/SMT851) on pending payment instructions, and the status of correspondent or current accounts over a transaction day.
4.23. Sending a query to AZIPS (MT298/SMT804) the participant may obtain detailed information on pending payment instruction (MT298/SMT854) over a transaction day.
4.24. In case of improper filling of queries by the participant, AZIPS sends a relevant notice (MT298/SMT900) to the participant.
4.25. AZIPS sends a statement from the account (MT950) at the end-transaction day.
4.26. Information sharing security in AZIPS is maintained as follows:
4.26.1. if SWIFT is used for information sharing, information security is maintained on the basis of regulations established by this telecommunications network;
4.26.2. if CTN is used for information sharing, electronic certificates of the Central Bank’s Bank Certificate Services Center (BCSC) are used to maintain information security. In this case to be protected from unauthorized external interventions, data transmission channels in use are encrypted and authenticated across participants’ registration codes.
4.26.3. The participant verifies integrity and accuracy of data received from AZIPS via CTN using options of electronic signature facilities issued by the BCSC. The Central Bank is immediately notified (in soft- and hardcopy) on any shortfalls revealed with respect to electronic signatures of accepted data.
4.27. In the event of technical problems with respect to use of AZIPS the Central Bank should be notified (in soft- and hardcopy). In this case based upon the participant’s appeal it participates in AZIPS via a dedicated workstation at the Central Bank. If the participant informs the Central Bank accordingly (in soft- and hardcopy) upon troubleshooting, its operation in the system is restored immediately.

5. Settlements in the Low Value Payments Clearing and Settlement System (LVPCSS)

5.1. The LVPCSS is used for collection and clearing of batches sent by participants based upon the procedural regulations approved in accordance with Item 3.5 herein and conduct settlements in AZIPS on derived net positions.
5.2. A LVPCSS participant should be connected to CTN launched for information sharing in interbank centralized payment systems.
5.3. A LVPCSS participant, depending on the information sharing scheme it chooses, should install one of the ‘STP-Adapter’ or ‘Payment gateway’ modules introduced by the Central Bank in one of its relevant server equipment in view of technical and system requirements of the software.
5.4. Information sharing security in the LVPCSS is maintained in the following order:
5.4.1. BCSC’s electronic certificates are used to maintain information security. In this case to be protected from unauthorized external interventions, data transmission channels in use are encrypted and authenticated across participants’ registration codes;
5.4.2. The participant verifies integrity and accuracy of data received from LVPCSS using options of open key infrastructure issued by the BCSC. The Central Bank is immediately notified (in soft- and hardcopy) on any shortfalls revealed with respect to electronic signatures of accepted data.
5.5. In the event of technical malfunction with respect to use of LVPCSS a participant should notify the Central Bank (in soft- and hardcopy). In this case based upon the participant’s appeal it participates in LVPCSS via a dedicated workstation at the Central Bank. If the participant informs the Central Bank accordingly (in soft- and hardcopy) upon troubleshooting, its operation in the system is restored immediately
5.6. Settlements in LVPCSS are provided through participants’ clearing accounts.
5.7. Settlements in LVPCSS are conducted on the basis of payment files (MT150) sent by participants. Payment files may include two types of batches:
5.7.1. batches, that include payment instructions (MT102);
5.7.2. batches, that include direct debits (MT104);
5.8. Batches included to payment files sent to the LVPCSS are executed in the first in first out order.
5.9. LVPCSS participants may manage debit limits on their clearing accounts as follows:
5.9.1. Participants may set debit limit for the clearing account sending a relevant format bank payment (MT205) in the AZIPS. In this case a limit is set on the basis of indicated amount without any write offs from participant’s correspondent account and any amount, implied on the basis of every bank payment sent, is added to clearing account’s debit limit. Real time information is delivered to the LVPCSS per order processed on changes made to participant’s clearing account’s debit limit in the AZIPS.
5.9.2. Participants may set debit limits for clearing accounts using a relevant format query (MT999) in LVPCSS. A query on debit limit management is initially processed in LVPCSS. If the query is meant for initial setting of a debit limit, or ordered amount is larger than the participant’s current debit limit, the query is transmitted to AZIPS in real time mode. If the amount ordered in the query is implied to decrease the current debit limit, when the current position of participant’s clearing account falls behind the newly set debit limit, a relevant notice is transmitted to AZIPS. Otherwise, a rejection notice (MT996) is sent to participant’s query to decrease debit limit. A query received by AZIPS on changing debit limit is processed in accordance with the size of funds in the participant’s correspondent account and resulting information is transmitted to LVPCSS. If the amount ordered in the query meets the requirements in this Item, clearing account’s debit limit is set equal to that amount. Depending on the result of query processing in AZIPS, the participant is sent a notice (MT996) on debit limit changes.
5.10. A participant can create a batch by using LVPCSS’s Payment Gateway workstation or via internal General Ledger.
5.11. A participant may create and send to LVPCSS a payment file on the basis of batches in the following order:
5.11.1. a batch is created from batches developed in the ‘Payment Gateway’ and sent to the LVPCSS;
5.11.2. batches created in General Ledger are transmitted to the ‘Payment Gateway’ and a payment file is created on their basis and sent to the LVPCSS;
5.11.3. A payment file created in General Ledger is transmitted to the Payment Gateway and sent to the LVPCSS;
5.11.4. A payment file created in General Ledger is sent to LVPCSS using ‘STPAdapter’.
5.12. Direct debit based settlements may be conducted in LVPCSS in a mandated and unmandated order. Unmandated direct debit based settlements in their turn may be conducted in clearing sessions or in a real-time mode.
5.13. To make mandated payments a beneficiary participant sends a query (MT998) to LVPCSS on the basis of funds recipient’s order for the registration of the query. After initial verification of compliance with the formats established by the Central Bank under Item 3.5 herein on the entered mandate, an issuer participant receives a relevant notice (MT998). The mandate takes effect only upon confirmation (MT995) by the issuer participant.
5.14. Batches, that include mandated direct debits (MT104), are prepared by the beneficiary bank and sent to LVPCSS within the payment file (MT150). Every direct debit includes a unique number of the mandate it is referred to. In LVPCSS direct debit’s requisites are reconciled with total amount, maximum amount per payment instruction, and the number of payments to be made set with the relevant mandate and only in case of compliance is accepted for processing. Otherwise, a beneficiary participant receives a rejection notice (MT196).
5.15. To make unmandated payments a beneficiary participant prepares batches (MT104) that include direct debits and sends in the payment file (MT150) to the LVPCSS.
5.16. Batches (MT104) are prepared on the basis of direct debits received and accepted for processing by LVPCSS and sent to issuer participant in payment file (MT150).
5.17. Participants may work on direct debits in LVPCSS in a statutory authorization or authorization-free manner. Initially a statutory authorization regime is established for all system participants. Every participant may appeal to the Central Bank (in soft- and hardcopy) and establish and change the authorization mode.
5.18. If an issuer participant, that operates in a statutory authorization mode, wants to reject execution of tasks included to a batch comprising direct debits received from LVPCSS a relevant notice (MT198) should be sent to the system. The batch, that includes at least one direct debit to be executed, is authorized by the issuer participant and a notice (MT195) is sent to LVPCSS.
5.19. If no authorization notice is received on batches, that include direct debits, sent to the issuer participant, operating in a statutory authorization mode by the final clearing session of the transaction day, the system rejects execution of those batches and a relevant notice (MT198) is sent to the beneficiary participant.
5.20. If a rejection notice (MT198) to a batch or direct debits in the batch sent to LVPCSS from the issuer participant that works in statutory authorization free mode is not sent during a session, the system includes them to the following session’s clearing process. If the issuer participant does not reject execution of batches sent to LVPCSS during the last clearing session, these batches are included to the clearing process of that session.
5.21. Every batch on unmandated direct debits may include only one payment instruction in real time mode. Irrespective the issuer participant’s work regime, confirmation is required for execution of these batches. The system automatically rejects execution of batches not confirmed by the issuer participant until the last session of the transaction day.
5.22. Unmandated direct debit approved by the issuer participant in real time is immediately transmitted to AZIPS and processed in case of availability of required funds in participant’s correspondent (current) account disregarding the debt limit set for the clearing account.
5.23. The LVPCSS immediately sends a notice (MT198) to issuer and beneficiary participants on the status of unmandated batch whose processing has finalized in real time.
5.24. Accepting the payment file by the participant for execution the LVPCSS verifies:
5.24.1. whether mandatory fields of the payment file and batches are filled in;
5.24.2. compliance of the value date of the batch with Items 3.7 and 3.8 herein;
5.24.3. recurrence of the batch number;
5.24.4. compliance of the batch with the format of electronic payment instructions established by the Central Bank;
5.24.5. accuracy of the participant BIC;
5.24.6. accuracy of clearing accounts;
5.24.7. accuracy of correspondent accounts;
5.24.8. compliance of the participant BIC and correspondent account;
5.24.9. whether the amount per payment instruction in batches exceed the maximum amount for one payment instruction set in the LVPCSS.
5.25. In the event of discrepancy from the requirements in Item 5.24 herein the following information is sent to the issuer participant stating the reasons:
5.25.1. notice (MT896) on rejection to execute the payment file;
5.25.2. notice (MT196) on rejection to execute the batch;
5.25.3. notice (MT158) on rejection to execute the payment document.
5.26. In the event of absence of discrepancies in the payment file the LVPCSS sends a notice (MT896, MT196) to the participant on acceptance of the payment file and batches included there for execution.
5.27. Sending a query to the LVPCSS (MT920) a participant may obtain general information (MT941) on total amount of debit and credit transactions on the clearing account and outstanding amount.
5.28. Sending a query (MT195) to LVPCSS the participant may obtain the following information:
5.28.1. notice (MT896) on the status of the payment file;
5.28.2. notice (MT196) on the status of batch or payment document included therein;
5.28.3. copy of the payment file (MT156);
5.28.4. copy of the batch or the payment document included therein (MT196).
5.29. Sending a query (MT198) to the LVPCSS a participant may obtain information (MT198) on the status and copy of several payment documents included to the batch.
5.30. Payment operations in the LVPCSS are based upon clearing sessions. Clearing sessions are divided into the following periods:
5.30.1. document sharing;
5.30.2. pre-clearing;
5.30.3. clearing;
5.30.4. approval of clearing results;
5.30.5. clearing results;
5.30.6. clearing reporting.
5.31. The LVPCSS sends a notice (MT999) to participants on commencement of clearing session periods on the basis of LVPCSS procedural regulations.
5.32. From the moment the document sharing starts, a participant may send queries to the LVPCSS to obtain payment files, as well as other queries with respect to setting debit limits, queries on deletion of payment files, batches and payment instructions and various reports and notices related to the system operation.
5.33. During exchange of documents, a notice (MT196) is sent to the participant on results of initial processing and status of each batch in payment files sent by the participant to LVPCSS.
5.34. In pre-clearing the LVPCSS calculates initial net position on each participant’s clearing account, a notice (MT986) is sent to it on executed and non-executed payment instructions, and amount that falls short to execute payment instructions. In this phase, the participant is allowed to increase clearing account’s debit limit.
5.35. A relevant notice (MT196) is sent if in pre-clearing the status of batches is pending due to funds shortfall in participant’s clearing account.
5.36. In the clearing period, participants’ net positions on clearing accounts are estimated in the current clearing session.
5.37. During clearing results approval, a batch of participants’ net positions on clearing accounts (MT971) are sent to AZIPS for final settlements. The following reports and notices are sent to participants after final settlements on clearing results are finalized in AZIPS:
5.37.1. report on payments executed in the current clearing session (MT970);
5.37.2. report (MT971) on clearing account’s net position in current clearing session;
5.37.3. report on total amount of debit and credit operations on clearing account in the current clearing session (MT986);
5.37.4. notice on the current status of batches (MT196).
5.38. In the clearing results phase payment files (MT150) are sent to participants.
5.39. In clearing reporting phase participants receive a final statistic report (MT986).
5.40. In the current clearing session in the LVPCSS unexecuted batches whose value date is as of that day are translated to the following clearing session of that day. If no following clearing session is implied, unexecuted batches are annulled. In that case, the LVPCSS sends a notice to the participant (MT196).
5.41. At the end of the transaction day in the LVPCSS a statement from the clearing account is sent to the participant (MT950).
5.42. Notices on transactions conducted in the LVPCSS and queries are sent to participants in real time mode.
5-1. Settlements in the IPS
5-1.1. The IPS is used to maintain 24/7/365 settlements between participants under the procedural regulations approved in accordance with Item 3.5 herein.
5-1.2. Settlements in the IPS are conducted through IPS settlement accounts of direct participants and participants’ clearing accounts.
5-1.3. Clearing accounts of a direct participant and indirect participants, of which it is a settlement bank, are linked to its IPS settlement account. Relations between direct and indirect participants arising from these Regulations are governed by the agreement concluded between them.
5-1.4. IPS participants should be integrated to the CTN created for data sharing in the systems.
5-1.5. The participant should accordingly integrate relevant internal information resources with main and supplementary components of the IPS allowed for information sharing.
5-1.6. Information security in the IPS is provided as follows:
5-1.6.1. electronic certificates of the BCSC are used to maintain information security. In this case, to protect from unauthorized external interventions data transmission channels in use are encrypted and authenticated across participants’ registration codes;
5-1.6.2. The participant verifies integrity and accuracy of data received from the IPS using open key infrastructure options presented by the BCSC. The Central Bank is immediately notified (in soft- and hardcopy) on any shortfalls revealed with respect to electronic signatures of accepted data.
5-1.7. Participants in the IPS may manage their debit limits on clearing accounts as follows:
5-1.7.1. a direct participant may initially set and increase a debit limit for IPS settlement account by sending a relevant query (MT205) to AZIPS. In this case, a limit on the indicated amount is set without write-off from the participant’s correspondent account and the amount implied on every query sent is added to the debit limit. Information is transferred to the IPS on a real time mode on every order processed on similar changes to the debit limit in the participant’s correspondent account in AZIPS;
5-1.7.2. a direct participant may set a debit limit for the IPS settlement account using a relevant query (camt.011) in the IPS. A query on managing the debit limit is initially processed in the IPS. If the amount ordered in the query is more than the net debit position of the direct participant’s IPS settlement account, the query is transferred to AZIPS on a real time mode, and if less, a rejection notice (camt.025/ERRC) is sent to direct participant’s query to change a debit limit. The query received by the AZIPS on the change to the debit limit is processed in line with the amount of funds in the participant’s correspondent account and information is transferred to the IPS on the result. Depending on the result of processing of the query in AZIPS, the direct participant’s debit limit is changed in the IPS and a direct participant is notified accordingly (camt.010);
5-1.7.3. a direct participant may set a debit limit for the clearing account of itself or an indirect participant, of which it is a settlement bank, using a relevant query (camt.011) in the IPS. A query on managing the debit limit is processed in the IPS. If the amount ordered in the query is more than the net debit position, it is processed in the IPS, and if less, a rejection notice (camt.025/ERRC) is sent to direct participant’s query to change a debit limit on the clearing account. As a result of successful processing of the query the clearing account’s debit limit is set and a relevant notice is sent to the participant(camt.010);
5-1.7.4. adjustments are made with direct participants’ correspondent and current accounts with AZIPS on transactions conducted in participants’ clearing accounts in the IPS over the day under the operation procedural regulations of the system;
5-1.7.5. if the debit limit allocated on participants’ clearing accounts is less than the threshold set in the procedural regulations approved in accordance with Item 3.5 herein, the IPS sends a notice (camt.010) to related direct participant on changes to their clearing accounts;
5-1.7.6. participants send a query (camt.009) to the IPS to get information on the balance in their clearing accounts, the IPS sends a rejection notice (camt.025/ERRC) in case of discrepancy, and a response (camt.010) in case of no discrepancy.
5-1.8. Information sharing on payment transactions in the IPS is provided as follows:
5-1.8.1. payment order (pacs.008) is sent to the IPS;
5-1.8.2. payment request (pain.001) is sent to the IPS;
5-1.8.3. payment refund order (pacs.004) is sent to the IPS;
5-1.8.4. payment refund request (camt.056) is sent to the IPS.
5-1.9. The following is verified in data formats sent by the participant to the IPS on payment transactions:
5-1.9.1. whether mandatory fields are filled out in data formats;
5-1.9.2. whether the value date is compliant with Item 3.7 herein;
5-1.9.3. non-recurrence of the document number;
5-1.9.4. compliance of the document with the formats of electronic payment documents established in the IPS in accordance with Item 3.5 herein;
5-1.9.5. accuracy of the participant BIC;
5-1.9.6. accuracy of clearing accounts;
5-1.9.7. accuracy of correspondent accounts;
5-1.9.8. compliance of the participant BIC and correspondent accounts;
5-1.9.9. whether the payment amount exceeds the maximum amount for one payment instruction set in the IPS.
5-1.10. In case of discrepancies from the requirements established in Item 5-1.9 herein, the following notices are sent to the participant whose document is sent to the IPS substantiating the rejection on processing:
5-1.10.1. a notice on rejection of execution of the payment instruction (pacs.002/RJCT);
5-1.10.2. a notice on rejection of execution of the payment request (camt.025/RJCT);
5-1.10.3. a notice on rejection of execution of the payment refund instruction (pacs.002/RJCT);
5-1.10.4. a notice on rejection of execution of the payment refund request (camt.029).
5-1.11. In case of discrepancies in other information formats (pacs.028, pain.998, camt.033, camt.060, camt.998, camt.011) sent by participants for supplementary purposes for organization of activities in the IPS from the electronic document formats established on the system in accordance with Item 3.5 herein, the participant is sent a notice of rejection of processing (camt.025 / ERRC).
5-1.12. In case of no discrepancy from the requirements as per Item 5-1.9 herein, transactions on documents sent by direct and indirect participants are executed as follows:
5-1.12.1. on execution of payment instructions (pacs.008):
5-1.12.1.1. the issuer participant sends a payment instruction (pacs.008) to the IPS;
5-1.12.1.2. the IPS blocks the participant's clearing account up to the amount of funds in the payment instruction and sends the payment instruction to the beneficiary participant for approval;
5-1.12.1.3. the beneficiary participant sends a confirmation notice (pacs.002 / AUTH) to the IPS if the participant confirms the payment instruction, and a rejection notice (pacs.002 / NAUT) if it does not confirm;
5-1.12.1.4. when the IPS receives a confirmation notice from the beneficiary participant, it debits the issuer's clearing account, credits the beneficiary's clearing account and sends a confirmation notice (pacs.002 / STAT) to both participants;
5-1.12.1.5. if the IPS receives a rejection notice from the beneficiary participant or does not receive a response within the timeframe specified for this purpose in the procedural regulations approved in accordance with Item 3.5 herein, it cancels the blocking in the amount of the payment instruction in the issuer participant's clearing account and sends a rejection notice to both participants (pacs.002/RJCT);
5-1.12.1.6. at the request of the direct participant, a copy of payment orders of indirect participants operating in the systems through it executed in the IPS (pacs.008) may be sent directly to the participant.
5-1.12.2. on execution of the payment request (pain.001):
5-1.12.2.1. beneficiary participant sends a payment request (pain.001) to the IPS;
5-1.12.2.2. the IPS verifies and sends to the participant the payment request;
5-1.12.2.3. the issuer participant verifies the payment request, in case of discrepancy, sends a rejection notice (pain.002/NAUT) indicating reasons, in case of no discrepancy, gives consent and sends a payment instruction (pacs.008) to the IPS;
5-1.12.2.4. when the IPS receives confirmation (pacs.008) from the issuer participant, it debits the issuer's clearing account up to the amount of funds in the payment order, credits the beneficiary's clearing account and sends the payment order (pacs.008) to the beneficiary participant;
5-1.12.2.5. when the IPS receives a rejection notice (pain.002/NAUT) from the issuer participant, if the issuer participant does not have sufficient funds in the clearing account or does not receive a response within the time period specified for this purpose in the procedural regulations approved in accordance with Item 3.5 herein, it refuses to perform the transaction and notifies the beneficiary participant or sends a rejection notice (pain.002/RJCT) to both participants;
5-1.12.2.6. the IPS sends a payment status to both (pacs.002/STAT) on successful transaction.
5-1.13. In case of no discrepancy from the requirements of Item 5-1.9 herein, transactions on payment requests sent by intermediaries are executed in the following order:
5-1.13.1. an intermediary sends a payment request (pain.001) to the IPS;
5-1.13.2. the IPS verifies the payment request and sends it to the issuer participant;
5-1.13.3. the issuer participant verifies the payment request, in case of discrepancy sends a notice (pain.002/NAUT) to the IPS indicating the reason, in case of no discrepancy, gives consent and sends a payment instruction (pacs.008) to the IPS;
5-1.13.4. if the issuing participant refuses, the IPS sends a rejection notice (pain.002/NAUT) to the intermediary, and when sending the confirmation, the issuer blocks the participant's clearing account up to the amount of the payment instruction and sends the payment instruction (pacs.008) to the beneficiary participant for approval;
5-1.13.5. if the beneficiary participant confirms the payment instruction, it sends a confirmation notice (pacs.002/AUTH), otherwise a rejection notice (pacs.002/NAUT) to the IPS;
5-1.13.6. the IPS debits issuer's clearing account, credits beneficiary's clearing account, and sends a confirmation notice to issuer and beneficiary participants (pacs.002/STAT) and the intermediary (pain.002/STAT) upon receiving beneficiary participant’s confirmation notice;
5-1.13.7. when the IPS receives a rejection notice from the beneficiary participant or does not receive a response within the time period specified for this purpose in the procedural regulations approved in accordance with Item 3.5 herein, it cancels the blocking in issuer participant’s clearing amount up to the amount of the payment instruction, sends a rejection notice (pacs.002/RJCT) to the issuer participant and (pain.002/RJCT) to the intermediary.
5-1.14. In case of no discrepancy from the requirements set forth in Item 5-1.9 herein, operations on payment refund instructions sent by participants are performed in the following order:
5-1.14.1. the beneficiary participant sends payment refund instruction (pacs.004) to the IPS;
5-1.14.2. the IPS blocks the beneficiary participant's clearing account up to the amount of funds in the payment instruction and sends the payment refund instruction (pacs.004) to the issuing participant for approval;
5-1.14.3. the issuer sends a confirmation notice (pacs.002/AUTH) if the participant confirms the refund instruction, and a refusal notice (pacs.002/NAUT) if it does not confirm to the IPS;
5-1.14.4. when the issuer receives a confirmation notice from the issuer, it debits the beneficiary's clearing account, credits the issuer's clearing account and sends a confirmation notice (pacs.002/STAT) to both participants;
5-1.14.5. if the issuer receives a rejection notice from the issuer participant or does not receive a response within the timeframe specified for this purpose in the procedural regulations approved in accordance with Item 3.5 herein, it cancels blocking in the payment order amount in the beneficiary participant’s clearing account and sends a rejection notice to both participants (pacs.002/RJCT);
5-1.14.6. If requested by the direct participant, a copy of the refund order (pacs.004) of indirect participants operating in the system through the IPS is sent directly to the participant.
5-1.15. In case of no discrepancy from the requirements set in Item 5-1.9 herein, operations on the payment refund request sent by participants (camt.056) is executed as follows:
5-1.15.1. if the process on the refund request is initiated by the issuer participant:
5-1.15.1.1. the issuer participant sends a refund request (camt.056) to the IPS;
5-1.15.1.2. the IPS verifies refund request (camt.056) and sends it to beneficiary participant;
5-1.15.1.3. if the beneficiary participant confirms the refund request, it sends a refund instruction (pacs.004), otherwise a rejection notice (camt.029) to the IPS;
5-1.15.1.4. when the IPS receives confirmation (pacs.004) from the beneficiary participant, it debits the beneficiary participant's clearing account up to the amount of funds in the payment order, credits the issuer's clearing account and sends the refund order (pacs.004) to the issuer;
5-1.15.1.5. when the IPS receives rejection from the beneficiary participant (camt.029), it does not execute cancellation and the issuer sends a rejection notice (camt.029) to the participant;
5-1.15.1.6. if the beneficiary participant does not have sufficient funds in the account, the IPS does not execute the cancellation and sends a rejection notice (pacs.002/RJCT) to it;
5-1.15.1.7. The IPS sends a payment status (pacs.002/STAT) information to both participants on a successful operation.
5-1.15.2. if the process on the refund request is initiated by the intermediary:
5-1.15.2.1. the intermediary sends a refund request (camt.056) to the IPS;
5-1.15.2.2. IPS verifies and sends to the beneficiary participant the refund request (camt.056);
5-1.15.2.3. if the beneficiary participant confirms the refund request, it sends a refund instruction (pacs.004), otherwise a rejection notice (camt.029) to the IPS;
5-1.15.2.4. if the IPS receives confirmation from the beneficiary participant, it blocks the amount of funds in the payment instruction in its clearing account and sends the refund order (pacs.004) to the issuing participant for confirmation;
5-1.15.2.5. when the issuer receives confirmation from the issuing participant on the refund order (pacs.002/AUTH), it executes the refund operation and sends a confirmation notice (pacs.002/STAT) to all three participants in the process.
5-1.16. If the issuer receives rejection from the issuing participant (pacs.002/NAUT) or does not receive a response within the timeframe specified for this purpose in the procedural regulations approved in accordance with Item 3.5 herein, it cancels the blocking in the amount of payment order on the beneficiary participant's clearing account, sends a rejection notice (pacs.002/RJCT) to all three participants.
5-1.17. The participant may get the following information and documents from the IPS:
5-1.17.1. a notice (pacs.002/STAT) on the status of execution of the payment instruction by sending a query (pacs.028);
5-1.17.2. a notice (pacs.002/STAT) on the status of execution of the payment request by sending a query (pain.998);
5-1.17.3. a copy of the payment instruction (camt.034) executed in the system by sending a query (camt.033);
5-1.17.4. a statement from the clearing account (camt.998/TRANSREP) for any day within the timeframe set by the Central Bank by sending a query (camt.060);
5-1.17.5. information on the balance in the clearing account (camt.010) by sending a query (camt.009);
5-1.17.6. information on the current operating day (camt.019) by sending a query (camt.018).
5-1.18. The participant can send 24/7/365 information to other participants in the IPS using a free text format (camt.998/TEXTMESSAGE).
5-1.19. A statement from the clearing account (camt.998/TRANSREP) is sent to the participant at the end of every operating day in the IPS.

6. Settlements in paper-based carriers

6.1. In the event of technical malfunction related to use of AZIPS and LVPCSS, payment instructions are delivered to the Central Bank in hardcopy. The Central Bank accordingly notifies other participants electronically and participant’s transactions in AZIPS and LVPCSS are conducted on behalf of the Central Bank.
6.2. When payment instructions are delivered in hardcopy, settlements are conducted according to the Guidelines on Cashless Settlements and Money Remittances in the Republic of Azerbaijan approved by Resolution# 19/1 of the Management Board of the Central Bank dated 17.09.2013.

7. Organization of business continuity of systemically important participants in emergency cases

7.1. The Central Bank identifies systemically important participants based upon previous year indicators no later than January 25 of the following year and notifies related participants in writing accordingly.
7.2. To ensure business continuity in the systems in emergency cases a systemically important participant should have business continuity and recovery plans in emergency cases in place. Business continuity and recovery plans in emergency cases should be updated annually.
7.3. The recovery plan in emergency cases should cover various possible scenarios, including process break during natural disasters and equipment malfunction, system break as a result of terror attack, outsider intrusion and cut of communication channels and other possible cases. Each of these scenarios should allow to resume operation of the systems within no later than two hours.
7.4. A systemically important participant should create a back-up center and provide the facility with the main infrastructure equipment similar to the one used in the main center, system configuration (updates and changes to hardware and software), alternative communication lines, UPS, and fire extinguishers. Technical condition of equipment should be reviewed and updated periodically. The back-up center should stand ready to conduct operations any moment, and the staff should be provided with necessary conditions to continue operations until the emergency case is eliminated.
7.5. A systemically important participant should ensure its participation in payment systems via the back-up center in a real time mode quarterly to check how prepared they are to emergency cases.
7.6. In the event of failure of operations specified in Item 7.5 herein, a systemically important participant should ensure real time operations in the backup center during the following two months.
7.7. A systemically important participant should notify the Central Bank 5 (five) days prior to providing the operation specified in Items 7.5 and 7.6 herein. A systemically important participant should deliver a Report on results of operations in the backup center (Annex №1) to the Central Bank in writing during 7 (seven) business days.
7.8. A systemically important participant should designate and instruct persons responsible (main and substitutes) to respond to queries and share information for business continuity in emergency cases and inform the Central Bank on these employees (first and last names, position and contact numbers) no later than February 25 of each year. If responsible employees are replaced a written notification on newly appointed persons should be delivered to the Central Bank within 5 (five) business days.
7.9. A systemically important participant should register the cases that caused break of its operations in the systems. Detailed information on the case, including the date it occurred, the period it was eliminated and explanation of the work done should be delivered to the Central Bank in writing within 3 (three) days at the latest after these cases occurred.
7.10. A systemically important participant should deliver a topological diagram on organization of data exchange between the backup and main centers and the address the backup center is located to the Central Bank no later than February 25 of every year.7-1. Participant’s joining the systems, suspension of their activities in the systems and their removal from the systems
7-10.1. A participant newly joined the systems signs a connection protocol (Annex №2). The Central Bank sends information on a newly joined participant electronically or on a hard copy to other participants.
7-10.2. The Central Bank suspends participant’s activity in the systems if:
7-10.2.1. competent state authorities issue an order to suspend participant's operations or a decision to seize the participant's account;
7-10.2.2. the Central Bank receives information on occurrence of a technical problem related to the use of the system at an official request of the participant (electronically or on paper).
7-10.3. Upon elimination of the circumstances that caused suspension of the participant's activity in the systems, the Central Bank immediately resumes the activity of the participant in the systems and sends the information to it electronically or on paper.
7-10.4. If a participant's banking license is revoked, the participant is declared bankrupt or liquidated by a court decision, the Central Bank removes the participant from the system without notice.
7-10.5. The Central Bank sends information to other participants of the system in electronic or paper form about the participant who was removed or applied for termination of participation in the system.
7-10.6. In the cases provided for in Item 7-1.4 herein, participant's payments in the system with the future value date and pending payments are canceled from the moment of removal of the participant from the system or termination of its participation in the system.