1. General Provisions.
The product is a software complex (hereinafter referred to as the System), designed to organize technical interaction between online stores (merchants), individuals (buyers) and payment systems, and hereinafter jointly referred to as the system participants.
The System provides the ability to interact between system participants according to uniform standards and algorithms, regardless of the payment system through which the corresponding order (goods/services) is paid.
1.1. This document is an internal regulatory document of the System Operator.
1.2. This document defines the general procedure and conditions for connecting to and disconnecting from the System.
1.3. The System Operator may introduce changes to this document. Such changes are aimed at:
- improving the quality of services provided by the System Operator
- improving the efficiency and reliability of the System
- compliance with the Applicable Requirements and amendments thereto.
1.4. The Regulatory legislation shall have priority over any provisions of this document.
1. Terms and Definitions.
1.1. System Operator means Freedom Pay Kyrgyzstan LLC, which is a legal entity operating in accordance with the Applicable Requirements, acting as the authorized owner of the System and ensuring the procedure and conditions for its use.
1.2. System is hardware and software complex, as well as related means and resources used by the System Operator to provide services for the execution of the Payment Instruction.
1.3. Funds and resources include technological, intellectual, informational, labor, financial and other means and resources used, including, but not limited to, software, ATMs, terminals, websites, cash registers, premises, personnel, communication channels and utilities.
1.4. Applicable requirements are represented by regulatory legislation, rules and standards of the Payment Systems involved, and accepted contractual obligations, including the Agreement.
1.5. Regulatory legislation is an applicable legislation of the Kyrgyz Republic.
1.6. Agreement is the Agreement concluded between the System Operator and the Merchant.
1.7. Payment Instruction is a request to carry out a transfer transaction for payment or transfer, or payment of funds initiated in the Merchant's infrastructure through the System.
1.8. Merchant's Infrastructure includes the means and resources used by the Merchant to transmit the Payment Instruction in the System.
1.9. Payment System is a fund transfer system that ensures uniform rules and standards for processing, accounting and settlement of transactions, and authorizes a specific method of executing the Payment Instruction, including, but not limited to, the international payment system VISA Inc. or international payment system MasterCard Worldwide.
1.10. Merchant is a supplier of goods and/or works and/or services, in whose infrastructure the Payment Instruction is initiated.
1.11. Personal account is a specialized section of the Merchant in the System, which displays information about the operations carried out to execute Payment instructions.
3. System Architecture and its Operating Scheme
3.1. The technical result consists in the fact that the system can combine several payment systems and provide access to them for the merchant through its single interface, within the framework of one contract and a single technical integration. The system can also combine Internet/online stores, thereby providing the Buyer with the ability to select various goods, types of goods in the same place on one website, without the need to go to them, and pay for purchases with one common payment, using any available form of payment, since the system combines all currently available forms of cash and non-cash payment for the selected product, while allowing any payment systems to be connected to the system as quickly as possible, as well as making additional payments for orders from another payment system, if the payer has no balance within the selected one. The operation of the System is based on electronic invoices created at the relevant requests of buyers by sellers (suppliers of goods/services). In this case, the request for issuing an electronic invoice can be carried out either fully automatically using the API, or manually through a special web interface available to the seller/supplier of the goods/services. Information about the receipt of payment/payout for the electronic invoice comes to the supplier of the goods/services within a few seconds in online mode.
3.2. Connection of payment systems is carried out by connecting them to the system's electronic gateway, which is capable of interacting with various types of payment systems (hereinafter referred to as Payment agents) used worldwide, such as: Internet acquiring of bank cards, cash payment systems (banking organizations, service payment terminals, POS terminals, communication stores, money transfer systems), electronic money systems and mobile payments.
3.3. One of the features of such system is a fully automated online back office, which allows you to control the operation of the System online, connect new suppliers of goods/services and payment agents as quickly as possible, configure security settings and change them depending on the needs of a particular participant in the system, and conduct mutual settlements and reconciliations online.
3.4. The main functionality of the System consists of 17 unique services/modules:
1. Payment system connection gateways.
2. Electronic invoice issuing and accounting system.
3. Store connection API is a set of ready-made procedures, functions, structures and constants provided by the system for use in external software products/online stores.
4. CMS connection modules are the modules for ensuring and organizing the joint process of creating, editing and managing of content.
5. Connection to booking systems.
6. Client interface for stores.
7. Payment gateway management system.
8. Service for returning, canceling and/or adjusting erroneous payments.
9. Service for arbitrary payments.
10. Payer notification module.
11. Manual invoicing service.
12. Anti-fraud filters for counteracting fraud through the System.
13. Statistical reporting.
14. Register reconciliation module.
15. Creation of legal and accounting documents.
16. Automatic connection to the system.
17. Integration with billing and access control system.
3.5. Interaction of the payment system with the online store owner (seller) is carried out via open communication channels of the public Internet. The https protocol is used for exchange.
3.6. Communication is authorized by creating an EDS (electronic digital signature). Each request contains an EDS, which is checked before any actions with the request. The source text (base signature string) for constructing the EDS is a string obtained by sequential (in the order of issuance) concatenation of all values in the final XML separated by a semicolon.
3.7. Requests from the payment system to the Service Provider's server are transmitted using the POST method of the http protocol with parameters in the form of XML.
3.8. Responses are returned as XML documents in UTF-8 encoding.
4. Procedure for joining and leaving the system.
System connection procedure and conditions
4.1. The procedure for connecting a Merchant to the System consists of the following conditional stages:
• Application registration
• Access to the personal account
• Filling out the questionnaire
• Collection of documents
• Verification
• Accession to the Agreement
• Integration
• Configuration of transaction processing parameters
• Testing
• Activation of the "combat mode"
4.2. The Merchant is connected to the System under the following conditions:
4.2.1. Application registration:
The Merchant initiates a connection to the System using the appropriate functionality for submitting a connection application on the website: The System automatically registers the Merchant's connection application and sends a confirmation to the email address specified when submitting the application.
4.2.2. Access to the Personal Account:
Confirmation of registration of the Merchant's connection application contains instructions, an identifier (login) and a password for authorizing access to the Merchant's Personal Account in the System. Following these instructions, the Merchant logs in to the Personal Account and proceeds to filling out the questionnaire.
4.2.3. Filling out the questionnaire:
The Merchant fills out the questionnaires in the Personal Account by entering data in accordance with the requirements of the applicable legislation of the Kyrgyz Republic on the legalization (laundering) of proceeds from crime or financing of terrorism. To get assistance in filling out the questionnaire, the Merchant may contact the System support service via the contacts specified in the received confirmation of application registration or on the Internet site https://freedompay.kg
To assist in filling out the questionnaire, the System Operator may independently contact the Merchant via the contacts specified in the connection application.
4.2.4. Collection of the package of documents:
The Merchant provides the System Operator with a set of documents in accordance with the requirements of the applicable legislation of the Kyrgyz Republic on the legalization (laundering) of proceeds from crime or financing of terrorism. The set of documents is initially provided by the Merchant by uploading photographs or copies of the original documents in the Personal Account.
4.2.5. Verification:
The System Operator checks the completeness and compliance of the questionnaire and the set of documents with the Applicable Requirements. If necessary, in accordance with the Applicable Requirements, the System Operator requests missing or additional documents from the Merchant for verification. The System Operator informs the Merchant of the verification result.
4.2.6. Conclusion of the Agreement or the Questionnaire for connection to the System:
In case of a positive verification result, the Merchant signs the questionnaire for connection to the System or concludes the Agreement with the System Operator. Unless otherwise expressly specified in the Agreement, the signing by the Merchant of the necessary documents that form the constituent parts of the Agreement and/or the Questionnaire for connection to the System shall be deemed as the conclusion of the Agreement and the acceptance by the Merchant of the General Terms of Use of the System, posted as a public offer in the public domain on the website. When concluding the Agreement, the Merchant provides the System Operator with a set of documents (originals) in accordance with the requirements of the applicable legislation of the Kyrgyz Republic.
4.2.7. Integration:
The System Operator provides the Merchant with documentation on integration with the System and, if necessary, assists the Merchant in implementing integration with the System. The Merchant, in accordance with the received documentation, implements integration with the System.
4.2.8. Configuration of transaction processing parameters:
The System Operator shall configure the parameters for processing the Merchant’s transactions in the System in accordance with the terms and conditions of the Agreement and the Applicable Requirements.
4.2.9. Testing:
Initially, the System Operator will configure a test mode for performing Merchant’s transactions. The Merchant will perform transactions in test mode via the System, notify the System Operator of any errors identified, and eliminate any errors that may occur on the Merchant’s side. The System Operator will eliminate any errors identified and notify the Merchant of any errors that occur on the Merchant’s side.
4.2.10. Activation of "combat mode":
Upon elimination of all errors, the System Operator will activate the "combat mode" for conducting the Merchant's transactions in the System.
5. Procedure and Conditions for Disconnection from the System.
5.1. The procedure for disconnection of a Merchant from the System consists of the following conditional stages:
• Agreement termination notification
• Blocking transactions
• Conducting mutual settlements
• Blocking access to the Personal Account
• Storing documents
5.2. The Merchant is disconnected from the System under the following conditions:
5.2.1. Agreement termination notification.
The Party initiating disconnection from the System sends the other Party an Agreement termination notification in accordance with the requirements of the Agreement, indicating the date and reasons (if any) for such termination. The termination period is set out in accordance with the requirements of the Agreement, as well as the Applicable Requirements.
5.2.2. Blocking transactions.
The Party initiating disconnection from the System blocks transactions through the System in accordance with the terms and conditions of the Agreement. The Party that received the Agreement termination notification shall block transactions via the Freedompay.kg System from the date of receipt of such notification, unless otherwise specified in the terms and conditions of the Agreement.
5.2.3. Conducting mutual settlements.
Once the transactions through the System are blocked, the parties will perform reconciliation and subsequent mutual settlement within the terms and under the conditions specified in the Agreement.
5.2.4. Blocking access to the Personal Account.
The Agreement shall be considered terminated provided that the parties complete mutual settlements and fulfill the obligations assumed hereunder. After termination of the Agreement, the System Operator shall block the Merchant's access to the Personal Account in the System.
5.2.5. Storage of data and documents.
After termination of the Agreement, the System Operator will store the Merchant's data and documents for the period established in accordance with the Special Conditions and other Applicable Requirements.
6. Procedure for connection of participants to the System.
6.1. The Merchant sends a connection request via the website.
6.2. The System Operator immediately sends test access to the system to the Personal Account, and integration keys.
6.3. In the Personal Account, the Questionnaire for connection to the System of the System Operator is filled out.
6.4. The Merchant sends constituent and registration documents.
6.5. The generated file is signed (signature, seal or digital signature)
6.6. Following the bilateral signing of the Merchant's Questionnaire, the "combat mode" becomes available.
7. Processing procedure.
7.1. Carrying out purchase of goods/works/services by the Cardholder 1 on the Merchant's website using Payment cards (their details) through the Internet Payment System of the Organization, as well as the procedure for settlements between the Bank and the Organization.
7.2. An individual creates an order on the merchant's website and selects the System Operator to make the payment.
7.3. The Merchant registers and transfers the order data to the System Operator.
7.4. The Payment Organization registers the order data, assigns a payment ID in the system, checks for the presence of the telephone number and E-mail of the Individual, and returns 1D payment and the URL of the payment page to the store.
7.5. After successful verification, the Individual enters the card details and clicks
"Pay".
7.6. The Individual’s card details are sent as a payment request to the Bank.
7.7. The Bank makes the payment, credits the amount to the Bank's account, returns the Individual to the page with the payment result, and transfers the payment result data to the System Operator.
7.8. The System Operator registers the payment result data, transfers the payment result data to the merchant's billing.
7.9. The Merchant records the payment for the order and fulfills the order for the Individual.
7.10. The Bank transfers the payment to the Individual after deduction of the commission fee for the Bank and the System Operator to the merchant's account within 1-5 business days.
7.11. The Bank transfers the commission fee on the Individual's payment to the System Operator's account within 1-5 business days.
7.12. To register a merchant in the Bank's system, the System Operator transfers the Application and the List of goods/works/services to the Bank to verify the information specified in these documents and makes a decision on the possibility of registering the merchant.
7.13. In case of a positive decision on the possibility of registering the specified merchant in the Bank System, the Bank shall carry out the above registration no later than 3 (three) business days from the date of receipt of the Application by the Bank.
7.14. In case of refusal to register the Merchant in the Bank System, the Bank undertakes to provide the System Operator with a reasoned justification.
7.15. After successful registration in the Bank System on the merchant's website, online payments for goods and services by cardholders become available.
8. Procedure for providing information by the payment system participants about their activities to the payment system operator
8.1. Information established for the purpose of identifying a legal entity.
Freedom Pay Kyrgyzstan LLC as the System Operator establishes and records the following information regarding legal entities:
• Name, corporate name in Russian or Kyrgyz (full and (or) abbreviated).
• Organizational and legal form.
• Taxpayer identification number for a resident, taxpayer identification number or foreign organization code - for a non-resident (if any).
• Information on state registration: registration number (for a non-resident, the registration number in the country of registration); series and number of the document confirming the state registration.
• Place of state registration and location.
• Information on the legal entity bodies (structure and personnel of the governing bodies of the legal entity).
• Information on the presence or absence at the address (location) of the legal entity of its permanent management body, other body or person entitled to act on behalf of the legal entity without a power of attorney.
• Contact telephone and fax numbers (if any).
• Date of commencement of relations with the client.
• Last name, first name, and patronymic (unless otherwise provided by law or national custom), position of the employee who completed the questionnaire, his signature (if the questionnaire is completed on paper). If organizations and individual entrepreneurs record other information, then their list shall be included in the internal control rules.
• Other information (at the discretion of the organization and individual entrepreneur).
• Information (documents) received for the purpose of identifying individual entrepreneurs.
• Information provided for in Appendix 2 to these internal control rules.
• Information on the state registration of an individual as an individual entrepreneur: state registration number; date of state registration and details of the document confirming the fact of entry into the Unified State Register of Individual Entrepreneurs of a record of the abovementioned state registration; name and address of the registering authority.
• Postal address and contact telephone and fax numbers.
9. Payment system risk management system, including the risk management model applied, a list of measures and risk management methods
9.1. The risk management system of the System Operator means a set of measures taken by the System Operator for the purpose of timely identification, measurement, control and monitoring of risks to ensure financial stability and stable functioning. For effective risk management, the System Operator developed a risk management policy, which consists of:
• risk identification, measurement, control and monitoring;
• assessment of the effectiveness of their application;
• control over the execution of all monetary transactions;
• development and practical implementation of measures to prevent and minimize risks.
9.2. The main objective of risk regulation at the Oney System Operator is to maintain acceptable ratios of profitability with security and liquidity indicators in the course of managing the assets and liabilities of the System Operator, i.e. minimization of losses. The risk management process in the Payment Organization includes:
• risk anticipation, determination of probable extent and consequences;
• development and implementation of measures to prevent or minimize associated losses.
9.3. All this implies the development of an in-house risk management strategy in such a way as to use all the development opportunities of the System Operator in a timely and consistent manner while simultaneously keeping risks at an acceptable and manageable level.
9.4. The risk management system is characterized by such elements as management activities and methods. Risk management activities include: determining the organizational structure of risk management that ensures control over the fulfillment by agents and subagents of the System Operator of the risk management requirements established by the risk management rules of the System Operator; communicating relevant information on risks to the management bodies of the System Operator; determining the indicators and procedure for ensuring the uninterrupted functioning of the System Operator of certain risk analysis methods; determining the procedure for exchanging information necessary for risk management; determining the procedure for interaction in controversial} non-standard and emergency situations, including cases of system failures; determining the procedure for changing operational and technological means and procedures; determining the procedure for ensuring the protection of the System Operator's information.
9.5. Requirements for storing information about cards and card transactions made:
• The organization is obliged to ensure compliance with the following basic requirements for storing information about cards and card transactions made;
• Do not store under any circumstances;
• The full content of any of the tracks of the magnetic strip located on the back of the card; Card validation code is a 3-digit number printed on the signature panel of the card;
• Store only that part of the card information that is essential for the business (i.e. cardholder name, card number, card expiration date).
• Ensure the protection of the information stored by the Organization on card details and transactions made using them in accordance with the requirements of PCI DSS (Payment Card Industry Data Security Standard).
• Store all materials containing information on card details and transactions made using them in a secure place accessible only to authorized persons.
• Destroy or clear all information media containing outdated data on transactions made using cards.
9.6. In case of suspected fraudulent actions of the Wallet Owner/third parties, upon detection of a failure of software and hardware, in order to ensure security by the Operator of the Electronic Money System, the Issuer shall independently block the electronic wallet or sends a written request to the Operator to block the electronic wallet of the Electronic Money Owner indicating the reason for which it is necessary to block the electronic wallet. In case of receiving such a request from the Issuer to block the electronic wallet of the Electronic Money Owner, the Operator shall block the specified electronic wallet.
Exceeding the restrictions on the types and amounts of transactions with electronic money by the Electronic Money Owner, as well as the discovery by the Operator of the transfer of information by the Electronic Wallet Owner about his own authorization parameters (user name, password) to other persons, also entails blocking of the electronic wallet by the Operator.
9.7. Risk management regulation to ensure the safety of the client's money is provided through automatic blocking of the acceptance of payments by the system if the amount of the security deposit is exhausted.
9.8. Risk management by the System Operator is determined by such methods as managing the order of execution of orders by officials; making settlements within the limits of funds provided by the agents of the Payment Organization; making settlements with the System Operator before the end of the working day; ensuring the possibility of providing a limit; other methods of risk management.
10. Information security requirements
10.1. The Participants of the System Operator shall maintain confidentiality of non-public information about other Participants of the System Operator that has become known to the Participants of the System Operator in connection with accession with these Rules, except for cases if the information:
• is disclosed at the request or with the permission of the Participant of the System Operator who is the Owner of this information;
• is subject to provision to third parties to the extent necessary to fulfill the obligations stipulated by these Rules;
• requires disclosure according to the legislation of the Kyrgyz Republic.
10.2. Providing confidential information to a third party for the purpose of fulfilling the Rules and other agreements of the Participants of the System Operator; provision of confidential information upon the legal request of law enforcement and other authorized state bodies, as well as in other cases stipulated by the applicable legislation of the Kyrgyz Republic shall not constitute a violation of the confidentiality and security of the Participants of the System Operator.
10.3. Access to the electronic wallet and performing special transactions using the electronic wallet is possible only after authentication of the Electronic Money Owner.
10.4. Authentication of the Electronic Money Owner when accessing the electronic wallet is carried out by the software of the Payment Organization using the authorization data of the Electronic Money Owner: login, password, mobile phone number and, if necessary, special SMS messages.
10.5. The Operator shall ensure the uninterrupted functioning of the System in 24/7/365 mode (24 hours a day, 7 days a week, 365 days a year), except for the time necessary for maintenance.
10.6. The Operator shall ensure the protection of information about the means and methods of ensuring information security, personal data and other information subject to mandatory protection in accordance with the legislation of the Kyrgyz Republic, which may become known to him in the course of activities: in the EM Payment Organization.
10.7. The Participants of the System Operator undertake to take all necessary measures to ensure security and protection of information and documents exchanged within the Payment Organization or which are available to the Participants of the System Operator in connection with the use of the System Operator, as well as for the purpose of identifying (preventing) fraud and combating the legalization of proceeds from crime and the financing of terrorism.
10.8. The means and measures to prevent unauthorized access to software and hardware used in the System Operator, including software and hardware protection tools, must ensure the level of information protection and maintenance of its privacy in accordance with the requirements established by the legislation of the Kyrgyz Republic. The Participants of the System Operator shall take all necessary measures to maintain confidentiality, prevent unauthorized use and protect identification data from unauthorized access by third parties.
10.9. In the event of loss of authorization data by the Participant, the System Operator shall provide the Participant with the opportunity to restore access to the electronic wallet by submitting a corresponding application in the form established by the Operator to the Operator's Internet resource.
10.10. In this case, an unidentified Owner of Electronic Money (an individual) in order to restore access to an electronic wallet shall submit a corresponding application in the form established by the Operator to any of the Operator's offices, as well as provide evidence of ownership and use of the electronic wallet, access to which is being restored: (for example, by providing a list of the latest transactions using the wallet), while the sufficiency of such evidence shall be determined at the sole discretion of the Operator.
10.10. Server structure:
The Service is developed on the PHP server technology, and involves PHP version 5.6, launched in Fast CGI mode. MySQL Server version 5.5 is used as a data storage system. The Freedompay.kg server structure consists of a firewall, two identical transaction processing nodes, a database server and a backup database server, which also ensures the creation and storage of backups; All servers are running CentOS 7.
10.11. Fault tolerance.
Fault tolerance of the service is ensured by distributing the load between two application servers. This function is performed by software Nginx version 1.8, which acts as a frontend server proxying requests to application servers in round-robin mode. In case of unavailability of one of the servers (communication channel drop, high current load, server failure), all requests will be without delay automatically switched to the server that remains online. Thus, a balance is achieved in the performance of the servers in the basic operating mode and ensures uninterrupted transaction processing in the event of unforeseen circumstances, when one of the servers temporarily fails for some reason. The database server operates in the Master-Slave replication mode with a backup server, and in the event of a failure of the main server, the transaction processing nodes are automatically switched to the backup one.
10.12. Backup:
The database server is backed up using built-in MySQL tools, with backups saved on the backup database server for one month. The backup scheme is as follows: every hour + final at 1:00 with deletion of hourly copies. Backups older than one month are deleted in order to prevent the data storage from overfilling. The relevance and preservation of the transaction processing system code base is ensured by the version control system. The code repositories themselves are stored on the BitBucket.com service, from which deployment, can be performed in the shortest possible time in the event of server failure.
10.13. Server infrastructure access security:
Administrative access to any of the servers is possible only with a 2048-bit SSH2-RSA key. It is impossible to gain access to the server infrastructure by brute-forcing passwords or any other unauthorized method. Client access to the personal account, as well as administrator access to the transaction management account, is carried out only through two-factor authorization, which is provided by the teddyid.com service. To pass authorization using this service, you must have an extension installed in your browser or a mobile application. Authorization in this area using other, less secure methods is not possible.
10.14. Transaction security:
PCIDSS
PayBox system was certified according to the PCI DSS standard and carries out all transactions in accordance with this certificate, which meets the requirements for ensuring the security of data about payment card holders stored and processed by the company.
As part of this certificate, the Digital Management Payment Organization fulfills the following requirements:
Building and maintaining a secure network:
• Installation and ensuring the functionality of firewalls to protect cardholder details;
• Restriction on use of the default system passwords and other security parameters set by manufacturers.
Cardholder Data Protection
• Ensuring the protection of cardholder data during storage;
• Ensuring encryption of cardholder data during transmission over public networks.
Support of a vulnerability management program
• Use and regular update of antivirus software;
• Development and support of secure systems and applications.
Implementation of strict access control measures
• Limiting access to cardholder data in accordance with the business need;
• Assigning a unique identifier to each person with access to the information infrastructure;
• Limiting physical access to cardholder data.
Regular network monitoring and testing
• Control and tracking of all access sessions to network resources and cardholder data;
• Regular testing of security systems and processes.
Support of information security policy
• Development, support and implementation of an information security policy.
CyberSource
Each transaction in the РауBох service passes through the CyberSource filter. This filter is a highly effective measure to protect transaction security that provides a high level of protection against fraud. More than 68 billion transactions are processed annually through the CyberSource service. Based on this data, as well as machine learning algorithms, the service decides, whether a transaction is fraudulent or not. CyberSource does not require 3D-Secure or another transaction security protection method, which allows the РayВох service to significantly expand its user base of payers with subscribers who do not have or do not enable 3D-Secure.
Trustkeeper
The РayВох server infrastructure is periodically scanned for vulnerabilities using the Trustkeeper service. During testing, the servers are subject to emulation of modern types of attacks, the use of new vulnerabilities and penetration methods. This procedure allows for timely detection and elimination of security issues.
Anti-fraud
All transactions with payment cards after their transfer from the РayВох service to the bank's payment system pass through the anti-fraud filter. Based on a set of rules, such as the presence of a card mask for sale on the black market, the reliability of the IP address from which the transaction is made, the use of a TOR client, etc., the filter calculates the risk level of the transaction and assigns it a certain rating. Depending on the level of transaction reliability set by the merchant, the bank's system processes or rejects the transaction.
11. Procedure for Settling and Resolving Disputes.
11.1. In the presence of legislative norms in force in the territory of the state, excluding the application of contractual terms in relations related to the implementation of the activities of the System Operator, the aforementioned imperative norms shall have priority over the terms of these Rules.
11.2. Disagreements between the Participants of the System Operator related to the implementation of the activities of the System Operator, or settlements between the Participants, which may serve as the basis for the emergence of the need for judicial consideration of disputes between the Participants, shall be considered by the System Operator under the claim procedure.
11.3. A claim of a Participant of the System Operator, set out in writing on official letterhead signed by its authorized official, shall be sent to the other party by registered mail or by other means confirming delivery of the claim to the addressee. The claim must be filed within 10 (ten) business days after the grounds for the claim arose, and contain an indication of the circumstances serving as the basis for its presentation, as well as the date of occurrence of the aforementioned circumstances. Claims received after the expiration of the specified period will not be taken into consideration.
11.4. Consideration of claims includes the study of circumstances that allow establishing the performance (non-performance) by the Participants of the System Operator of their functions and obligations arising from these Rules and the agreements concluded therewith. The System Operator may request from the Participants of the System Operator any information necessary to clarify the aforementioned circumstances.
11.5. A decision on the claim must be made within 15 calendar days after receipt of the claim and is communicated to the Participant who sent it in writing.
11.6. If it is impossible to resolve disagreements in the claim procedure, disputes shall be resolved by the Arbitration Court at the location of the System Operator in accordance with the legislation of the Kyrgyz Republic.
12. Procedure to be followed by participants in emergency situations in the system
12.1. This section contains the procedure for actions of the System Operator employees in emergency situations (hereinafter referred to as the Regulations).
12.2. The object of influence, control and management in the event of emergency situations is the uninterrupted functioning of the System, including:
- software; and
- hardware.
12.3. The nature of an emergency situation in the System is expressed as follows:
- failure in operation (suspension or incorrect functioning);
- detection of a fact or attempt at unauthorized access.
12.4. The factors causing emergency situations include:
- deliberate actions or inactions (of employees or third parties);
- natural phenomena (earthquake, fire, flood, hurricane, etc.);
- other factors (negligence, premature wear, accident, etc.).
List of emergency situations: