Personal Information and Data Processing

KAI Privacy Policy

This Privacy Policy is issued by VN TECH LTD (the “Company”, “we”, “us” or “our”). It explains how personal information is processed in connection with KAI and how you may obtain information about that processing, manage your information and exercise applicable rights. Read it together with the information for the features you use, notices from your organisation and the applicable service documents.

First effective: 6 September 2026Revised: 10 September 2026Version: 1.1

Overview of personal information processing

We process information for providing the Services, maintaining security, performing contractual obligations and meeting applicable legal requirements. We do not sell or rent personal information or use it for cross-app advertising tracking. Essential account and transaction processing, optional device features and content processed on an enterprise customer’s instructions have different purposes and conditions. Disabling notifications, signing out, closing an account and deleting historical records also have different effects. The following sections explain information categories, recipients, international processing, retention criteria, request procedures and relevant limitations. This overview does not replace the complete Policy.

1. Scope, service provider and processing roles

1.1 Services covered

The Company provides the KAI iOS and Android applications, the workspace at hongkong.kai.com, and directly related account authentication, access management, capacity-market, order, execution, asset, funds-ledger, fulfilment, metering, API credential, notification and customer-support features. These are collectively the “Services”. KAI services are operated in Hong Kong. Our mailing address and contact channels appear in section 17.

This Policy covers relevant processing when you visit these pages, apply for or use an account, act for an organisation, access an enabled feature, or submit service or personal information requests. The information involved depends on the client, account permissions, product version and business relationship. Listing a category or circumstance does not require every visitor to provide that information and does not mean every feature is available to that visitor.

1.2 Personal information and business records

Personal information means information relating to an identified or identifiable individual, subject to the definitions of personal data and related concepts under applicable law. An organisation name, capacity specification or aggregate market figure may not identify a person by itself. If it is linked to an account, contact details, an operator or other identifying material, the relevant information is treated accordingly. Replacing a name with a number does not necessarily anonymise a record.

1.3 Responsibilities of the Company and enterprise customers

Where we determine the purposes and means of processing for account administration, service operation, security, reconciliation and responding to requests, the Company undertakes the corresponding responsibilities of a data user, controller or personal information handler under applicable law. Where an enterprise customer determines those purposes and means for employee or end-user information entrusted to KAI, we may provide processing services under the applicable contract. Roles depend on the actual activity and agreement, rather than a single general label in this Policy.

If an organisation supplies your account, its administrator permissions, internal retention arrangements, employee notices and other rules may also apply. You may ask the organisation about those arrangements. You may still contact us directly about processing for which the Company is responsible. Read this Policy with the Terms of Service, User Agreement and applicable data-processing documents. None of those documents removes rights that cannot lawfully be excluded.

1.4 Independent third parties

Independently operated websites, applications and model services, and sharing, communications or file tools that you select, process information under their own rules. A link to KAI does not establish that a third party acts on our instructions. Its role in a particular delivery must be determined from the actual service relationship.

2. Information categories, circumstances and necessity

2.1 Account and contact information

When you apply for access, authenticate or manage an account, the relevant services may process your registered email address, name or display name, avatar URL, user identifier (UID), email-verification status and account creation and update times. Email and account identifiers establish the identity relationship, support necessary communications and locate relevant records. Without necessary identification details, an account may not be established or recovered. Available changes to display information depend on the account interface.

2.2 Authentication, security and organisation information

Authentication and security services may process protected password-verification representations, session identifiers, authorisation tokens, scopes, consent records, login times, IP addresses, browser or device types, regions inferred from network addresses and security events. If you use additional security features, they may also process passkey public keys, authenticator types, two-factor verification status, protected TOTP secrets and recovery credentials. These support verification and protection against impersonation. The mobile application and workspace do not thereby receive every security record held by the authentication service.

Organisation services may process organisation or project names, membership roles, invitations, administrative authorisations, access status and changes. These determine which account a person may enter, which resources they may see and which actions they may perform. Information supplied by an authorised administrator can affect available features. Successful authentication alone does not confer trading, funds-management or credential-management permission.

2.3 Orders, accounts and delivery records

Market and account features process account identifiers, agreement specifications, order side, quantity, price, time in force, request identifiers, fills, positions, available and reserved amounts, fees, funds movements, bills, capacity entitlements, delivery obligations, timestamps and related audit records. The records are connected to execute instructions, avoid duplicate processing, maintain consistent accounts, fulfil capacity and investigate discrepancies. One transaction may produce several corresponding records. Removing an item from a screen does not establish that all related records have been deleted.

