On the approval of the Rules for the integration of digital objects of the "digital government"

Home / Order / On the approval of the Rules for the integration of digital objects of the "digital government"

Order of the Deputy Prime Minister - Minister of Artificial Intelligence and Digital Development of the Republic of Kazakhstan dated July 1, 2026 No. 368/NK. Registered with the Ministry of Justice of the Republic of Kazakhstan on July 2, 2026 No. 39199

In accordance with paragraph 3 of Article 83 of the Digital Code of the Republic of Kazakhstan, I ORDER:

1. To approve the attached Rules for the integration of digital objects of the "digital government".

2. To invalidate certain orders listed in accordance with the annex to this order.

3. The Public Services Committee of the Ministry of Artificial Intelligence and Digital Development of the Republic of Kazakhstan, in accordance with the procedure established by the legislation of the Republic of Kazakhstan, shall ensure:

1) the state registration of this order in the Ministry of Justice of the Republic of Kazakhstan;

2) posting of this order on the Internet resource of the Ministry of Artificial Intelligence and Digital Development of the Republic of Kazakhstan after its official publication.

4. Control over the execution of this order is entrusted to the supervising Vice Minister of Artificial Intelligence and Digital Development of the Republic of Kazakhstan.

5. This order will enter into force on July 12, 2026 and is subject to official publication.

Deputy Prime Minister – Minister of Artificial Intelligence and Digital Development of the Republic of Kazakhstan

J. Madiev

"APPROVED" by the National Security Committee of the Republic of Kazakhstan

Approved by the Order of the Deputy Prime Minister – Minister of Artificial Intelligence and Digital Development of the Republic of Kazakhstan on July 1, 2026 No. 368/NK

Rules for the integration of digital objects of the "digital government"

Chapter 1. General provisions

1. These Rules for the Integration of digital objects of the "digital government" (hereinafter referred to as the Rules) have been developed in accordance with paragraph 3 of Article 83 of the Digital Code of the Republic of Kazakhstan (hereinafter referred to as the Code) and define the procedure for the integration of digital objects of the "digital government".

2. The following basic concepts are used in these Rules:

1) architectural coordination center is a legal entity designated by the Government of the Republic of Kazakhstan that ensures the integrity, compatibility and effectiveness of the digital architecture of government agencies, state legal entities, quasi-public sector entities, legal entities with fifty or more percent of voting shares (participation interests) owned directly or indirectly by quasi–public sector entities, as well as other organizations involved in public administration processes;

2) open data service – a way to transfer data unilaterally between digital objects;

3) verification token – an electronic key in the form of a set of a certain number of numbers and letters intended to confirm the consent of the initiator and (or) the operator from the subject of personal data;

4) Web service security (WebServiceSecurity) (hereinafter referred to as WSSecurity) is a standard for the use of security features in the exchange of messages between SOAP web services. When applying the software architecture style for distributed systems (REST), the security of the service is ensured through HTTPs security measures and the use of user authentication.;

5) the state service for access control to personal data is a service that provides information interaction between owners and (or) operators, third parties with the subject of personal data and the authorized body when accessing personal data contained in digital objects of state bodies and (or) state legal entities, including obtaining consent from the subject of personal data to collect, processing of personal data or their transfer to third parties;

6) public Peer IP address – the unique IP address of the device terminating the VPN tunnel and used on the Internet on the initiator's side of the integration service;

7) the Internet Protocol (hereinafter referred to as IP) is a routable protocol at the firewall level of the TCP/IP stack designed to transmit datagrams between computer network nodes, providing their logical addressing;

8) integration services are functional digital objects that provide interaction, data exchange and coordinated operations between digital objects through standard interfaces, protocols and access mechanisms defined by the authorized body.;

9) initiator of the integration service – the owner or owner of a digital object initiating a request for the provision of an integration service;

10) the owner or the owner of the integration service is the owner or the owner of the digital object providing the integration service.;

11) eXtensible Markup Language (hereinafter referred to as XML) is an extensible markup language used for storing and transmitting data in a structured and machine–readable format;

12) transport signature – an electronic digital signature used to ensure the integrity and authorship of transmitted messages in the information interaction of digital systems using the WSSecurity specification;

13) certification center is a legal entity established in accordance with the legislation of the Republic of Kazakhstan, which confirms the authenticity of electronic digital signature public key certificates, ownership and validity of electronic digital signature public keys.;

14) An open access API (hereinafter referred to as OpenAPI) is a formalized specification that provides an interface between the presentation part of a digital system, its user interface, low–level libraries and the application programming interface;

15) applied software service – application software designed and (or) used to perform applied user tasks, digitalize business processes, provide information interaction and other service functions;

16) Application programming interface (API) – a set of rules and protocols for the interaction of software components of digital systems with each other;

17) the Hyper Text Transfer Protocol (hereinafter HTTP) application layer protocol is a protocol that provides interaction between the client and the server by transferring hypertext documents in HTML format;

18) unified transport environment of government agencies (hereinafter referred to as UTS GO) is a telecommunications network included in the infrastructure of the "digital government" and designed to ensure the interaction of local (with the exception of local networks with Internet access), departmental and corporate telecommunications networks of government agencies, their subordinate organizations and local governments, as well as other subjects of the digital environment identified by the authorized body, in compliance with the required level of cybersecurity;

19) Simple Object Access Protocol (SimpleObjectAccessProtocol, hereinafter referred to as SOAP) is an XML–based protocol for message transmission in the integration of digital systems;

20) service passport – a web page of a specific service containing information about the contacts of responsible persons of the owner or owner, the accompanying organization (if any) and the service developer, purpose, functionality, technical characteristics, modes of interaction, conditions of information exchange, connection and other parameters of the integration service or application software service, providing information initiators of integration interaction and participants of the integration architecture on the conditions and standards for the use of this service;

21) Service registry – a list of registered integration and application software services on the Smart Bridge digital platform;

22) notification–based integration service is a method of informational interaction of digital objects, with notification sent to the owner or owner of the integration service about the start of measures for the integration of digital objects;

23) the authorized body in the field of digitalization (hereinafter referred to as the authorized body) is the central executive body responsible for the management and intersectoral coordination in the field of digitalization;

24) digital system – a functionally connected complex of digital resources that uses digital infrastructure facilities to ensure the creation, collection, processing, storage and dissemination of digital data, as well as automating the interaction of subjects of the digital environment and (or) providing services in the digital environment;

25) a digital object is a separate element of the digital environment created, used or transmitted through digital technologies, possessing unique digital characteristics and allowing subjects of the digital environment to exercise ownership, use or disposal powers to the extent established by the legislation of the Republic of Kazakhstan.;

26) integration of digital objects – measures to organize and ensure interaction between digital objects through integration services using standard data transmission protocols;

27) digital event log – files containing information about the operation of the system, used to monitor its operation and identify the causes in the event of a failure.;

28) The Identity Provider identification and authentication module of the Digital Government web portal is a specialized module that provides centralized user authentication, as well as the connection of external systems through single sign-on mechanisms;

29) the digital government operator (hereinafter referred to as the operator) – a legal entity designated by the Government of the Republic of Kazakhstan, ensuring the functioning of digital objects of the "digital government";

30) the external gateway of the "digital government" (hereinafter referred to as the GCC) is a subsystem of the gateway of the "digital government" designed to ensure the interaction of digital objects located in the ETS with digital objects located outside the ETS;

31) the digital government payment gateway is a digital object that automates the processes of transmitting information about payments as part of the provision of paid services;

32) digital objects of the "digital government" – digital objects of state bodies and other persons intended for carrying out the activities of state bodies, performing state functions and providing public services;

33) the gateway of the "digital government" (hereinafter – the gateway) is a digital object designed to integrate digital objects of the "digital government" with other digital objects;

34) electronic digital signature (hereinafter referred to as EDS) is a digital record (set of digital data) created using the private key of an electronic digital signature and electronic digital signature tools, confirming the authenticity of an electronic document, its affiliation and the immutability of its content;

35) an electronic message (hereinafter referred to as a message) is an electronic document in XML or JSON format intended for the exchange of information between digital objects;

36) The Java Script Object Notation format (hereinafter referred to as JSON) is a text data exchange format based on JavaScript;

37) The mTLS mutual authentication mechanism is a network communication protection mechanism in which the authenticity of both sides of the connection is confirmed by mutual verification of digital certificates using the TLS 1.2 protocol and higher;

38) The software architecture style of Representative State Transfer (hereinafter referred to as REST) is a consistent set of constraints taken into account when designing distributed digital systems or interacting services using HTTP, URL, JSON, and XML standards.;

