Electronic Interaction and Digital Signature Regulations
Revision dated 2 November 2026 · Effective
The checksum is calculated from the exact UTF-8 bytes of the downloadable JSON, without a BOM or trailing newline.
Limited pilot aluber.limited-pilot/v1: email-only sign-in; orders, shipments and operational PDF delivery notes. Digital signatures and automated accounting are disabled. References to disabled capabilities below do not make them available in the pilot.
The Russian and Kazakh versions are prepared for owner adoption in the limited pilot, not as the result of independent legal review. This English translation is for reference only and is not used for acceptance. Preparing this text does not itself constitute owner adoption, publication or entry into effect.
These Regulations govern the exchange of digital messages and electronic documents through aluber, which is owned by "Aluber.kz" limited liability partnership (unofficial translation), BIN 261040020455, registered address: Republic of Kazakhstan, Zhetysu Region, Taldykorgan, 204 Abylai Khan Street, 040000.
These Regulations distinguish ordinary actions of an authenticated account, digital confirmations and electronic documents authenticated by a digital signature. Neither a login nor an OTP is described as a digital signature.
1. Types of electronic interaction
1.1. In production, a legally significant action in an authenticated session must preserve the specific user, organisation, role, basis of authority, server time, immutable content, result and checksum. Commercial agreement of an Order preserves a separate verifiable chain of such messages; active membership confirms only internal authorisation and does not replace a corporate power of attorney. An operational status log not linked to such a snapshot is not, by itself, treated as complete evidence of intention.
1.2. An OTP, confirmation button, push notification or email code is a digital confirmation. It may express intention in agreed processes, but does not ensure content immutability and is not a digital signature.
1.3. For the purposes of the Digital Code, an electronic document is a digital record whose authenticity, attribution and immutability are secured by a digital signature. A PDF without an associated digital signature is only a visual copy.
2. Platform documents
2.1. The Platform may generate:
- an Order and the history of agreement of its material terms;
- an electronic delivery note and its corrected revisions;
- an acceptance payload stating accepted quantities and discrepancies;
- a return act and the history of return decisions;
- a verification package containing the payload, hash, CMS, certificate and verification result.
2.2. aluber documents are not electronic invoices, accompanying waybills for goods or documents of another government system and do not replace them. Each party independently prepares mandatory forms.
3. Source accounting, time of preparation and copies
3.1. Until an accountant issues a written decision and the form is incorporated into the accounting policy, an aluber delivery note is an additional contractual record and is not represented as a source accounting document of the Supplier or Buyer.
3.2. If the parties approve it as a source document, it is generated at the time of the relevant business transaction or immediately afterwards and contains the mandatory particulars required by Article 7 of the Accounting Law: title and date, preparer and identification number, substance, quantitative and monetary measures, and the positions, full names and signatures of responsible persons.
3.3. A printable paper copy of an electronic source document is provided to a participant in the transaction and to an authorised government authority upon a lawful request; the ability to download a PDF does not remove the obligation to provide such a copy.
3.4. A correction to a source document is agreed by the participants, dated and confirmed by the signatures of responsible persons in the composition required by law. A new technical revision without the prescribed agreement and signatures is not, by itself, an accounting correction.
4. Canonical content and visual form
4.1. Before issue, the server generates canonical JSON containing the schema version, identifiers, parties, particulars, lines, quantities, prices, address and time. Key order is deterministic, and SHA-256 is calculated over the exact bytes.
4.2. Before a digital signature is created, the signatory is given an opportunity to review the content and expressly confirm signing. The signed envelope contains the document, its hash, the signature purpose and a one-time challenge.
4.3. The PDF contains the number, revision and SHA-256 and is created for reading and printing. If the PDF includes later logistics statuses, they are clearly separated from the immutable signed payload.
5. Creating and verifying digital signatures
5.1. Signing is performed using a tool compatible with the National Certification Authority of the Republic of Kazakhstan, without transferring the private key to the Operator. The user is independently responsible for safeguarding the key and must not transfer it to third parties.
5.2. The server accepts CMS only after trusted verification of the certificate, chain, validity period and revocation status, correspondence to the signed payload, the signatory's IIN and the BIN of the represented organisation.
5.3. The current digital-signature perimeter is intended only for legal entities and joint individual enterprises with an assigned BIN included in the signed production allowlist. An ordinary individual entrepreneur identified by IIN may use Orders, delivery notes, PDFs and acceptance without a digital signature; signing remains unavailable until a separate certificate, identifier and authority model is implemented.
5.4. Without a trusted authority-verification service of the Root Certification Authority of the Republic of Kazakhstan, creating and accepting digital signatures is completely unavailable in production. The internal owner role is only an additional access control and does not replace verification of authority under Article 61 of the Digital Code.
5.5. Before requesting an IIN, authority data or other personal data from a digital object of a government authority or government legal entity, the Operator separately classifies the data flow under Articles 8-1 and 10 of the Personal Data Law. If no statutory exception applies, the production request remains disabled until integration with the government personal-data access control service and preservation of its verifiable confirmation.
5.6. Once the service is connected, the time, identifier and response of the authority check are included in the evidence; a matching BIN in the certificate alone is insufficient. An error, timeout, stale result or mismatch with the fixed trust profile results in refusal to sign.
6. Signing the delivery note and acceptance
6.1. The Supplier signs the issued revision of the delivery note. The Buyer separately signs an acceptance payload that refers to the delivery-note hash and contains the quantity actually accepted and any discrepancies.
6.2. The Buyer's signature does not alter the Supplier's signed delivery note. Taken together, the documents show what was stated for handover and what was actually accepted.
6.3. A correction is documented as a new revision referring to the replaced revision, its hash and the reason. The previous revision and signatures remain available and are not overwritten.
7. Authority and delegation
7.1. Within the current pilot perimeter, only a user with the active internal owner role for the relevant organisation may sign or accept a document with a digital signature; users with the member role are not permitted to sign.
7.2. The internal role controls access to the function but does not replace the charter, an order, a power of attorney, an electronic power of attorney or authority verification through the service prescribed by law. The signatory is independently responsible for having a valid basis of authority.
7.3. Delegating signing to other users and storing the basis and term of their authority will become available only after a separate process and the authority-verification service are implemented. Revocation of internal access blocks new operations but does not delete records created previously.
8. Delivery, time and notifications
8.1. After successful recording, the document is technically available to the addressee in the account. The server-recorded time does not, by itself, prove the legal time of receipt by the addressee; that time is determined under the applicable contract and confirmed by a separate immutable delivery receipt. An SMS or email notification is supplementary unless the contract expressly provides otherwise.
8.2. Time is recorded by the server in UTC and displayed in the user's time zone; a time-stamping service is used to prove that a signature existed at a particular time where available and required.
8.3. An interface failure is not treated as a party's waiver of a right. The user reports unavailability to support, and the parties use the agreed backup channel.
9. Verification and preservation
9.1. Before digital signatures are enabled in production, the Operator provides the open signature-verification service without account login required by Article 61(4) of the Digital Code. It verifies the submitted electronic document or standalone evidence package, displays the verification result to the necessary extent, and does not require public disclosure of the document itself, an IIN or commercial terms.
9.2. A separate bearer-token QR check is only an optional privacy-safe lookup of a stored status and does not replace the mandatory open cryptographic-verification service. It is disabled by default; when the QR perimeter is disabled, the code leads to the authenticated account. A minimal QR response is not a fresh online certificate check as at the current date and does not disclose the parties, amounts, document numbers, IINs, certificate serial numbers or certificate fingerprints.
9.3. An authenticated party checks integrity, association of the stored CMS and the historical server-verification result in the account or using the exported package within the approved availability and export procedure.
9.4. A document party may separately download a PDF copy and a standalone JSON package containing the canonical payload and its exact bytes, CMS signatures, certificate data, hashes and stored verification results. The JSON package itself contains the format version and serves as a machine-readable manifest.
9.5. An electronic document must remain accessible and verifiable outside the Platform. The package format and independent-verification instructions are published and versioned before the production digital-signature perimeter is approved.
10. Retention and access
10.1. Electronic documents, signatures and evidence are retained immutably for the mandatory statutory period and in accordance with the approved schedule. Backups are located in Kazakhstan.
10.2. Before access is terminated, the Operator allows the party to export its own documents and communicates the period for which a read-only account or protected backup channel will remain available. The specific period and the access-restoration and bulk-export procedures are determined by the approved offboarding procedure and may not be shorter than required by law or a separate contract.
11. Challenges and compromise
11.1. A disputed signature, lost key or document error must be reported immediately to webberdyev@gmail.com and to the certification authority. The Operator preserves evidence, blocks new operations where there is a substantiated risk, and does not delete the disputed record.
11.2. The parties may use the government electronic-document verification service, independent expert examination and judicial remedies.
Related documents
Official legal sources
- Digital Code of the Republic of Kazakhstan, Articles 46–50 and 61–62
- National Certification Authority of the Republic of Kazakhstan
- Law of the Republic of Kazakhstan on Accounting and Financial Reporting
- Rules for Integration with the Government Personal Data Access Control Service
Links lead to official sources. This document is contractual language and does not reproduce legislation verbatim.