2.4 API activity, request content and metering

When you use an enabled fulfilment API, the relevant services process the content actually submitted, together with model and region information, request and response identifiers, statuses, usage, metering results and delivery evidence. Request materials may also be associated with records through a digest or protected reference. Credential administration involves names, permissions, status, suffix identifiers and protected representations needed for verification. A complete newly created key is displayed once. Store it as directed and do not include it in an ordinary support description.

Input may contain personal information about you or other people. Select information that is necessary for your purpose, verify your authority to submit it and avoid unrelated identity documents, financial account details, complete passwords or confidential materials. Request-content, logging and retention arrangements for different model services must be assessed under the applicable service documents. A capacity reservation does not by itself specify the retention or model-training practices of every upstream service.

2.5 Devices, preferences, diagnostics and support

The Services may also process application and operating-system versions, language, time zone, access times, requested features, response statuses, network errors, performance and security events. Themes, watchlists, recent views, batch templates, demo choices and credential metadata may remain on the device. Descriptions, attachments, registered email addresses, UIDs, authorisation relationships and request-handling records supplied during support are also within the corresponding processing scope.

The current mobile application does not request camera or microphone permission and does not directly collect bank-card numbers, payment-card security codes or government-issued identity documents. If a future feature requires such information or permissions, specific disclosures and applicable authorisation will precede collection.

This is a feature-based classification, not a request that you submit every listed item together. Collecting additional information is not an objective in itself. If further verification or investigation is necessary, requested material should relate to the particular matter. Remove or obscure unrelated information about other people before sending an attachment.

3. Information sources and collection methods

3.1 Information you provide

You provide information when completing account details, confirming a service choice, submitting an order, creating credentials, calling a fulfilment service, sending an email or exercising a right. Copying, downloading and sharing are actions you initiate. The resulting copies may subsequently be stored by your device or chosen recipients under their own arrangements.

3.2 Information produced through operation

Network connections and service operation generate access, security and necessary diagnostic information when you visit public pages or use authenticated features. Accepting an order, executing it, changing funds, fulfilling capacity and metering usage generate the corresponding business records. Request and business-reference identifiers help relate the different stages of a matter and distinguish an executed instruction, a rejected instruction and an instruction whose outcome is not yet established.

Automatically produced information is not available for unrestricted use. Processing must still correspond to the purposes described here. For example, time and status recorded to trace a request do not become available for unrelated advertising simply because they are technical logs. Public-page access logs and authenticated account information may differ in nature and in how closely they are linked to an individual.

3.3 Organisations, authentication and delivery participants

An inviting organisation may provide membership, role and access information. Authentication services may provide verified identity information and session status. Capacity or model-service participants may provide acceptance, usage, errors and delivery results. Information obtained through these relationships should be limited to what is needed for the corresponding authorised feature, rather than all information held by the source.

3.4 Corrections and unnecessary submissions

If information supplied through your organisation or authentication service is inaccurate, use the relevant account facility or contact an authorised administrator. If its source is unclear, describe the field and problem to us so that the appropriate channel can be identified. Historical orders and account records may require a reconciliation or correction procedure that retains necessary evidence of what occurred at the time.

We do not require an address book, complete photo library or precise location for ordinary page browsing. The current mobile application does not request those permissions or cross-app tracking permission. If you voluntarily put such information in a support email, model input or shared file, that is a separate submission whose necessity you should consider.

4. Purposes, applicable grounds and automated checks

4.1 Accounts and service performance

We use necessary identity, contact and organisation information to establish and manage service relationships, verify access, restore valid sessions, handle activation or change requests and provide permissions appropriate to each user. As applicable, processing relies on entering into or performing a contract, meeting a legal obligation or another available lawful ground. Where a person acts for an organisation, the relationship between that organisation and the Company must also be considered.

For orders, funds, delivery and metering, we process instructions and related records to validate conditions, accept requests, establish outcomes, update entitlements, calculate usage and charges, provide bills and resolve discrepancies. Orders, fills and accounting records are not merely optional display preferences. If information genuinely necessary for these functions is not provided, the corresponding operation may be unavailable.

4.2 Security, fault investigation and protection of rights

Login and access records, errors, request statuses and permission changes help identify compromised credentials, unusual access, duplicate instructions, excessive usage and abuse, investigate failures and improve reliability. Processing takes account of necessity, sensitivity, impact and applicable requirements. Where a legitimate-interest basis is available and relied upon, the interest must also be assessed against individual rights. A general reference to service improvement does not authorise every possible use.