39) SSL certificate (Secure Sockets Layer) is a registration certificate intended for use by an Internet resource or a digital system to provide authentication procedures.;

40) the Smart Bridge digital platform (hereinafter referred to as Smart Bridge) is a digital object designed to publish integration services of state and non–state digital objects, application software services on it in order to provide access to them and (or) organize their interaction;

41) Transmission Control Protocol (hereinafter referred to as TCP) is a protocol of the TCP/IP stack transport layer that provides reliable transmission of network packets in a computer network between a sender and a recipient through a pre–established connection between them and control of the flow of transmitted network packets;

42) the Uniform Resource Locator (hereinafter referred to as the URL) is a unified resource pointer on the Internet.;

43) the User Datagram Protocol (hereinafter referred to as UDP) is a protocol of the TCP/IP stack transport layer that provides the transmission of autonomous datagrams in a computer network between the sender and the recipient without guarantees of their delivery;

44) Virtual Private Network Logical Network (hereinafter referred to as VPN) is a network that uses virtualization technology to extend an IP address in a public telecommunications network using encryption and tunneling;

45) X.509 certificate is a digital certificate used for authentication, encryption, and data integrity during the interaction of digital objects.;

46) XSD Schema (XML Schema Definition) is a language for describing the structure of an XML document that defines the rules to which an XML file must conform.

3. The integration of digital objects is carried out by means of WTSP and (or) WTSP, with the exception of:

1) services provided by certification centers, except for the integration interaction of digital objects within the ETS contour.;

2) digital objects containing information constituting the state secrets of the Republic of Kazakhstan and official information marked "For official use";

3) digital objects hosted on the digital government platform and intended to form a single data space for the purpose of providing analytical information on the activities of government agencies of the Republic of Kazakhstan;

4) digital objects hosted on the digital government platform and intended for tax and customs administration in accordance with the tax and customs legislation of the Republic of Kazakhstan;

5) digital objects that receive information from government agencies, military formations, military units and military organizations necessary to perform tasks assigned to national security agencies;

6) services for providing open data through OpenAPI, API, using XML, JSON formats and HTTP and HTTPS protocols, through the REST architectural style, including Internet portals of open data, open budgets and open regulatory legal acts;

7) information interaction between the digital government web portal and the digital government mobile application in the framework of the provision of public and other services in electronic form;

8) The Identity Provider identification and authentication module of the Digital Government web portal.

4. The integration of non-governmental digital facilities with digital facilities of the "digital government" is carried out on a reimbursable basis with the conclusion of a service agreement with the operator, except in cases where the integration of digital facilities of the "digital government" is established by the legislation of the Republic of Kazakhstan.

In the absence of a concluded agreement, the operator suspends the connection of the initiator of the integration service to the integration service until the conclusion of a contract for the provision of paid services with the operator.

5. When integrating non-governmental digital facilities with state-owned digital facilities, the owners and (or) owners of digital systems enter into a joint cybersecurity agreement.

6. The integration of digital objects is carried out through a Smart Bridge, taking into account the SOAP web service data formats specified in Appendix 1 to these Rules.

7. Applications and documents for the integration of digital objects are certified by the EDS of authorized persons participating in the integration interaction.

8. The integration of digital objects is carried out subject to the availability of an integration service or an application software service in the service registry.

9. The operator develops and/or publishes an integration and/or application software service, as well as updates or excludes them from the register of services at the request of the owner or owner of the integration service or an authorized body, compiled in any form, with notification to the authorized body and the architectural coordination center.

10. If the initiator of the integration service does not use the state integration service, the operator, within ten working days, disconnects him from the service containing personal data and confidential information at the request of the authorized body and (or) the owner or owner of the integration service, and (or) the architectural coordination center with notification to the authorized body.

11. When providing paid services in digital form, the digital object automatically sends information about the payment to the payment gateway of the "digital government" for its recording.

12. The application for connection to the integration service or for the publication of the integration service is accompanied by test reports with a positive result of tests for compliance with cybersecurity requirements issued no more than three years before the connection, when the digital system of the initiator of the integration service is classified as digital objects specified in paragraph 2 of Article 49 of the Law "On Cybersecurity".

Chapter 2. The procedure for the integration of digital objects of the "digital government"

Paragraph 1. The procedure for publishing the integration service on the Smart Bridge at the initiative of the initiator of the integration service

13. To publish an integration service in the registry of services, the initiator of the integration service sends via Smart Bridge a request to identify the owner or owner of a digital object that contains the necessary information to the architectural coordination center.

14. Upon receiving notification of a request, the architectural coordination center reviews it within two business days and provides it to the initiator of the integration service.:

1) confirmation and information about the owner or owner of a digital facility, as well as recommendations for the development of an integration service within the framework of the digital government architecture;

2) motivated refusal.

15. The initiator of the integration service, upon confirmation by the architectural coordination center, logs in to the Smart Bridge and sends an application for the creation of an integration service in any form to the owner or owner of the digital facility.

16. The owner or owner of the digital facility reviews the application for the creation of an integration service within two business days after its receipt. According to the results of the review, the owner or the owner of the digital object:

1) approves the application for the creation of an integration service;

2) returns it to the initiator of the integration service for revision;

3) refuses to create an integration service, stating the reasons.

17. When approving an application for the creation of an integration service, the owner or owner of a digital facility fills out an application for publication of the integration service on the Smart Bridge digital platform in accordance with Appendix 2 to these Rules (hereinafter referred to as the application for publication of the integration service), notifying the initiator of the integration service and the authorized body.

18. When an application for the creation of an integration service is returned by the owner or owner of a digital facility for revision, the initiator of the integration service finalizes this application within two working days and resends it to the owner or owner of the digital facility.

19. If the owner or owner of a digital object refuses to create an integration service, the measures for its publication are terminated.

20. Upon receipt of an application for the publication of an integration service, the operator checks it for completeness and correctness within three working days. If the verification result is negative, the operator sends an application for publication of the integration service for revision, indicating the reasons.

21. The owner or owner of the digital facility shall finalize the application for publication of the integration service within two working days and send the application for publication of the integration service agreed upon by the owner or owner of the digital facility to the operator.

22. If the verification result of the application for the publication of the integration service is positive, the operator provides the initiator of the integration service with access to the test environment of the ADC, the ADC, and connects it to conduct integration testing within ten working days.

23. The developers of the integration service on the part of the owner or owner of the digital object, the initiator of the integration service, make changes to digital objects in order to test their integration.

24. The developers of the integration service on the part of the owner or owner of the digital object, the initiator of the integration service and the operator conduct testing of the integration service for a period of no more than three months until a positive result is obtained.

25. On the part of the ADC, the confirmation of the implementation of the integration service is the transmission of messages (for an asynchronous service, the sender receives a unique message identifier, for a synchronous service, the recipient receives a response message) between the participants in the interaction recorded in the event log of the ADC.

26. On the part of the participants in the integration interaction, confirmation of the implementation of the integration service is the fulfillment of the conditions of interaction and the processing of data by the participants in the interaction.

27. If the test result of the integration service is positive, the owner or owner of the integration service forms an act of testing and commissioning of the integration service in accordance with Appendix 3 to these Rules (hereinafter referred to as the act of testing and commissioning), certifies it with his EDS and sends it for approval to the initiator of the integration service.

If the result is negative, integration testing continues until a positive result is obtained.

28. Upon receipt of the application for publication of the integration service and the act of testing and commissioning, the initiator of the integration service coordinates the act of testing and commissioning within three working days, certifying it with his EDS, and sends it to the operator for approval.

29. The operator reviews the act of testing and commissioning within three business days from the date of receipt of the application for publication of the integration service and the act of testing.

30. If the verification result is negative, the operator returns the act of testing and commissioning for revision to the owner or the owner of the integration service. The owner or the owner of the integration service shall finalize the test report within three working days and resend it to the initiator of the integration service for review.

31. If the test report is verified positively, the operator approves the test and commissioning report, publishes the service passport for the Smart Bridge within ten working days, and provides the initiator of the integration service with access to the integration service for the industrial environment of the SRC, SRC. The authorized body and the architectural coordination center are notified of the publication of the integration service through the Smart Bridge personal account.

Paragraph 2. The procedure for publishing the integration service on the Smart Bridge at the initiative of the owner or owner of the digital facility

32. To publish an integration service in the registry of services, the owner or owner of the integration service starts the process of publishing the integration service on the Smart Bridge.

33. The owner or owner of the integration service fills out the requirements for interaction with the integration service in accordance with Appendix 4 to these Rules (hereinafter referred to as the requirements for interaction with the integration service) and the application for publication of the integration service, accepts the integration terms, with the application of the XSD schema, as well as XML examples of the request and response with test data.