Necessary records may continue to be processed to investigate account discrepancies, handle complaints, meet applicable audit or other obligations, and establish, exercise or defend legal claims. Information retained for a specific dispute should be relevant to that dispute. Ending a service relationship does not automatically end recordkeeping obligations already incurred; section 9 explains the corresponding limits.

4.3 Optional features and consent

Biometrics, system notifications and user-initiated sharing depend on your choices and, where required, operating-system permission or applicable consent. Declining an optional feature affects that feature rather than automatically cancelling an existing order, delivery obligation or account entry. Where consent is the processing ground, you may withdraw it without affecting the lawfulness of processing undertaken before withdrawal.

Reading, acknowledging or accepting this Policy should not be construed as blanket permission for undisclosed purposes, all future recipients or all sensitive-information processing. Before undertaking processing incompatible with the original purpose, we will provide any additional notice, obtain required consent or meet another applicable lawful condition.

4.4 Automated validation and review

Requests are automatically checked against identity, permissions, balances, positions, gate status, price protection, usage and security conditions. A failed condition may prevent access or execution. Temporary network or service faults can also make an account read-only. Such outcomes do not by themselves establish unlawful conduct or constitute a final account sanction.

If the information used in a check appears inaccurate or an automated outcome appears inappropriate, provide the request identifier, time and displayed message to seek an explanation or investigation. Where applicable law provides special rights for solely automated decisions with legal or similarly significant effects, you may exercise those rights, including an applicable right to human review. An explanation need not disclose security details that would enable circumvention or compromise other people’s rights.

5. Device permissions, local storage and user actions

5.1 Biometric verification

Biometric verification in the mobile application is off by default. If you enable it, the operating system performs verification. KAI receives results such as success, failure, cancellation or unavailability; it does not obtain, store or upload facial or fingerprint templates. Device support, enrolled verification methods and system prompts are managed by the operating system.

Local biometrics and server-side authorisation serve different purposes. One verifies an action on a device; the other determines whether the account may perform the instruction. Passing device verification does not revive an expired session, add trading permission or remove a security restriction. Available alternatives after disabling biometrics depend on the actual interface.

5.2 Notifications and device display

System notifications are off by default, and the application requests permission when you choose to enable them. The current mobile application can display local notifications using order, fulfilment, capacity or security events it has received and update its setting from the permission status returned by the operating system. Disabling notifications does not reverse completed operations or automatically remove associated business records from the in-app notification centre.

The operating system may display information on a lock screen, in notification history or on associated devices. Adjust preview and display settings for your environment. Arrival and display may depend on device conditions. Check account records for the actual status of orders, funds and delivery.

5.3 Mobile and browser storage

On supported platforms, the mobile application stores authorisation credentials in operating-system protected storage. Account display information and preferences use local storage, with account-specific watchlists, recent views, templates, settings and API credential metadata separated by account. The workspace instead maintains login through necessary first-party session cookies and may store account preferences in the browser. Browser pages do not keep KAI Auth authorisation tokens in ordinary preference storage.

Signing out clears the active session and corresponding active state, but does not delete all server-side information. Some local preferences may remain for later use by the same account. Clearing website data, clearing application data and uninstalling an application have different effects. Device backups, system keychains and other operating-system copies may have independent lifecycles that require management through system settings.

5.4 Clipboard, downloads and sharing

If you copy a UID, order reference, delivery identifier or newly created key, the application writes the chosen material to the system clipboard. Exporting or sharing may provide a file to a downloads folder, system share sheet or selected application. These actions can move information outside access controls on the KAI page. Verify the recipient and avoid sending complete keys, other people’s information or internal account records to an inappropriate location.

The current mobile application does not request contacts, precise location, photo-library or cross-app tracking permission for basic account and capacity services. If a future separate feature needs a new permission, its purpose and the applicable choice will be explained for that feature. Listing device information here is not treated as permission for undisclosed device access.

6. Market information, organisation access and model requests

6.1 Market information and account information

Market views may show agreement specifications, price, quantity, direction, execution time and market status. Public or shared market data is designed to exclude registered email addresses, personal names and UIDs. Within an account, orders, executions, positions, funds, delivery and permission records need to be connected so that services can be performed accurately and account changes explained.

Quantity, timing or other details can nevertheless be combined with outside information to identify a participant in a particular context. The absence of a displayed name is therefore not a reason to assume identification is impossible. Redact information according to need when forwarding a screenshot or export containing account references, detailed activity and timestamps.

6.2 Organisation administration

Authorised administrators may manage membership, roles, projects, applications and access, and view information necessary for their administrative, security or reconciliation responsibilities. Administrative roles differ. Membership alone does not confer access to all members’ assets or credentials. An organisation remains responsible for the purposes it determines and for corresponding notices to its members.

6.3 Delivery-related disclosures

Where a supplier, model-service provider or enterprise customer participates in delivering specified capacity, we may supply information necessary to execute requests, verify delivery, meter usage, reconcile fees or investigate disputes. Recipients must not use this information for unrelated marketing or to build their own advertising profiles. Disclosure should relate to that particular delivery. Providing one component does not give a participant unrestricted access to unrelated accounts.

Model inputs and outputs are different from market data. The former may include actual text or other submitted materials; the latter describes market activity. A statement that market data excludes names cannot establish that a model request contains no personal information. Assess the selected model, relevant service documents and organisational requirements before submitting personal or confidential content.

6.4 Statistical information and limits on purpose

Aggregated or appropriately de-identified information may be used to understand capacity consumption, performance and market operation. Only results that cannot reasonably identify individuals are treated as anonymous. Numbered records that remain traceable to an account remain subject to relevant protections. We do not attempt to re-identify individuals in anonymised information. Statistical or diagnostic needs do not independently authorise unrelated uses of request content.

This Policy does not grant general permission to use customer content for model training. Where a service includes a separate data-use choice, the purpose, affected content, recipients and means of choice must be explained in the corresponding documents. Model-training, request-retention or dedicated-deployment arrangements are governed by the actual applicable service conditions disclosed to you, rather than inferred from a product name or capacity specification.

7. Sharing, processing providers and disclosure

7.1 General principles

We do not sell or rent personal information and do not share it for cross-context behavioural advertising. Disclosure to another entity should correspond to a particular service, user instruction, legal obligation or protection of rights and be restricted to what that purpose requires. A need to transfer information between features or departments does not give every person access to it.

7.2 Service components and processing providers

KAI authentication, access control, markets, accounts, delivery, metering and support exchange service information within applicable permissions. Cloud computing, hosting, network, storage, security, communications, support, audit and professional service providers may process information to perform their assigned functions. We require applicable confidentiality, purpose, security, retention and deletion obligations protection no less than the level described in this Policy, and processing in accordance with relevant arrangements.

These recipient categories do not mean that every category receives every user’s information or that mentioning a third-party brand establishes a confirmed commercial relationship. Ask us through section 17 if you need details of the processing categories and safeguards for a particular service. Where law requires separate identification of a recipient or consent to disclosure, the applicable requirements govern.

7.3 Organisations and delivery participants

We may provide member and business-administration information to appropriately authorised organisation administrators, and fulfilment, metering, reconciliation and dispute information to suppliers, model-service providers or settlement participants involved in the specified service. A recipient that independently determines a purpose bears corresponding obligations for that activity. A recipient acting on instructions remains subject to the relevant processing limits.

7.4 Recipients selected by you

Information is provided according to your explicit export, sharing, email or other recipient-selection action. Check the file and scope of authority. If you ask the Company to assist in supplying account information to another person, we may verify identity and authorisation to prevent disclosures caused by impersonation or an incorrect contact address.

7.5 Legal processes, security and business changes

Relevant information may be disclosed where necessary to respond lawfully to binding requests, protect users or the public, investigate fraud or attacks, enforce valid agreements or address legal claims. The authority, scope and lawfulness of a request should be considered; a request from a third party is not itself a reason to release all information.

Necessary information may be provided to relevant advisers, counterparties or successors during a merger, reorganisation, financing or transfer of a business or assets, subject to confidentiality and continued protection. Material changes in responsibility or purpose require applicable notices and other procedures. A business change does not automatically extinguish existing personal information obligations.

8. Processing locations and international safeguards

8.1 Determining processing locations

KAI operations, enterprise customers, authentication, infrastructure and individual delivery participants may involve different regions. Information may therefore be stored, accessed or processed outside your country or region. Locations depend on the enabled services, chosen delivery region, providers and applicable contract. They cannot be established solely from a page’s language, domain, company mailing address or device location.

A region in a capacity agreement identifies a delivery specification. It does not necessarily locate all account authentication, support, security logs and backups within that region. If your business has residency, overseas-access or model-processing requirements, check the applicable arrangements before supplying information or enabling the relevant feature.

8.2 Legal and organisational safeguards