34. Upon receiving notification of receipt of the application for publication of the integration service, the operator verifies the application for publication of the integration service and the application for network access for completeness and correctness within three working days.

If the result of the check is negative, the operator sends them for revision, indicating the reasons.

35. If the verification of the application for the publication of the integration service is positive, the operator publishes the application in the register of services within ten working days and provides the owner or owner of the integration service with access to the test and industrial environment of the Integration Center.

36. The authorized body and the architectural coordination center are notified of the publication of the integration service via the Smart Bridge.

37. If the owner or owner of the integration service that connects to the service specifies the owner or owner of the digital object, the integration service is published in accordance with the procedure established by paragraphs 17-31 of these Rules.

Paragraph 3. Procedure for connecting to an integration service or an application software service

38. If the necessary integration service is available in the Smart Bridge service registry, the initiator of the integration service fills out an application for connection to the integration service in accordance with Appendix 5 to these Rules (hereinafter referred to as the application for connection to the integration service) and accepts the integration terms.

39. The connection to the integration service is based on the requirements for interaction with the integration service.

40. When owners or owners of non-governmental digital systems use integration services to provide public services, the owners or owners of integration services conclude an agreement on the use of integration services by owners or owners of non-governmental digital systems to provide public services in accordance with Appendix 6 to these Rules with the authorized body in the field of public services on the Smart Bridge.

41. When a government agency initiates an application for connection to the integration service of a government agency, the application is sent to the operator for consideration. The owner or the owner of the integration service is notified about the initiation of an application for connection to the integration service by e-mail and Smart Bridge personal account.

42. When an application for connection to an integration service is initiated by the owner or owner of a non-governmental digital system, a notification is sent to the owner or owner of the integration service via Smart Bridge about the need to consider the application for connection to the integration service.

43. When connecting non-governmental digital systems to an integration service, in the application for publication of which the owner or owner indicates the absence of personal data in it and the presence of at least 100 connections to it, this integration service is considered a notification service.

When an application is initiated by the owner or owner of a non-governmental digital system for connection to a notification service, the application is sent for consideration to the operator and the owner or owner of the integration service via a Smart Bridge.

44. The owner or the owner of the integration service, having received a notification of the need to consider the application for connection to the integration service, sends a response of consent or a reasoned refusal indicating the reasons within two working days.

A refusal that does not contain legal or technical grounds, as well as a refusal that amounts to a requirement to perform actions not provided for in the Rules, is considered unmotivated and is not allowed.

45. If the owner or the owner of the integration service fails to provide a response within the prescribed period, the application for connection to the integration service of a notifying nature is considered agreed.

46. After approval of the application for connection to the integration service, the operator is notified of the need to review and approve the application via a Smart Bridge.

47. Upon receipt of the notification, the operator checks the completeness and correctness of the application for connection to the integration service within three working days and approves it in the absence of comments.

If the verification result of the application for connection to the integration service is negative, the operator sends it for revision, indicating the technical reasons.

48. The initiator of the integration service shall finalize the application for connection to the integration service within three working days and resend it:

1) for consideration by the operator and for familiarization by the owner or the owner of the integration service in the case of integration of state digital systems;

2) for consideration by the owner or the owner of the integration service in the case of integration of non-governmental digital systems with state-owned ones.

49. Upon approval of the application for connection to the integration service, the operator, within ten working days, provides the owner or the owner of the integration service, the initiator of the integration service, with access to the test environment of the WTSP, WTSP for testing the integration service until a positive result is obtained within a period of no more than three months.

50. On the part of the SRC, the confirmation of the implementation of the integration service is the transmission of messages (for an asynchronous service, the sender receives a unique message identifier, for a synchronous service, the receipt of a response message) between the participants in the interaction, recorded in the event log of the SRC, SRC.

51. On the part of the owner or the owner of the integration service and the initiator of the integration service, confirmation of the implementation of the integration service is the fulfillment of the conditions of interaction and data processing.

52. If the integration service is tested positively, the initiator of the integration service forms an act of testing and commissioning, certifies it with his EDS and sends it to the owner or owner of the integration service for approval.

If the result is negative, testing of the integration service continues until a positive result is obtained.

53. Upon receipt of the application for connection to the integration service and the act of testing and commissioning, the owner or owner of the integration service approves it within three working days, certifying it with his EDS and sending it to the operator for approval.

54. The operator reviews the act of testing and commissioning within three working days from the date of its receipt.

55. If the verification result is negative, the operator returns the act of testing and commissioning for revision to the initiator of the integration service. The initiator of the integration service shall finalize it within three working days and resend it to the owner or owner of the integration service for review.

56. If there is a positive result of checking the act of testing and commissioning, the operator approves it and within ten working days provides the initiator of the integration service with access to the integration service in the industrial operation environment of the SRC, SRC. The authorized body and the architectural coordination center are notified about the connection of the initiator of the integration service to the integration service via a Smart Bridge.

57. If personal data is available in the integration service, integration is performed using the state service for access control to personal data in accordance with the Rules for Integration with the state service for Access Control to personal data, approved by Order No. 236/NK of the Acting Minister of Digital Development, Innovation and Aerospace Industry of the Republic of Kazakhstan dated July 8, 2022 (registered in the Register of State Registration regulatory legal acts No. 28786).

58. When connecting to integration services that process and provide personal data, the verification token is checked by the ADC. In the absence of a verification token or unsuccessful verification, the initiator of the integration service is not granted access to it with a notification indicating the reason for the refusal.

59. If the required application software service is available in the registry of services on the Smart Bridge, the initiator of the connection to the application software service fills out an application for its connection and accepts the connection conditions.

60. The application is sent for consideration to the owner or the owner of the application software service via a Smart Bridge.

61. Upon receipt of an application for connection to an application software service, the owner or owner of the application software service approves it within three working days and sends it to the operator for approval or sends a reasoned refusal indicating the reasons.

62. Upon approval of the application for connection to the application software service, the operator provides the initiator of the connection to the application software service with access to the test environment for testing the application software service within ten working days until a positive result is obtained within two months.

63. If the test result is positive, the operator provides the initiator of the connection to the service's application software service with access to it in an industrial operation environment within ten working days.

Paragraph 4. The procedure for updating the integration service

64. The owner or the owner of the integration service initiates the updating of the integration service in the event of a change in the operating conditions of the integration service or at the request of the initiator of the integration service.

65. The integration service is updated by the owner or owner of the integration service after its authorization on the Smart Bridge by submitting to the operator an application for updating the integration service in accordance with Appendix 7 to these Rules (hereinafter referred to as the application for updating the integration service).

66. Upon receiving notification of receipt of the application for updating the integration service, the operator checks its completeness and correctness within three working days.

If the verification result of the application for updating the integration service is negative, the operator sends it for revision, indicating the reasons.

If the verification of the application for updating the integration service is positive, the operator will update the integration service within ten working days.

Paragraph 5. The procedure for updating the connection to the integration service

67. When the operating conditions of the connection to the integration service change, the initiator of the integration service updates the connection to it.

68. Updating the connection to the integration service is carried out by the initiator of the integration service by submitting to the operator an application for updating the connection to the integration service in accordance with Annex 8 to these Rules (hereinafter referred to as the application for updating the connection to the integration service) using a Smart Bridge.

69. Upon receiving notification of receipt of the application for updating the connection to the integration service, the operator checks its completeness and correctness within three working days.

If the verification result is negative, the operator sends an application for updating the integration service for revision, indicating the reasons.

If the verification result is positive, the operator updates the connection to the integration service within ten working days.

Chapter 3. Ensuring the operation and protection of the integration service and the application software service

70. Integration services and application software services are hosted on the digital infrastructure located on the territory of the Republic of Kazakhstan.

71. The SRC and the SRC ensure the transfer of integration services and application software services around the clock on an ongoing basis, with the exception of technological interruptions.

The time for receiving the message of the ADC, the ADC should not exceed one minute from the moment it is received via the universal synchronous channel and the asynchronous channel.

72. Technological interruptions in the work of the digital facilities of the initiator of the integration service and the owner or owner of the integration service or application software service are negotiated and agreed upon in advance between them and the operator three working days before the start of their implementation. Technological breaks should take place at night from 21:00 to 6:00, as well as on weekends and holidays.

73. For the purpose of testing, the participants in the interaction ensure the operability of the test environment of digital objects.

74. If a technical error occurs, the operator and (or) the owner or the owner of the integration service and (or) the initiator of the integration service reboots the digital object and notifies the administrators of other digital objects about the time of technical work, in the form of a telephone message or by e-mail.

75. If the owner or the owner of the integration service or the application software service and/or the initiator of the integration service fails to take measures to correct the technical errors that have occurred, the operator will disable or suspend the corresponding integration service or application software service within three working days with notification of the temporary unavailability of the service.

76. In case of malfunction or scheduled maintenance work carried out by telecom operators on communication channels providing the transfer of an integration service or an application software service, the duration of technical work is determined by the regulations of the telecom operator.

77. When implementing an integration service, the transmitted information is protected by:

1) using mechanisms to control the integrity and reliability of information, including confirmation of authorship, signed EDS XML messages;

2) authorization of the initiator of the integration service and the owner or owner of the integration service or the application software service on the ADC, ADC by login and password issued by the operator, by transport signature or mTLS mutual authentication mechanism. For integration services implemented in the distributed systems architecture (REST) style, authorization is performed using a username and password in conjunction with the mTLS mutual authentication mechanism.;

3) logging of events related to the transfer of the integration service to the SRC, SRC.

78. The confirmation of the authorship of the messages is a positive result of checking the compliance of the transport signature with the registration certificate of the EDS of the owner or owner of the integration service or application software service and (or) the initiator of the integration service who sent the message.

82. The transport signature is checked on the EDS when calling the integration service according to the transport signature usage scenario in accordance with Appendix 9 to these Rules and include verification of the identity of the EDS to the sender of the message and verification of the validity of the EDS.

86. In case of temporary shutdown of the integration service or application software service caused by modification and/or modification of the digital object providing access to the integration service, the owner or owner of the integration service or application software service notifies the authorized body and all initiators of the integration service or application software service via Smart Bridge three business days before the start of its shutdown.

Upon termination of the integration service or application software service, its owner or owner notifies the authorized body and all initiators of the integration service via Smart Bridge one month before the termination of work.

87. The owner or owner of the integration service and the initiator of the integration service determine the responsible persons who ensure cybersecurity and constant availability of software and hardware, and when their composition changes, they inform each other about the changes and provide new information about the responsible persons within seven working days.

92. When the initiators of the integration service receive a review on the Smart Bridge about the inaccuracy of the information posted in the service passport, the system records the corresponding status. The owner or the owner of the integration service is obliged to update the information within no more than one month from the date of receipt of the review.

Appendix 1 to the Rules for the Integration of digital objects of "Digital Governance"

Download

SOAP Web Service data Formats

1. Description of asynchronous channel messages:

1.1. the interface of the integration service on the side of the gateway of the "digital government" (hereinafter referred to as the DG) and the external gateway of the "digital government" (hereinafter referred to as the DG).

The method used is to send messages to the asynchronous ADC channel, the SendMessage ADC.

The service request (SendMessageRequest) contains the following fields: SendMessageRequest data format

Download

Field

Type

Mandatory filling

Description

request

AsyncSendMessagerequest

Yes

Request

messageInfo

AsyncMessageInfo

Yes

Message metadata

messageId

xsd: string

Yes

The ID of the message in the system of the owner of the integration service (generated by the system)

correlationId

xsd: string