International processing can involve protection rules that differ from those where you are located. We apply the lawful transfer conditions and safeguards required for the actual processing relationship. Where required, this includes relevant notices, separate consent or other authorisation, assessments or procedures, and applicable contractual, access-control, transmission-protection and other measures.

Describing categories of safeguards does not mean that every transfer uses the same legal mechanism. It is not a statement that the Company holds any certification, adequacy finding or particular regulatory approval. Information subject to local-storage requirements or additional restrictions must be handled in accordance with those requirements.

8.3 Information about particular arrangements

You may identify the account, model or delivery service and the information category about which you need details, and ask us about the relevant locations and safeguards. Distinguish request content, account details, metering, security logs and support attachments where possible: their processing paths can differ because their purposes differ.

Enterprise customers with additional regional restrictions should define their scope, supported services and processing arrangements through the applicable contract. This Policy does not create an unconfigured regional-isolation capability. If a service cannot meet a restriction you have specified, avoid submitting restricted material until an appropriate arrangement exists. International processing does not remove applicable rights to information, consent withdrawal or other protections.

9. Retention, historical records and deletion

9.1 Retention criteria

We retain personal information for the period needed for the purposes explained and applicable obligations. Relevant considerations include the continuing account and contractual relationship, connections with outstanding matters, sensitivity, disputes and limitation periods, financial or audit requirements, security investigations and backup rotation. Categories need not share one period. Session expiry is not a deletion schedule for transaction information.

This Policy does not apply one fixed number of years to every record or use an unspecified legal need to justify permanent retention of everything. You may ask about the criteria for a particular category and matter. Continuing retention on a lawful basis must remain restricted to the necessary categories, scope and purposes, with unrelated access and reuse limited.

9.2 Lifecycles of principal categories

Accounts, organisations and authentication
Information is retained for the account or organisational relationship and provision of the relevant service. Sessions, short-lived tokens, verification codes and temporary challenges expire according to usage, expiry and revocation rules. Related security evidence may remain for its separate purpose after a credential stops working.
Orders, fills, funds and ledgers
Records are retained for execution and reconciliation and, after the relationship ends, for applicable financial, tax, contractual, audit, dispute and security needs. A zero balance or a hidden historical item does not mean those obligations immediately end.
Delivery, metering and evidence
Records support performance of the specified capacity service, usage and fee reconciliation, delivery-discrepancy investigation and related obligations. Content, digests, references and metering results are distinct records; their scope depends on the applicable service arrangement.
Support, security and rights requests
Records are retained for resolving the matter, checking identity, investigating events and demonstrating actions taken. Subsequent retention is assessed against relevant legal and dispute needs.
Device copies and backups
Preferences may remain until overwritten or cleared. Exported, copied or independently received material follows its own storage mechanisms. Information removed from an active system may remain in protected backups until the applicable rotation cycle ends.

9.3 Corrections and record integrity

Accounting or audit records with historical-integrity requirements may need a correction, reversal or linked explanation rather than replacement of the original event. This preserves a verifiable history without removing your right to correct inaccurate personal information. Where appropriate, access restrictions, de-identification or separation can prevent necessary historical records from being used for unrelated purposes.

9.4 Deletion, anonymisation and restricted retention

When a processing purpose has ended and no lawful basis for further retention remains, we delete or irreversibly anonymise information according to its nature and the system. Temporary separation or restricted access is not completed deletion. If law, open orders, delivery, balances, disputes or investigations require temporary retention, we will explain the affected categories and reasons as appropriate.

Remaining backup copies are access-restricted and addressed through rotation or clearance. Any restoration for recovery, security or legal reasons must still respect effective deletion and purpose restrictions. Copies that you retain in email, downloads, clipboard tools or receiving applications require management in those locations.

10. Individual rights, choices and request handling

10.1 Requests you may make

Depending on applicable law, information type and the relationship, rights may include being informed, access and copies, correction or completion, erasure, restriction, objection to particular processing, portability, withdrawal of consent and an explanation or review of certain automated decisions. You may also complain to a competent privacy or data-protection authority. Rights do not apply under identical conditions in every region and circumstance. This Policy does not reduce rights provided by law.

Existing account and device settings can manage editable information and preferences. If no interface control is available, a result is disputed or several service components are involved, use the email and telephone channels here. Inability to sign in does not prevent a request, although an appropriate identity-verification method is necessary.

10.2 Request details and identity verification