The ID of the message chain in the system of the owner of the integration service (if a message exists within the message chain of the system (sender), it is formed by the owner's system)

serviceId

xsd: string

Yes

Service ID

messageType

xsd: string

Yes

Message type:REQUEST – the first message of the interaction

routeId

xsd: string

The identifier of the message route (if additional routing is required, the identifier according to the registry is filled in by the sender's system)

messageDate

xsd: dateTime

Yes

Date the message was created

sessionId

guid

Yes

ID of the ADC session. To be filled in at the MCP, not filled in by the sender

sender

SenderInfo

Yes

The sender's information object (to be filled in by the sender)

senderId

xsd: string

Yes

Sender's ID (sender's system)

password

xsd: string

Yes

Sender's password

properties

property

An array of properties that specify additional request properties in agreement with the ADC, the recipient's and sender's system.

Key

xsd: int

Property Key

value

xsd: int

Property Value

messageData

messagedata

Yes

Data transfer object

data

xsd: Anytype

The "message data" object

The response to the SendMessageResponse message is an array of elements with the following fields: SendMessageResponse data format

Download

Field

Type

Mandatory filling

Description

response

AsyncSendMessagerequest

Yes

Answer

messageId

xsd: string

Yes

Message ID

correlationId

xsd: string

Yes

ID of the message thread

responseDate

xsd: dateTime

Yes

Response date

sessionId

Guid

ID of the ADC session

The SendMessagefault error response is an array of elements with the following fields: SendMessagefault data format

Download

Field

Type

Mandatory filling

Description

ErrorInfo

Error Information

errorCode

xsd: string

Yes

Error code

errorData

xsd: string

Yes

Additional error description

errorDate

xsd: dateTime

Yes

Date of error

subError

ErrorInfo

Child error

sessionId

guid

ID of the session where the error occurred

1.2. The interface for the implementation of the integration service on the side of the users of the ADC, the ADC for working with an asynchronous channel.

The service is implemented on the side of the owner or initiator of the integration service. The service is implemented if it is necessary to deliver SMS messages by calling the message recipient's service (PUSH).

The SendMessage message sending method is used.

The SendMessageRequest message request contains the following fields: SendMessageRequest data format

Download

Field

Type

Mandatory filling

Description

request

Async SendMessageRequest

Yes

messageInfo

Async SendMessageInfo

Yes

Meta message data

messageId

xsd: string

Yes

The ID of the message.An ADC is generated. If a message is sent to the ADC, this field remains empty. In case of transmission of the message to the recipient, the number will be marked with a CPT.

correlationId

xsd: string

ID of the message chain. An ADC is generated. If a REQUEST message is sent to the ADC, this field remains empty. When sending other types of messages to the ADC, this field must be filled in. In case of transmission of the message to the recipient, the number will be marked with a CPT.

serviceId

xsd: string

Yes

The interaction ID. According to the registry of services of the WPP.

messageType

xsd: string

Yes

Message type:REQUEST - the first message of the interaction

routeId

xsd: string

The identifier of the message route (if there is a need for additional routing, the identifier according to the registry is filled in by the sender's system)

messageDate

xsd: dateTime

Yes

Date the message was created

sessionId

guid

ID of the ADC session. It is filled in at the MCP, the sender does not need to fill it in.

sender

SenderInfo

Yes

The sender information object

senderId

xsd: string

Yes

Sender's system ID

password

xsd: string

Sender's password

properties

Property

An array defining additional properties of the request in agreement with the ADC, the recipient's and sender's system.

key

xsd: int

Yes

Property Key

value

xsd: int

Yes

Property Value

messageData

Yes

Data transfer object

data

xsd: Anytype

Yes

The "message data" object

The WPC response to the SendMessageResponse message is an array of elements with the following fields: SendMessageResponse data format

Download

Field

Type

Mandatory filling

Description

response

Async SendMessageResponse

Yes

Answer

messageId

xsd: string

Yes

Message ID

correlationId

xsd: string

Yes

ID of the message thread

responseDate

xsd: dateTime

Yes

Response date

sessionId

guid

ID of the ADC session

The SendMessageFault error response is an array of elements with the following fields: SendMessageFault data format

Download

Field

Type

Mandatory filling

Description

ErrorInfo

Error Information

errorCode

xsd: string

Yes

Error code

errorData

xsd: string

Yes

Additional error description

errorDate

xsd: dateTime

Yes

Date of error

subError

ErrorInfo

Child error

sessionId

guid

ID of the session where the error occurred

2. Description of synchronous channel messages

2.1. The interface of the integration service on the side of the ADC:

The method of sending messages via the synchronous SendMessage channel is used.

The SendMessageRequest service request is an array of elements with the following fields: The format of the SendMessageRequest message type

Download

Field

Type

Mandatory filling

Description

request

SyncsendMessagerequest

Yes

Request

requestInfo

SyncMessageInfo

Yes

Information about the request message

messageId

xsd: string

Yes

The ID of the message in the recipient's system (generated by the ADC)

correlationId

xsd: string

ID of the message chain in the system of the recipient of the request (generated by the ADC)

serviceid

xsd: string

Yes

The interaction ID (maintained in the registry of ADC services)

messegeDate

xsd: dateTime

Yes

The date when the message was created in the system of the initiator of the integration service (To be filled in by the system).

routeId

xsd: string

The identifier of the message route (if additional routing is required, the identifier according to the registry is filled in by the system of the initiator of the integration service)

sessionId

guid

ID of the session on the ADC. It is installed on the control panel.

sender

senderinfo

Yes

Sender's information (to be filled in by the sender)

senderId

xsd: string

Yes

Sender's ID (sender's system)

password

xsd: string

Yes

Sender's password

properties

property

An array defining additional properties of the request in agreement with the ADC, the recipient's and sender's system.

key

xsd: string

Property Key

value

xsd: string

Property Value

requestData

Yes

Request data transmission object

data

xsd: Anytype

1.2. The interface for the implementation of the integration service on the side of the users of the ADC, the ADC for working with an asynchronous channel.

The SendMessage message sending method is used.

The SendMessageRequest message request contains the following fields: SendMessageRequest data format

Download

Field

Type

Mandatory filling

Description

request

Async SendMessageRequest

Yes

messageInfo

Async SendMessageInfo

Yes

Meta message data

messageId

xsd: string

Yes

The ID of the message.An ADC is generated. If a message is sent to the ADC, this field remains empty. In case of transmission of the message to the recipient, the number will be marked with a CPT.

correlationId

xsd: string

serviceId

xsd: string

Yes

The interaction ID. According to the registry of services of the WPP.

messageType

xsd: string

Yes

Message type:REQUEST - the first message of the interaction

routeId

xsd: string

The identifier of the message route (if there is a need for additional routing, the identifier according to the registry is filled in by the sender's system)

messageDate

xsd: dateTime

Yes

Date the message was created

sessionId

guid

ID of the ADC session. It is filled in at the MCP, the sender does not need to fill it in.

sender

SenderInfo

Yes

The sender information object

senderId

xsd: string

Yes

Sender's system ID

password

xsd: string

Sender's password

properties

Property

An array defining additional properties of the request in agreement with the ADC, the recipient's and sender's system.

key

xsd: int

Yes

Property Key

value

xsd: int

Yes

Property Value

messageData

Yes

Data transfer object

data

xsd: Anytype

Yes

The "message data" object

The WPC response to the SendMessageResponse message is an array of elements with the following fields: SendMessageResponse data format

Download

Field

Type

Mandatory filling

Description

response

Async SendMessageResponse

Yes

Answer

messageId

xsd: string

Yes

Message ID

correlationId

xsd: string

Yes

ID of the message thread

responseDate

xsd: dateTime

Yes

Response date

sessionId

guid

ID of the ADC session

The SendMessageFault error response is an array of elements with the following fields: SendMessageFault data format

Download

Field

Type

Mandatory filling

Description

ErrorInfo

Error Information

errorCode

xsd: string

Yes

Error code

errorData

xsd: string

Yes

Additional error description

errorDate

xsd: dateTime

Yes

Date of error

subError

ErrorInfo

Child error

sessionId

guid

ID of the session where the error occurred

2. Description of synchronous channel messages

2.1. The interface of the integration service on the side of the ADC:

The method of sending messages via the synchronous SendMessage channel is used.

The SendMessageRequest service request is an array of elements with the following fields: The format of the SendMessageRequest message type

Download

Field

Type

Mandatory filling

Description

request

SyncsendMessagerequest

Yes

Request

requestInfo

SyncMessageInfo

Yes

Information about the request message

messageId

xsd: string

Yes

The ID of the message in the recipient's system (generated by the ADC)

correlationId

xsd: string

ID of the message chain in the system of the recipient of the request (generated by the ADC)

serviceid

xsd: string

Yes

The interaction ID (maintained in the registry of ADC services)

messegeDate

xsd: dateTime

Yes

The date when the message was created in the system of the initiator of the integration service (To be filled in by the system).

routeId

xsd: string

The identifier of the message route (if additional routing is required, the identifier according to the registry is filled in by the system of the initiator of the integration service)

sessionId

guid

ID of the session on the ADC. It is installed on the control panel.

sender

senderinfo

Yes

Sender's information (to be filled in by the sender)

senderId

xsd: string

Yes

Sender's ID (sender's system)

password

xsd: string

Yes

Sender's password

properties

property

An array defining additional properties of the request in agreement with the ADC, the recipient's and sender's system.

key

xsd: string

Property Key

value

xsd: string

Property Value

requestData

Yes

Request data transmission object

data

xsd: Anytype

Message data (format is determined by the system of the recipient of the message)

The response message to the SendMessageResponse request is an array of elements with the following fields: The format of the SendMessageResponse message type

Download

Field

Type

Mandatory filling

Description

response

SyncsendMessageresponse

Yes

Answer

responseInfo

SyncMessageInfoResponse

Yes

Information about the response

messageId

xsd: string

Yes

The ID of the message in the recipient's system (generated by the system of the owner of the integration service)

correlationId

xsd: string

The ID of the message chain in the system of the recipient of the request (if the message exists within the message chain of the sender's system, it is generated by the system of the owner of the integration service)

responseDate

xsd: dateTime

Yes

The date of the response in the system of the owner of the integration service (to be filled in by the system of the owner of the integration service)

sessionId

guid

ID of the session on the ADC. It is installed on the control panel. It is not filled in when sending a response by the system of the owner of the integration service.

status

StatusInfo

Yes

The "Status Information" object

code

xsd: int

Yes

Status code (entered by the system of the recipient of the request)

message

xsd: string

Yes

Status message

responseData

responsedata

Yes

The "response data" object

data

xsd: Anytype

The message data object (the format is determined by the system of the owner of the integration service)

The SendMessageFault1_SendMessageFault error message is an array of elements with the following fields: The format of the SendMessageFault message type

Download

Field

Type

Mandatory filling

Description

errorCode

xsd: string

Yes

Error code

errorMessage

xsd: string

Yes

Error message

errorData

xsd: string

Additional error description

errorDate

xsd: dateTime

Date of error

subError

ErrorInfo

Child error

sessionId

Guid

ID of the session where the error occurred

Data formats of REST services

A service request is an array of elements with the following fields:

Download

Field

Type

Mandatory filling

Description

request

SyncsendMessagerequest

Yes

Request

requestInfo

SyncMessageInfo

Yes

Information about the request message

messageId

xsd: string

Yes

The ID of the message in the system of the owner of the integration service (generated by the ADC)

serviceid

xsd: string

Yes

The interaction ID (maintained in the registry of ADC services)

messegeDate

dateTime

Yes

Date of creation of the message in the system of the initiator of the integration service (to be filled in by the owner of the integration service)

routeId

xsd: string

The identifier of the message route (if additional routing is required, the identifier according to the registry is filled in by the system of the owner of the integration service)

sender

senderinfo

Yes

Sender's information (to be filled in by the sender)

senderId

xsd: string

Yes

Sender's ID (sender's system)

password

xsd: string

Yes

Sender's password

requestData

Yes

Request data transmission object

data

Anytype

Message data (format is determined by the system of the recipient of the message)

The response message to the request is an array of elements with the following fields:

Download

Field

Type

Mandatory filling

Description

response

SyncsendMessageresponse

Yes

Answer

responseInfo

SyncMessageInfoResponse

Yes

Information about the response

messageId

xsd: string

Yes

The ID of the message in the system of the owner of the integration service (filled in by the system of the owner of the integration service)

responseDate

dateTime

Yes

The date of the response in the system of the owner of the integration service (to be filled in by the system of the owner of the integration service)

message

string

Yes

Status message

responseData

responsedata

Yes

The "response data" object

data

Anytype

The message data object (the format is determined by the system of the owner of the integration service)

Appendix 2 to the Rules for the Integration of Digital objects of the Digital Government

Form

Application for publication of an integration service on the Smart Bridge digital platform

Download

1. General information

The name of the service in Russian

The name of the service in Kazakh

The purpose of the service is in Russian

The purpose of the service in the Kazakh language

The official responsible for the operation (in Russian)

The official responsible for the operation (in Kazakh)

Contact phone number

Contact email address

10.

Contact information of the service developer (in Russian)

11.

Contact information of the service developer (in Kazakh)

12.

Contact phone number

13.

Contact email address

14.

Name of the accompanying organization

15.

Tags

16.

The root category of the service

17.

Service interaction mode

18.

Service format

19.

Who can access the service

20. Recommended performance and reliability requirements

21. Controlled indicator

22.

Maximum request processing time (filled in only for synchronous services)

23.

Average request processing time (filled in only for synchronous services)

24.

25.

Rated load (optimal number of requests per hour)

26.

Average operation time without failures

27.

Time to restore working capacity

28.

Cybersecurity requirements Requirements for the event log format Requirements from the Digital Government gateway and/or the external digital Government gateway

29.

Confirmation of compliance with these requirements

30. Service Parameters

31. The digital system of the owner of the integration service

32.

Name of the digital system

33.

System login

34.

Password (test environment)

35.

Password (operating environment)

36.

The service key

37.

The security method

38.

Transport Signature Public Key Certificate (.cer; .crt) (issued by the National Certification Center of the Republic of Kazakhstan)

39.

Certificate type (general/for test environment/for operational environment)

40.

Cybersecurity Test Report

41.

The scheme of information interaction

42.

Indication of message routing (yes/no)

43.

The service provides personal data (yes/no)

44.

Notification service (yes/no)

45.

Publish the service on the external gateway of the "digital government" (yes/no)

46.

The name of the URL of the service accepting requests (test environment)

47.

The name of the URL of the service accepting requests (operating environment)

48.

URL of the service accepting requests (test environment)

49.

URL of the service accepting requests (operating environment)

50.

SSL certificate (.cer; .crt) (issued by the National Certification Center of the Republic of Kazakhstan)

51.

Certificate type (general/for test environment/for operational environment)

52.

Authorization on the service side (yes/no)

53.

Authorization method

54.

55.

Password

56.

Posting with a client (yes/no)

57. Customer of the service

58.

Name of the organization

59. Network parameters and service schemes

60. Test environment

61.

In the unified transport environment of government agencies (yes/no)

62.

Outside the unified transport environment of government agencies (yes/no)

63.

VPN tunnel data (shared/separate)

64.

Information about the VPN Gateway

65.

The public Peer IP address of the system

66.

Is there a VPN tunnel for this system? (yes/no)

67.

Hosting by the digital Government operator (yes/no)

68.

The public IP address of the system

69.

Port

70.

Protocol

71. Operating environment

72.

In the unified transport environment of government agencies (yes/no)

73.

Outside the unified transport environment of government agencies (yes/no)

74.

VPN tunnel data (shared/separate)

75.

Information about the VPN Gateway

76.

The public Peer IP address of the system

77.

Is there a VPN tunnel for this system? (yes/no)

78.

Hosting by the digital Government operator (yes/no)

79.

The public IP address of the system

80.

Port

81.

Protocol

82.

Service schemes

83.

XSD (.zip)

84.

Request example (.xml)

85.

Response example (.xml)

Appendix 3 to the Rules for the Integration of Digital objects of the Digital Government

The act of testing and commissioning the integration service

Download

Participants in information interaction:

Name of the owner of the integration service:

Name of the initiator of the integration service:

Digital systems:

The digital system of the owner of the integration service:

The digital system of the initiator of the integration service:

Testing Services:

Name of the service:

The service key:

10.

Conclusion:

11.

Test scenario:

12.

Decision based on test results:

13.

Cybersecurity compliance test reports:

14.

Date of transfer to an industrial environment:

Appendix 4 to the Rules for the integration of digital objects of "Digital governance"Form

Requirements for interaction with the integration service

Validation of the X.509 certificate includes the following checks::

1) the validity period of the certificate;