Where possible, write from your registered email address and identify your UID, request type, affected information or dates, and an available reply channel. An initial request need contain only what is necessary to locate the account and understand the matter. It need not include complete transaction archives, identity documents, passwords, verification codes, recovery codes or API keys.

We may check registered contact details, account status or other necessary information in proportion to sensitivity and potential impact. Any further material requested should relate to the particular verification need; identity checks are not a reason to expand collection without purpose. An authorised representative should explain the relationship and provide sufficient evidence of authority as required by applicable law.

10.3 Investigation, response and objections

We examine the processing concerned, determine the applicable scope and respond within the period required by applicable law. An unclear request may require clarification. Where an extension is both legally permitted and necessary, we will explain the reason and arrangements. If a request cannot be fulfilled in whole or part, we explain the basis to the extent permitted and identify available review or complaint channels.

Providing copies requires protection for other people’s information, legally protected confidential material, security information and other legitimate interests. Correcting business history may require comparison with original receipts and subsequent changes rather than simply overwriting the current display. Exceptions must be assessed under applicable law; complexity alone is not a sufficient reason to refuse a request.

10.4 Effects of withdrawing consent and changing settings

Withdrawing consent for an optional feature or particular purpose stops the corresponding processing as applicable. It does not change the lawfulness of earlier processing or independently required processing under another lawful basis. Notifications, device logout, local-storage removal and account closure affect different scopes, as explained in sections 5, 9 and 11.

We do not discriminate against you for lawfully exercising privacy rights. Reasonable identity checks, protection for other people or necessary service conditions should remain proportionate. Failure to supply genuinely necessary information may make a corresponding feature unavailable, but must not be treated as punishment for exercising a right.

11. Account closure, sign-out and outstanding matters

11.1 Request channels

Request closure through the account-closure application in KAI mobile settings or write from your registered email to beidou@kai.com. Include the registered address, UID and action requested. Closing a KAI business account, leaving an organisation, ending a device session and deleting particular information are different requests. Email remains available if the in-app entry cannot be used.

11.2 Initial contact and scope

The service team will contact your registered email within 72 hours after receiving the request to verify identity and explain the next steps. This is an initial-contact target, not a promise that closure, funds handling and deletion of all personal information will be completed within 72 hours. Where several services, organisational relationships or identity problems are involved, the scope and authority of the request must first be established.

Closing a KAI business account and removing every identity record in a separate authentication service can involve different processing scopes. Shared sign-in does not mean one request automatically covers every system. We will explain the available actions and necessary additional channels for the actual relationship so that a sign-out message is not mistaken for termination of all services.

11.3 Outstanding business and organisation arrangements

Open orders, balances, reserved items, active capacity, delivery obligations, billing disputes, security investigations or required records may need attention during closure. Reconciliation should accurately end the relationship without causing unrelated information to be retained indefinitely.

For an organisation-authorised account, individual membership, enterprise entitlements and business records held by the organisation must be distinguished. A member’s departure does not automatically erase legitimate enterprise accounting records. Equally, internal administration is not a reason for an organisation to expand personal information use without limit. Representatives must explain the scope they are authorised to address.

11.4 Effects of completion

After closure, the business account cannot continue signing in or initiating new relevant activity. Information no longer required is deleted or irreversibly anonymised. Material that must remain on a legal or other lawful basis is restricted as described in section 9. Closure does not reverse completed fills, make an actual delivery cease to have occurred or remove the need to reconcile outstanding amounts.

Signing out, uninstalling an application or clearing browser data affects the corresponding device and does not replace a closure request. Retain any completion records you need as evidence, and separately review device, email and downloaded copies. Remove copies no longer required through the systems in which they are held.

12. Information safeguards and security incidents

12.1 Protective measures

We apply technical and organisational safeguards appropriate to the processing and its risks, including transmission protection, protected credential storage, authorisation checks, account and organisation separation, input and response boundary checks, logging, audit, backups and change controls. Passwords and security factors use encryption or irreversible verification representations according to their purpose. Personnel and service access should be limited to assigned responsibilities.

Protection concerns storage, access, permitted instructions and the handling of abnormal conditions. Invalid authentication, insufficient permission or an inability to refresh essential records reliably can restrict features or make them read-only. Live-account results must not be replaced by demo information that could lead a user to act on an inaccurate picture of the account.

12.2 Measures for users and organisations

Protect your device, registered email, passwords, recovery materials and API keys, use trusted software and networks, and assign permissions according to organisational requirements. Do not put complete credentials in screenshots, public code, chats, ordinary emails or support attachments. Identify a key by its name, suffix or creation time when that is sufficient to locate it without revealing the secret.