2) Certificate chains;

3) revocation of the certificate;

4) checking the business identification number of the organization for affiliation.

Description and formats of the values of the properties and settings of the object (hereinafter referred to as properties) in the framework of interaction with the state service for access control to personal data.

In order to interact with the services providing personal data, the verification token is checked by the digital government gateway.

The sender needs to specify two properties objects in the request.

The public key and the generated verification token are provided by the government's personal data access control service.

In case of unsuccessful validation of the public key and verification token, the sender will receive an informative error from the digital government gateway and the request sending process is interrupted.

Download

Array

Required value of the key field

Field type key

Field type value

Mandatory

Description

Properties

kdp_public_key

xsd: string

Yes

The public key for accessing the data in the verification token

Properties

kdp_token

xsd: string

Yes

Generated verification token

Synchronous service performance and reliability requirements

Download

№

Controlled indicator

Limitation

Maximum request processing time for synchronous interaction

up to 60 seconds

Average request processing time

10 seconds

Peak load

2000 requests per second

Rated load

1,500 requests per second

Average operation time without failures

365/7/24

Time to restore working capacity

3 hours

Asynchronous service performance and reliability requirements

Download

№

Controlled indicator

Limitation

Maximum request processing time for asynchronous interaction

The time to provide a result on an asynchronous service request depends on the implementation of each integration service.

Peak load

100 requests per second

Rated load

70 requests per second

Average operation time without failures

365/7/24

Time to restore working capacity

3 hours

Appendix 5 to the Rules for the Integration of digital objects of "Digital Governance"

Form

Application for connection to the integration service

Download

1. The owner of the integration service

Name of the organization

Individual identification number/Business identification number

4. Integration Service client

Name of the organization

Individual identification number/Business identification number

The basis for connection

The connection foundation file

Joint order

10.

Pilot Project Order (yes/no)

10.1

Validity period of the pilot project order

10.2

The file of the pilot order

11.

Full name of the responsible person

12.

Contact phone number of the responsible person

13.

Email address of the responsible person

14. The customer's digital system

15.

Name of the digital system

16.

System login

17.

Password (test environment)

18.

Password (operating environment)

19.

Digital System Transport Signature Public Key Certificate (issued by the National Certification Center of the Republic of Kazakhstan)

20.

Cybersecurity compliance test reports (.doc, .docx, .pdf, filled in when organizing access to the service on the operating environment of the digital government gateway, the external digital government gateway)

21. Test environment

21.1

In the unified transport environment of government agencies

21.2

Outside the unified transport environment of government agencies

21.2.1

VPN Tunnel Data

21.2.2

Information about the VPN Gateway

21.2.3

Tunnel type (general/operating environment)

21.2.4

The public Peer IP address of the system

21.2.5

Is there a VPN tunnel for this system?

21.3.

Hosting of the digital government operator

22. A productive environment

22.1

In the unified transport environment of government agencies

22.2

Outside the unified transport environment of government agencies

22.2.1

VPN Tunnel Data

22.2.2

Information about the VPN Gateway

22.2.3

Tunnel type (general/operating environment)

22.2.4

The public Peer IP address of the system

22.2.5

Is there a VPN tunnel for this system?

22.3

Hosting of the digital government operator

23. Electronic service

24.

Name of the service

25.

The service key

26.

Service interaction mode

27.

Service format

28.

Indicates whether there is message routing.

29.

Route key

30.

The name of the URL of the service accepting requests (test environment)

31.

URL of the service accepting requests (test environment)

32.

The name of the URL of the service accepting requests (operating environment)

33.

URL of the service accepting requests (operating environment)

34.

SSL certificate (issued by the National certification Center of the Republic of Kazakhstan)

35.

Certificate type (general/test environment)

Appendix 6 to the Rules for the Integration of Digital objects of the Digital Government

An agreement on the use of integration services by owners or owners of non-governmental digital systems for the provision of public services

"___" ____________ ____ year

_____________________________ (name of the government agency) (_________________) ( the name of the public service), hereinafter referred to as "Party 1", on the one hand, and __________________________( name of the organization), hereinafter referred to as "Party 2", and _____________________________ ( name of the state body), hereinafter referred to as "Party 3", collectively referred to as the "Parties", have entered into this Agreement on the Use of Integration Services (hereinafter referred to as the Agreement) as follows.

Chapter 1. Scope of application

Appendix 6 to the Rules for the Integration of Digital objects of the Digital Government

An agreement on the use of integration services by owners or owners of non-governmental digital systems for the provision of public services

"___" ____________ ____ year

Chapter 1. Scope of application

1. This Agreement defines the level of service when using the integration service of Party 1 in order to ensure the availability of public services provided in electronic form, the activities of government agencies and the acceptance of obligations by Party 2 for the uninterrupted provision of public services through external platforms. At the same time, the indices of accessibility of the integration service are established, and also Party 1 ensures the availability of the integration service at the stage of industrial operation in accordance with the established accessibility index.

Chapter 2. Definitions and abbreviations

2. The following basic concepts are used in this Agreement:

1) AC SD is an automated "Service Desk" system designed to publish incidents and display the progress of execution;

2) ECM – Unified monitoring System;

3) resource – a mobile application or portal used to provide public services;

4) Digital Monitoring System for the provision of public services is a digital system designed to automate and monitor the process of providing public services, including those provided through the Government for Citizens State Corporation.

Chapter 3. Content of the Agreement

3. Side 1:

Ensures that service providers enter data into the digital monitoring system for the provision of public services on the stage of provision of public services in accordance with the procedure established by the rules for entering data into the digital monitoring system for the provision of public services on the stage of provision of public services approved by Order of the Acting Minister of Transport and Communications of the Republic of Kazakhstan dated June 14, 2013 No. 452 (registered in the Register of State Registration of Regulatory Legal Acts acts for No. 8555).

4. Side 2:

1) ensures the connection of non-governmental digital systems used for the provision of public services to the digital monitoring system for the provision of public services;

2) creates its own operational cybersecurity center and ensures its functioning or acquires the services of an operational cybersecurity center from third parties in accordance with the Civil Code of the Republic of Kazakhstan, and also ensures its interaction with the National Cybersecurity Coordination Center;

3) respects confidentiality and provides protection, does not disclose or transfer to third parties, does not publish personal data and confidential information provided to the service by Party 1, except in cases provided for by the legislation of the Republic of Kazakhstan;

4) Provides technical support;

5) to use the integration service(s), confirm the popularity of your resource by having a mobile application in marketplaces;

6) ensures the continuity of public services provided on its resource, provided that all services of other participants in integration interaction are available.;

7) provides users with biometric identification tools when using a mobile application or uses the biometric identification service of the Ministry of Artificial Intelligence and Digital Development of the Republic of Kazakhstan for authorization and signing of documents;

8) before the public service is put into commercial operation on an external platform, it provides a demonstration of the public service to the authorized body, the owner of the integration service and the service provider;

9) provides a public service within the time period established by a subordinate regulatory legal act defining the procedure for its provision.

5. Side 3:

In case of non-compliance by the parties with the requirements of this Agreement, it takes measures to disable the services used for the provision of public services, informing the participants in the implementation of the integration service.

6. The Parties are understood as:

Party 1 – authorized body, developer of a regulatory legal act in the field of public services;

Party 2 – a third-party organization, second-tier banks that organize the acceptance of applications for the provision of public services;

Party 3 – Ministry of Artificial Intelligence and Digital Development of the Republic of Kazakhstan;

Sides:

6.1 ensure uninterrupted operation and availability of integration services and receive messages from digital facilities year-round (except for scheduled, unscheduled upgrade work, technical failures of hardware, communication channels and inoperable services due to problems on the part of digital systems of government agencies);

6.2 SHTSP, SHTSP operate in an industrial environment around the clock and receive messages from digital objects on an ongoing basis, with the exception of technological interruptions;

6.3 The time for receiving the message of the ADC, the ADC does not exceed one minute from the moment it is received via the universal synchronous channel and the asynchronous channel. The response time for a request on an asynchronous channel depends on the implementation of each integration service.;

6.4 technological interruptions in the work of the integration service are negotiated and agreed upon by the Parties 3 (three) business days before the start of their implementation (by default, technological interruptions occur at night from 21:00 to 6:00, as well as on weekends and holidays);

6.5 for the purpose of testing, the participants in the interaction ensure the operability of the test environment of digital objects.;

6.6 in case of technical necessity, the digital facility is rebooted, which is notified to the administrators of other digital facilities, in the form of a telephone message or by e-mail, indicating the time of technical work.;

6.7 if the Parties do not take appropriate measures to correct technical errors in information interaction as soon as possible, the digital government operator disables the relevant integration service of the Owner of the integration service or suspends the connection of Party 2, informing the participants in the implementation of the integration service.;

6.8 in case of malfunction of communication channels, scheduled maintenance work on communication lines is carried out by communication service providers, the time limit for troubleshooting the malfunction is determined by the provider's regulations.;

6.9 implement measures to protect digital objects;

6.10 take measures to comply with the Uniform Requirements in the field of Information and Communication Technologies and Cybersecurity, approved by Government Decree No. 832 dated December 20, 2016;

6.11 comply with the legislation of the Republic of Kazakhstan in the field of digitalization, personal data and their protection, cybersecurity and the clauses of this Agreement.

7. Interactions of the parties:

7.1 the basis for the performance of any services stipulated in the Agreement is:

1) request to resolve the incident;

2) the task of executing scheduled work;

3) registration of Requests (Applications) occurs when receiving Requests from Party 1 and (or) Party 2 when registering messages in the ECM and service management in the AC SD.

4) schedules and the scope of planned work are specified in the relevant incident/change/request management process policies for the services of Party 1;

5) when requesting personal data, the subject or his legal representative gives (withdraws) consent to the collection and processing of personal data through the state service for access control to personal data.

8. The accessibility index.

Calculation: The accessibility index is calculated using the formula given below.

The formula consists of:

I – the service availability index, %;

T is the period of possible availability of the service, hours;

P is the period of unavailability of the service*, hours.

*Unavailability of the service is downtime during which authorized users are unable to access resources, information, and services provided by digital systems. It consists of failures of digital systems, planned and unplanned work carried out with the shutdown of digital systems.

The formula for calculating the availability of digital systems is as follows:

(T-R)/T*100= XX %

8.1 The accessibility index of each service is calculated independently by the Owner of the integration service for further publication on their resources.

Chapter 4. Notification

9. Any notification that one party sends to the other party in accordance with this Agreement is sent on purpose, with additional transmission by e-mail or fax.

10. The notification takes effect after delivery or on the specified effective date (if specified in the notification), whichever is later.

Chapter 5. Resolution of disputes

11. Party 1 and Party 2 shall make every effort to resolve, through direct negotiations, all disagreements or disputes arising between them under or in connection with this Agreement.

12. If, after such negotiations, Party 1 and Party 2 are unable to resolve the dispute under this Agreement, either Party may request a resolution of this issue in accordance with the legislation of the Republic of Kazakhstan.

Chapter 6. Other conditions

13. The term of this Agreement comes into force from the moment of signing by the Parties and is valid until its termination.

14. Any amendments and additions to this Agreement shall be made in the same form as the conclusion of this Agreement, through the signing by the Parties of an additional agreement(s) to this Agreement.

15. This Agreement is drawn up in Kazakh and Russian languages in two copies. All copies are identical and have the same legal force. Each of the Parties has one copy of this Agreement in Kazakh and Russian languages. All annexes to this Agreement are an integral part of it.

16. In the part not regulated by this Agreement, the Parties are guided by the legislation of the Republic of Kazakhstan.

17. This Agreement may be terminated by agreement of the Parties or on the initiative of one of the Parties if the other Party fails to comply with the terms of this Agreement.

Appendix 7

towards the Rules of Digital Integration

objects of "digital

governments"

Form

Application for updating the integration service

Download

1. The owner of the integration service

Name of the organization

Individual identification number/Business identification number

Serivis key

Purpose of the service

Interaction mode

Name of the digital system

8. The digital system of the owner of the integration service

The name of the digital system of the owner of the integration service

10.

System login

11.

Password (test environment)

12.

Password (industrial operation environment)

13. Test environment

13.1

In the unified transport environment of government agencies

13.2

Outside the unified transport environment of government agencies

13.2.1

VPN Tunnel Data

13.2.2

Tunnel type (shared/test environment)

13.2.3

Information about the VPN Gateway

13.2.4

The public Peer IP address of the system

13.2.5

Is there a VPN tunnel for this system? (yes/no)

13.3

Hosting by the digital Government operator (yes/no)

14.

The public Peer IP address of the system

15.

Port

16.

Protocol

17. A productive environment

17.1

In the unified transport environment of government agencies

17.2

Outside the unified transport environment of government agencies

17.2.1

VPN Tunnel Data

17.2.2

Tunnel type (general/operating environment)

17.2.3

Information about the VPN Gateway

17.2.4

The public Peer IP address of the system

17.2.5

Is there a VPN tunnel for this system? (yes/no)

17.3

Hosting by the digital Government operator (yes/no)

18.

The public Peer IP address of the system

19.

Port

20.

Protocol

21.

Comment on the changes online

22. Electronic service

23.

Indication of message routing (yes/no)

24.

The name of the URL of the service accepting requests (test environment)

25.

URL of the service accepting requests (test environment)

26.

The name of the URL of the service accepting requests (operating environment)

27.

URL of the service accepting requests (operating environment)

28.

SSL certificate (issued by the National certification Center of the Republic of Kazakhstan)

29.

Certificate type

30.

Authorization method

31.

32.

Password

33.

Type of security

34.

XSD

35.

Request example

36.

Response example

Appendix 8 to the Rules for the Integration of Digital objects of the Digital Government

Form

Request for updating the connection to the integration service

Download

1. The owner of the integration service

Name of the organization

Individual identification number/Business identification number

The service key

Purpose of the service

Interaction mode

The name of the digital system of the owner of the integration service

8. Customer of the service

Name of the organization

10.

Individual identification number/Business identification number

11.

The basis for connection

12.

Full name of the responsible person

13.

Contact phone number of the responsible person

14.

Email address of the responsible person

15. The digital system of the customer of the service

16.

Name of the digital system

17.

System login

18.

Password (test environment)

19.

Password (operating environment)

20.

Certificate of the public key of the transport signature system (issued by the National certification center of the Republic of Kazakhstan)

21.

Certificate type (general/test environment)

22.

Cybersecurity compliance test reports