Check the origin of unfamiliar login or biometric prompts. If a device is lost, an email account is compromised or a key may have leaked, revoke affected sessions or credentials where possible and contact us promptly. Preserve request references and times for suspicious instructions that may already have executed, and avoid repeated submission that could increase the impact.

12.3 Investigation and notification

We assess the nature and impact of an incident, investigate its cause, limit risk, establish the information potentially affected and take appropriate remedial action. Where law requires notification to affected people or authorities, we notify in accordance with those requirements. Investigations may require preservation of access and operation evidence, which remains subject to access and purpose restrictions.

No system can guarantee absolute security in every circumstance. This does not remove the Company’s legal protection obligations. Responsibility and remedies depend on actual causes, applicable law and valid contracts. Submit necessary vulnerability or incident details through the security contact email, without accessing unrelated accounts or publishing other people’s information to demonstrate an issue.

13. Cookies, local technologies, analytics and communications

13.1 Necessary session technologies

The authenticated workspace uses first-party session cookies for login and security, with Secure, HttpOnly and SameSite protections. A cookie’s session identifier and server-side account state together identify valid access; the cookie does not grant browser pages permission to arbitrary accounts. Blocking or removing necessary cookies may sign you out, interrupt authentication or require a new session.

Browser local storage may hold language, theme and other preferences. Cookies, preferences, downloads and server records have different lifecycles. Removing one type does not necessarily remove the others. Browser settings can inspect or clear website data, but on a shared device you should also sign out and review downloaded copies.

13.2 Public pages and advertising

The current public legal and information pages do not set advertising or analytics cookies or load third-party advertising networks. Website infrastructure may still produce necessary network logs to serve requests and protect security. An absence of advertising cookies therefore does not imply that visiting a page involves no processing at all.

The current mobile application has no advertising or third-party behavioural analytics SDK. It does not read advertising identifiers for targeted ads, conduct cross-app advertising tracking, sell personal information or share it for cross-context behavioural advertising. There is consequently no separate advertising-tracking opt-out control at present. If different practices are introduced, relevant disclosures and legally required choices will be provided before activation.

13.3 Service and optional communications

Registered email, in-app information or applicable channels may carry verification, order, funds, fulfilment, security, service-change and support messages. Keep contact information usable. Turning off device push notifications does not stop every necessary service communication or alter the actual status of an order or delivery.

If marketing communications are offered in future, they will be distinguished from necessary service messages and accompanied by applicable subscription or unsubscribe arrangements. Maintaining an existing account does not require accepting unrelated marketing. Withdrawing an optional subscription should not remove important service information owed to you. Mentioning possible communication channels here does not claim they are all currently enabled.

14. Regional application and additional rights

14.1 Conditions of application

Privacy rules depend on your location, the processing activity, the relationship with the Company and other applicable conditions. This section supplements earlier provisions only where the relevant law applies. It does not state that every KAI service is available or authorised in every region, or that one jurisdiction’s terminology or processing grounds apply unchanged elsewhere.

14.2 Hong Kong

Where the Personal Data (Privacy) Ordinance applies, you may make data-access and correction requests as provided by law. Applicable notices explain collection purposes, whether providing information is necessary and the consequences of not providing it, recipient categories, and contact channels for access and correction. Requirements concerning accuracy, retention, security, transparency and access govern relevant activities. Guidance or complaints may be directed to the Office of the Privacy Commissioner for Personal Data, Hong Kong.

14.3 Mainland China

Where the Personal Information Protection Law and related rules apply, relevant disclosures identify the handler, purposes, methods, categories, retention periods or criteria, and means of exercising rights. Sensitive information, disclosure to other handlers or international provision may require additional notice, separate consent or other lawful conditions. Applicable rights include access, copying, correction, completion, deletion and explanations of processing rules. A person lawfully acting for another should identify the basis of that authority.

14.4 European Economic Area and United Kingdom

Where relevant data-protection law applies, rights may include access, rectification, erasure, restriction, objection, portability, withdrawal of consent and complaints to a competent supervisory authority. Special safeguards apply to relevant solely automated decisions with legal or similarly significant effects. Grounds, transfer mechanisms and exceptions depend on the particular activity. Listing rights does not mean that every activity relies on consent.

14.5 Relevant United States states