23. Test environment

23.1

In the unified transport environment of government agencies

23.2

Outside the unified transport environment of government agencies

23.2.1

VPN Tunnel Data

23.2.2

Tunnel type (shared/test environment)

23.2.3

Information about the VPN Gateway

23.2.4

The public Peer IP address of the system

23.2.5

Is there a VPN tunnel for this system? (yes/no)

23.3

Hosting by the digital Government operator (yes/no)

24. Operating environment

24.1

In the unified transport environment of government agencies

24.2

Outside the unified transport environment of government agencies

24.2.1

VPN Tunnel Data

24.2.2

Tunnel type (general/ operating environment)

24.2.3

Information about the VPN Gateway

24.2.4

The public Peer IP address of the system

24.2.5

Is there a VPN tunnel for this system? (yes/no)

24.3

Hosting by the digital Government operator (yes/no)

25.

The public IP address of the system

26.

Port

27.

Protocol

28.

Comment on the changes online

29. Electronic service

30.

The service key

31.

Service interaction mode -

32.

Service format

33.

Indicates whether there is message routing.

34.

The service provides personal data

Appendix 9 to the Rules for the Integration of Digital objects of the Digital Government

The scenario of using a transport signature

1. The scenario of receiving a message using a transport signature by the gateway of the "digital government" (hereinafter referred to as the MCP), used in the interaction of digital objects:

1) The ADC verifies the message (authorization, validation of the message packet, transport signature of digital objects);

2) The MCP signs the message with a transport signature;

3) The SRC transmits a signed message to the external gateway of the "digital government" (hereinafter referred to as the SRC) (when interacting with digital systems outside the unified transport environment of government agencies);

4) The high-speed transmission system transmits a message to a digital object (when interacting with digital systems outside the unified transport environment of government agencies).

2. The scenario of receiving a message using the transport signatures of the ADC and the calling party:

1) the sender signs the message with a transport signature and sends it to the MCP;

2) The MCP verifies the compliance of the business identification number indicated in the electronic digital signature of the legal entity entered into the system during the registration of the digital object;

3) The MCP checks the transport signature for validity or revocation.

3. The scenario of using the mTLS mutual authentication mechanism:

1) In the process of mutual TLS authentication, the sender and the ADC exchange X.509 certificates issued by the national certification center of the Republic of Kazakhstan.;

2) the sender and the MCP validate the certificates received;

3) Upon successful mutual TLS authentication, an authenticated secure connection is established.

4. Verification token verification scenario in the framework of interaction with the state service for access control to personal data:

1) The ADC checks for the presence of kdp_token and kdp_public_key in the request (in the properties array);

2) The ADC validates the kdp_token and kdp_public_key;

3) The ADC compares the sid parameter inside the verification token and the service id field as part of the request;

4) The SCP verifies the disconnection of the verification token in the state service for access control to personal data;

5) in case of successful completion of all checks, further processing of the request is carried out, including its transfer to the integration service.

Appendix to the Order of the Deputy Prime Minister - Minister of Artificial Intelligence and Digital Development of the Republic of Kazakhstan On July 1, 2026 No. 368/NK

List of expired orders

1. Order of the Acting Minister of Information and Communications of the Republic of Kazakhstan dated March 29, 2018 No. 123 "On Approval of the Rules for the Integration of Electronic Government Informatization Facilities" (registered with the Ministry of Justice of the Republic of Kazakhstan on April 19, 2018 No. 16777);

2. Order of the Minister of Digital Development, Defense and Aerospace Industry of the Republic of Kazakhstan dated April 22, 2019 No. 48/NK "On Amendments and Additions to the Order of the Acting Minister of Information and Communications of the Republic of Kazakhstan dated March 29, 2018 No. 123 "On Approval of the Rules for the Integration of Electronic Government Informatization Facilities" (registered with the Ministry of Justice of the Republic Kazakhstan, April 26, 2019, No. 18588);

3. Order of the Acting Minister of Digital Development, Innovation and Aerospace Industry of the Republic of Kazakhstan dated July 31, 2019 No. 183/NK "On Amendments and Additions to the Order of the Acting Minister of Information and Communications of the Republic of Kazakhstan dated March 29, 2018 No. 123 "On Approval of the Rules for the Integration of Electronic Government Informatization Facilities" (registered in the Ministry of Justice of the Republic of Kazakhstan on July 31, 2019, No. 19148);

4. Order of the Minister of Digital Development, Innovation and Aerospace Industry of the Republic of Kazakhstan dated April 29, 2020 No. 165/NK "On Amendments to the Order of the Acting Minister of Information and Communications of the Republic of Kazakhstan dated March 29, 2018 No. 123 "On Approval of the Rules for the Integration of Electronic Government Informatization Facilities" (registered with the Ministry of Justice of the Republic Kazakhstan, May 6, 2020, No. 20581);

1) The ADC checks for the presence of kdp_token and kdp_public_key in the request (in the properties array);

2) The ADC validates the kdp_token and kdp_public_key;

3) The ADC compares the sid parameter inside the verification token and the service id field as part of the request;

4) The SCP verifies the disconnection of the verification token in the state service for access control to personal data;

5) in case of successful completion of all checks, further processing of the request is carried out, including its transfer to the integration service.

Appendix to the Order of the Deputy Prime Minister - Minister of Artificial Intelligence and Digital Development of the Republic of Kazakhstan On July 1, 2026 No. 368/NK

List of expired orders

5. Order of the Minister of Digital Development, Innovation and Aerospace Industry of the Republic of Kazakhstan dated January 28, 2022 No. 21/NK "On Amendments to the Order of the Acting Minister of Information and Communications of the Republic of Kazakhstan dated March 29, 2018 No. 123 "On Approval of the Rules for the Integration of Electronic Government Informatization Facilities" (registered with the Ministry of Justice of the Republic of Kazakhstan 31 January 2022, No. 26688);

6. Order of the Minister of Digital Development, Innovation and Aerospace Industry of the Republic of Kazakhstan dated September 2, 2022 No. 307/NK "On Amendments and Additions to the Order of the Acting Minister of Information and Communications of the Republic of Kazakhstan dated March 29, 2018 No. 123 "On Approval of the Rules for the Integration of Electronic Government Informatization Facilities" (registered with the Ministry Justice of the Republic of Kazakhstan on September 9, 2022 No. 29478);

7. Order of the Minister of Digital Development, Innovation and Aerospace Industry of the Republic of Kazakhstan dated December 5, 2023 No. 603/NK "On Amendments and Additions to the Order of the Acting Minister of Information and Communications of the Republic of Kazakhstan dated March 29, 2018 No. 123 "On Approval of the Rules for the Integration of Electronic Government Informatization Facilities" (registered with the Ministry Justice of the Republic of Kazakhstan No. 33737 on December 7, 2023);

8. Order of the Acting Minister of Digital Development, Innovation and Aerospace Industry of the Republic of Kazakhstan dated July 26, 2024 No. 444/NK "On Amendments and Additions to the Order of the Acting Minister of Information and Communications of the Republic of Kazakhstan dated March 29, 2018 No. 123 "On Approval of the Rules for the Integration of Electronic Government Informatization Facilities" (registered in the Ministry of Justice of the Republic of Kazakhstan on July 31, 2024, No. 34838);

9. Order of the Minister of Digital Development, Innovation and Aerospace Industry of the Republic of Kazakhstan dated March 12, 2025 No. 104/NK "On Amendments to the Order of the Acting Minister of Information and Communications of the Republic of Kazakhstan dated March 29, 2018 No. 123 "On Approval of the Rules for the Integration of Electronic Government Informatization Facilities" (registered with the Ministry of Justice of the Republic of Kazakhstan 12 March 2025, No. 35804);

10. Order of the Minister of Digital Development, Innovation and Aerospace Industry of the Republic of Kazakhstan dated September 10, 2025 No. 465/NK "On Amendments and Additions to the Order of the Acting Minister of Information and Communications of the Republic of Kazakhstan dated March 29, 2018 No. 123 "On Approval of the Rules for the Integration of Electronic Government Informatization Facilities" (registered with the Ministry of Justice of the Republic Kazakhstan, September 13, 2025, No. 36831).

Constitution Law Code Standard Decree Order Decision Resolution Lawyer Almaty Lawyer Legal service Legal advice Civil Criminal Administrative cases Disputes Defense Arbitration Law Company Kazakhstan Law Firm Court Cases Declaration Decree Order Resolution Decision Report Conclusion Statement Conclusion Convention Contract Memorandum Methodology Norms Note Rules Program Charter Charter Article Commentary Resolution Regulations Protocol Draft Program Rules Messages