Where a state privacy law applies and its conditions are met, you may request information, access, deletion or correction, exercise applicable opt-outs, and receive protection against discrimination for exercising lawful rights. Rights concerning targeted advertising, sale or cross-context advertising sharing depend on the relevant statutory definitions. The Company does not currently undertake the personal information sales or advertising sharing described above. Applicable appeals or representative requests may be raised through our contact channels.

14.6 Coordinating requests

If you are unsure which right applies, describe the information you wish to access, correct or delete and the relevant region. We will address the actual relationship. You need not resolve a complex legal classification before raising a concern. Where different laws impose different requirements, the Company follows applicable obligations, and no provision removes statutory rights that cannot be waived by contract.

15. Minors and service eligibility

15.1 Intended users

KAI is intended for enterprise and professional users with the required capacity and authority. Account use is not offered to people under 18, and we do not knowingly collect children’s personal information. Organisation administrators should verify relevant age and authority requirements before inviting members. An organisation invitation does not dispense with those requirements.

15.2 Information supplied about others

Excluding minors from the intended audience does not make it impossible for a user to include information about a minor in a model request or support attachment. Avoid submitting unrelated children’s information. Where a proposed activity involves such information, first establish your authority, applicable service conditions and protection obligations. Ordinary account approval is not special permission to process it.

15.3 Reporting and handling concerns

If you believe a minor has provided personal information without appropriate authority, or an ineligible person has received an invitation, contact us through section 17. Initially provide only enough information to locate the matter. Do not send complete identity documents or unrelated information about a child in an initial email.

We will investigate and take action appropriate to applicable law and the circumstances, which may include restricting access or deleting information that should not be retained. A guardian or other legally entitled representative may need to verify identity and authority to avoid disclosure to an unauthorised person. Verification should remain limited to handling the request.

16. Revisions, notices and access to documents

16.1 Types of revisions

We may revise this Policy as features, actual processing, contact details or legal requirements change, identifying the revision date and version at the top. Changes may concern information categories, purposes, recipients, choices or procedures. Formatting, clarification and translation corrections should be distinguished from substantive changes to purposes or rights according to their actual content.

16.2 Material changes

For changes significantly affecting privacy interests, we will provide the notice required before they take effect through the website, in-app information, registered email or another appropriate channel, and obtain renewed consent or complete other procedures where law requires. Updating a page does not itself authorise an entirely new use of previously collected information.

If you do not agree to new processing that depends on voluntary consent, you may refuse or withdraw through the available means. Any resulting effect on a particular feature will be explained as appropriate. Processing independently required by law or existing obligations remains limited to its own basis and scope. An ambiguous reference to continued use does not replace consent that the law specifically requires.

16.3 Versions and languages

You may save or print this Policy and ask us for a historical version relevant to a particular period. Identify the date and service when asking about past activity so that descriptions from different versions are not confused.

Simplified Chinese, Traditional Chinese and English texts are intended to explain the same arrangements consistently. Report an apparent translation or wording difference through the contact channels so that it can be checked and clarified. Your language selection does not change legal rights, the service actually used or the underlying processing facts.

17. Contact details and request materials

17.1 Service provider and mailing address

VN TECH LTD
Mailing address: 1312 17th Street, Suite 769, Denver, Colorado 80202, United States
KAI service operations: Hong Kong

17.2 Personal information and customer support

For access, correction, deletion, account closure, complaints or questions about this Policy, contact beidou@kai.com. Customer support telephone: 400 108 2026. Sensitive account matters may require verification through the registered email or another appropriate procedure. A telephone enquiry does not by itself replace identity verification.

17.3 Useful information for a request

  1. Identify the request type, such as access, correction, deletion of particular information, account closure, an explanation of processing or a complaint.
  2. Provide the registered email and UID. If the UID is unavailable, explain what account identification is available and why access is unavailable.
  3. Identify the service, information category, date range and desired outcome. For an order or delivery, use the relevant identifier and time where possible.
  4. If acting for an organisation or another person, explain your identity, authorisation and the scope you may address.
  5. Provide a secure, usable reply channel and cooperate with necessary, proportionate identity checks.

Do not send passwords, one-time codes, recovery codes, complete API keys, unrelated identity documents or large unfiltered transaction archives by ordinary email. If further information is necessary, we will explain its relevant scope and appropriate submission method. If impersonation or credential compromise may be ongoing, identify the security concern in the subject and disable affected credentials where feasible.

17.4 Related documents

The User Agreement and Terms of Service explain use conditions. The Product Introduction and Help Centre explain capacity rules, procedures and common issues. Each addresses its own subject and does not replace this Policy’s disclosures about personal information and rights requests.