KAI Help Center

1. Registration, admission, and first use

1.1 Use an official entry point

Enter through hongkong.kai.com or an official KAI client. Follow the KAI Auth registration or sign-in flow, email verification, and necessary security checks. Verify the source of a page before entering credentials. Do not provide a password through an unfamiliar link or an unverified window. If an identity account already exists, use its normal sign-in process rather than create another account because an incorrect entry point did not work.

1.2 Distinguish identity from business access

Registration establishes identity information, sign-in verifies the current identity, and business admission determines access to a particular live account and its functions. Production service uses invitation or approval arrangements. Registration, verified email, or a page displayed after sign-in does not prove that orders, funds, or APIs have been enabled. For pending approval, insufficient permission, or an unavailable capability, record the UID and complete message and ask the relevant organisation or service team to check. Demo mode must not be used to process a live business requirement.

1.3 First-operation checklist

1. Verify the account. Check the UID, account information, and environment, especially on a shared device that may contain another person's session.
2. Check readiness. Confirm admission and valid market and account information, with no unresolved read-only, stale, or unavailable state.
3. Check time. Review device time, timezone, and the agreement's fulfilment date and timezone. Distributed teams should communicate explicit times.
4. Read the documents. Review the Product Overview, Terms of Service, User Agreement, and Privacy Policy, including capacity, metering, charges, and restrictions.
5. Prepare the requirement. Identify model, version, context, region, hour, and quantity before selecting an agreement and previewing an order.
6. Verify completion. After the first submission, inspect the receipt and related records to understand the relationship between an order, its executions, and a position.

1.4 Changing devices or accounts

Watchlists, recently viewed items, and batch templates saved locally may not appear after a browser, phone, or account change. This does not establish that real positions or funds were removed. Reconcile real business against the records for the current UID. Local preferences and page selections are conveniences, not server business states. If the UID is unexpected, sign out and authenticate with the intended identity before proceeding.

For organisational use, confirm that the operator is authorised to act for the account and knows whom to contact about procurement, technical access, and accounting. Do not assume that possession of a device or an existing signed-in session establishes the authority to submit an instruction.

2. Live and demo environments and data validity

2.1 Identify the current environment

Live mode displays actual market and business records for an admitted account. Demo mode explains the interface; the funds, orders, executions, positions, and delivery records shown there create no live rights. A user must select demo mode explicitly. Before submitting an operation, review the environment indicator, UID, account state, and data timestamps together. A familiar layout alone does not establish that the page is operating with live data.

2.2 When a live account is unavailable

Missing configuration, interrupted connectivity, an expired identity, or a permission error should produce the relevant unavailable, reconnecting, or read-only state. These conditions must not replace live records with demonstration funds or executions. If an authenticated live account displays demo content, stop orders and other business operations, record the page address, event time, environment indicator, and UID, and report that live-account access is displaying demonstration content. Do not use the demo balance to infer the location of real funds or submit repeated trades to test recovery.

2.3 Interpret data states

Loading or a dash

No valid value has yet been obtained. The price, quantity, or balance is not necessarily zero.

Retained or stale data

The screen shows the last available information while the current state is unresolved. Review its timestamp and wait for valid new information.

Read-only

Some information can be viewed, but conditions for safely changing business state are unmet. Follow the stated reason instead of attempting to bypass the restriction.

Not configured or not enabled

The connection conditions or account capability are absent and may require service-team review. Repeated refreshing cannot replace configuration or admission work.

2.4 Verify recovery

After recovery or another sign-in, establish that complete current account information has been obtained, selected-agreement data is refreshed, and original pending requests have been checked. Moving prices do not independently prove that the account is writable. A restored balance display does not mean that an earlier unknown order failed. Resolve outstanding items before making further changes.

Label screenshots and internal reports with their environment. Demo records may be used in training but should not be presented as evidence of live orders, funds, delivery, or performance. Retaining the environment and time in a support screenshot helps identify the issue while unnecessary personal information and credentials should be removed. Where a report combines several screenshots, indicate whether each was taken before the interruption, during the unavailable state, or after recovery so that their values are not treated as simultaneous.

3. Selecting agreements and understanding capacity and time

3.1 Review each specification

Model and version

Confirm the model and version actually delivered. Another version within the same family should not be treated as an identical service.

Context limit

Check the supported context and input constraints. A listing of 128K, 256K, or another size does not mean all models share that limit.

Fulfilment region

Confirm the required service region. Positions in another region should not be assumed to contribute to this region's allowance.

Date, hour, and timezone

Use the full date, clock hour, and displayed timezone, including cross-day and daylight-saving considerations where relevant.

Gate close

The current product description closes new orders 60 minutes before fulfilment. The agreement listing and server determination control actual handling.

3.2 Understand one lot

The current lot description is 1,000,000 Weighted TPM continuously available in each 60-second window of the specified hour. Additional lots increase the window limit accordingly. This is not an hourly cumulative token balance that can all be consumed in any one minute. Two lots, for example, provide a corresponding 2,000,000 Weighted TPM window limit under the applicable rules; unused capacity in a previous window does not double the next allowance. Use the numbers and rules confirmed for the specific agreement when reconciling actual use.

3.3 Estimate a workload

Apply the selected model's weight using input tokens + model weight × output tokens. Consider request distribution, retries, and shared use by different applications. Cache hits and reasoning tokens must be counted according to the applicable rules rather than another provider's practices. Estimate peak and ordinary windows separately; an hourly average can conceal a concentrated burst that exceeds an individual window's allowance.

3.4 If an agreement cannot be selected

1. Check whether the date has passed and whether the hour is gate-closed or fulfilled.
2. Confirm that the model, region, and context filters match the intended requirement.
3. Check valid offers and sellable quantity. Distinguish missing supply information from an absence of currently executable offers.
4. Review whether stale market data, permissions, or account state restricts the action.
5. If the condition remains unclear, send the agreement code, time, and message to support instead of substituting another specification without review.

Record the actual delivery window after obtaining capacity. Unused allowance does not automatically move into the next hour; another period requires its own agreement and available conditions. Allow time for transmission and confirmation near gate close. A device countdown cannot guarantee that an instruction will be accepted before the server closes the market.

4. Single orders, confirmation, and quantity management

4.1 Submission procedure

1. Select the intended agreement and recheck its full specification and delivery time.
2. Inspect the market timestamp, bid and offer depth, and available account funds or sellable lots.
3. Select buy or sell, enter the quantity, and choose an available order type.
4. For a limit order, enter a permitted price. The principal market currently quotes HKD per lot in HKD 0.5 increments, subject to the agreement's actual range.
5. Select a supported time in force and review the estimated amount, price condition, and other notices.
6. Submit once when the details are correct. Retain the original request identifier and await or query the result.

4.2 Common options

Limit

Applies a specified price constraint. Without sufficient qualifying counterparty interest, the order may remain unexecuted or execute partially.

Market

Uses available counterparty prices under the applicable rules. The actual average price may differ from the reference shown on screen.

GTC

The unexecuted remainder continues until execution, cancellation, expiry, gate close, or another termination under the rules.

IOC

Executes what is immediately available and does not retain the remainder.

FOK

Requires immediate execution of the full quantity or no execution. Support for the combination and its final state depend on the confirmation and server receipt.

4.3 Price and quantity errors

If input is rejected, first check permitted increments, bounds, and whole-lot requirements, then review agreement and account conditions. Insufficient available funds may reflect reservations against other orders. Sellable quantity can be lower than the total position because of open sale orders or other obligations. Check Assets rather than repeatedly submitting smaller test orders to infer a balance. Estimates, actual consideration, and final billing figures can represent different measurements and should be read under their respective labels.

4.4 Submission is not execution

A submitted state means an instruction has been sent or entered processing, not necessarily that the entire intended position has been acquired. Review cumulative execution, remaining quantity, average price, and state in Orders or Fills. One order can have multiple fills. Treatment of any unexecuted remainder depends on time in force and market rules. Closing a confirmation, leaving a page, or signing out does not automatically cancel an accepted server instruction.

If submission is disabled, examine the precise reason, including read-only state, stale quotes, insufficient permission, gate close, or invalid input. After recovery, review the confirmation again, especially price and quantity. Values entered before the restriction may no longer reflect current conditions.

5. Batch orders, templates, and partial results

5.1 Generate a basket

1. Confirm the model, region, and context specification for the batch plan.
2. Select start and end dates, hour range, weekdays, and lots per hour.
3. Generate the basket and inspect agreements and quantities for every day, including skipped gate-closed, fulfilled, or unavailable periods.
4. Remove unnecessary items and check agreement count, total lots, individual quotes, and estimated consideration.
5. Review quote timing and account state, then read the price-protection and individual-execution explanation before confirming.
6. Inspect every result after processing, distinguishing executions, failures, unprocessed items, and unknown outcomes.

5.2 Use templates correctly

The current workspace stores up to eight account-scoped local rule templates. They save selection rules, periods, and quantities rather than effective orders. They do not lock a quote or reserve capacity. Reuse still requires generation and inspection of actual dates; the same rule can produce different results on another day. Templates may be unavailable after clearing browser storage or changing devices. This does not affect real business records already held by the service.

5.3 After price protection activates

The current tool applies a 3% price-deviation safeguard. Before submission, it compares the basket total calculated from current offers with the quote-snapshot estimate. During item processing, it continues to compare amounts calculated from the submitted items’ corresponding quotes and quantities with estimates for those same items. A deviation beyond the threshold stops remaining submissions, so protection may activate before any item is submitted. Successful submission does not establish execution, and these comparison amounts are not final executed charges. Check order and execution receipts separately for fills, positions and changes in funds. The safeguard does not reverse completed fills, guarantee the entire basket or keep final execution costs within a guaranteed range.

For a basket containing ten hours that stops partway through, identify precisely which hours have positions, which clearly failed, which were never submitted, and whether any result remains unknown. An aborted overview does not mean that nothing executed. Do not immediately resubmit all ten items. Additional orders should cover only targets whose lack of execution has been established and which remain eligible, after a fresh confirmation.

5.4 Stale quotes and interruptions

If quotes are stale, missing, or updating, await a valid snapshot and reconsider the estimate. If connectivity fails during execution, preserve basket and request information and inspect account orders and fills after recovery. Rebuilding a basket is not a receipt query. For an unexpected result, include each relevant agreement code and outcome in a support request; a total alone normally cannot identify omitted or duplicated items.

The batch tool reduces repeated entry but does not replace business review. Multi-day and recurring plans require individual-hour checks. A template name or total number of lots is not evidence that the entire intended schedule was covered. Keep the original plan and actual item results distinct when handing a batch operation to another colleague.

6. Executions, cancellations, unknown outcomes, and identifiers

6.1 Read order details

Check original quantity, executed and remaining quantities, average price, reserved funds or lots, state, and relevant timestamps. An order can produce several fills, each with its own execution information. A weighted average across different prices can differ from the last fill's price. Establish procurement completion from actual cumulative execution and position changes, not merely creation time or a submission message.

6.2 Cancel an unexecuted remainder

1. Locate the original order and verify the account and agreement.
2. Check that an unexecuted quantity remains and is eligible for cancellation.
3. Send one cancellation request and retain its identifier.
4. After server confirmation, review final state, actual remainder, and release of related funds or lots.
5. If further execution occurred while cancellation was pending, reconcile executed and cancelled portions separately. Cancellation is not a refund or reversal of completed fills.

6.3 Pending or unknown state

A timeout, closed page, or interrupted connection can prevent a client from receiving a result even when the server accepted the instruction. For pending or unknown outcomes, query the original request identifier and compare orders, fills, and account records. Reloading is not cancellation; creating another similar order is not a query. Do not send a new replacement instruction before establishing the original result.

Record time, UID, agreement code, and request identifier, and follow the system's query for that request. Continue tracking the same identifier after sign-in recovery. If the outcome remains unresolved, ask the service team to investigate. Related redacted evidence may be required, but complete passwords and API secrets are unnecessary. An explicit rejection, a confirmed cancellation, and an unknown result are different states and must be treated according to their actual receipts.

6.4 Common identifiers

Request identifier

Locates receipt and processing of an instruction, particularly after an interruption.

Order identifier

Locates an order, cumulative execution, remaining quantity, and state.

Fill identifier

Locates an individual execution. One order can reference multiple fills.

Agreement code

Connects model, region, period, and related position and delivery records.

These identifiers are not interchangeable. Name the identifier type in a query, retain its complete format and event time, and do not modify it or infer its meaning from appearance. Closing a dialog or dismissing a notification does not remove the corresponding server business record. If several operations were attempted, list their identifiers separately and specify which result remains uncertain. This prevents a confirmed receipt for one request from being incorrectly used to close a different unresolved request.

7. Account snapshots, read-only states, and recovery

7.1 Review a complete account view

Read the account overview, positions, orders, fills, delivery, funds, and bills with their snapshot and update information. Market and account synchronisation are different processes. An online market connection does not establish that balances are current, and visible account information does not prove that the selected agreement's book is ready. Check both account and market conditions before making changes.

7.2 Common reasons for read-only operation

Failed snapshot refresh

A new complete account record is unavailable. Retained information is for reconciliation.

Stale market or unready order book

Selected-market data is insufficient to confirm current conditions safely. Valid market information is required.

Changed permissions or account status

The operation is not authorised or the account has a restriction or freeze that must be addressed as indicated.

Maintenance or incomplete reconnection

The service cannot presently meet the conditions for changes. Another sign-in may not resolve it.

Device or interface limits

A client, device, or layout may restrict a particular function. Use the capabilities and entry points actually indicated.

7.3 Recovery sequence

1. Record the reason, last update time, and unresolved business requests.
2. Check connectivity and device time, retaining the complete error. Avoid repeated refreshing that adds requests.
3. Allow automatic synchronisation. If session expiry is indicated, sign in again through the official flow.
4. Verify the recovered UID and environment, and establish that complete new account records are available.
5. Recheck the selected agreement, market timestamp, and permissions.
6. Query original pending orders before reviewing a new operation.

7.4 Differences and local information

Missing watchlists, recently viewed items, or templates on another device are separate from whether real assets exist. If asset quantities or amounts differ from earlier observations, compare fills, reservations, releases, and bills for the same UID, currency, and period. Clearing all storage is not an accounting repair. It may remove useful diagnostic context and preferences while leaving the server ledger unchanged.

If balances, positions, and orders appear inconsistent, pause further changes and record the fields, snapshot times, and related identifiers for support. Two screenshots taken at different times do not alone establish an accounting error. Nor does an enabled button replace verification of account state. For a continuing issue, note whether the same difference persists after a complete refresh and whether it affects one agreement or the entire account. This gives support a precise observation without requiring speculative changes to funds or positions.

8. Fulfilment preparation, API credentials, and invocation issues

8.1 Before delivery

1. Find the required agreement in Delivery Rights and verify model, version, context, and region.
2. Check start and end times, current lots, and the allowance for each 60-second window.
3. Verify that API access is enabled. Market permissions or a position alone do not establish that every interface is usable.
4. Use the endpoint, model identifier, authentication method, and parameters in the official API material available to the account.
5. Within a valid window, perform limited verification using necessary authorised test information, and reconcile the result and usage with the expected account.

8.2 Create and protect credentials

A complete API secret is displayed once when created. Store it immediately in a controlled secrets-management system. Do not rely on screenshots for routine storage or send secrets in public code, page source, support email, or group messages. If the secret was not retained, use an available creation or rotation process; do not request that support email the old secret. If exposure is suspected, disable or rotate affected credentials from a trusted device and contact the service team about suspicious usage.

8.3 Investigate rejected requests

Authentication or permission failure

Check the credential's account, active state, and scope. Do not paste the complete credential into a support request.

Outside the fulfilment window

Check the actual date, timezone, and start and end times rather than a local task name.

Context exceeded

Check input and requested output against the model specification and adjust using the effective API documentation.

Capacity or rate limit

Inspect aggregate weighted use in the current window and shared use across applications. Reduce concentrated traffic and unbounded retries.

Model or parameter mismatch

Verify the model identifier, region, and request parameters instead of copying assumptions from another provider.

8.4 Reconcile usage and retries

Weighted TPM, request count, concurrency, and response time measure different things. A retry may create additional invocation and usage. Apply the actual rules rather than assume that no usage occurred because the original client did not show a result. Separate explicit rejection from an unknown result. Technical teams should retain identifiers and use limited, controlled retries appropriate to the error instead of concentrated repetition.

Unused allowance does not automatically roll over. Completion and cross-window measurement for requests accepted before the window ends follow the effective agreement rules. A fulfilment query should identify the agreement, window, request identifier, redacted error, and metering record. Complete business input is not normally necessary to establish the initial scope of investigation. Where several applications share capacity, include that fact so that their combined use can be considered.

9. Funding, reservations, bills, and correction enquiries

9.1 Deposits and withdrawals

Deposits and withdrawals currently require assistance from the service team. Use the registered email address to contact beidou@kai.com, or call 400 108 2026. Identify the UID, application type, and matters to be checked. Documentation, payment arrangements, and processing steps require formal confirmation. This Help Center does not provide self-service funding or withdrawal and does not mean an application is approved.

9.2 Why available funds decrease

The buyer prepays KAI in full on execution under the applicable amount, and an order may reserve available funds. A reduction can reflect reservations, executed consideration, charges, or a verified adjustment, which should be traced through the ledger. Total, available, and frozen balances have different meanings. Reservation of lots for a sale is also different from a debit of funds. KAI manages prepayment and settles with suppliers after fulfilment; subsequent price movements are not settled as cash differences.

9.3 Reconcile individual records

1. Match UID, currency, billing period, and query dates.
2. Locate related orders and fills, recording actual quantities, prices, and times.
3. Connect each operation to ledger movements, distinguishing reservations, debits, releases, fees, and adjustments.
4. Check whether cancellation was confirmed and whether an unexecuted remainder still reserves funds.
5. Compare delivery and billing records with those operations, retaining specific differences and identifiers.
6. Ask support to review the expected and observed amounts and comparison basis rather than send only a balance screenshot.

9.4 Corrections and reversals

If an incorrect posting or another difference is suspected, request review of the original record. A correction is different from new funding, a refund application, or an ordinary charge; it requires an identified original record, reason, and applicable procedure. The resulting records should connect the original operation with its resolution. Do not create another transaction to offset a suspected difference or treat removal of a screen entry as cancellation of a ledger fact.

Some support or administrative records contain a ledger sequence and fact ordinal identifying a specific fact within a record. These are not amounts, account UIDs, or order quantities. Supply complete identifiers exactly as displayed. Do not assume the ordinal is always zero or select one independently for reversal. Authorised personnel must establish the original fact and processing permissions through the formal accounting procedure.

9.5 Protect information

Verify payment information through established channels. An unfamiliar person's receiving account, a message asking for a verification code, or a request to control the device remotely is not authorised by this Help Center. Redact unrelated information from payment evidence while retaining necessary amount, timing, and business references. Ordinary email must not contain full passwords, recovery codes, or API secrets.

10. Sign-in security, device functions, and incidents

10.1 Interrupted sign-in and expired sessions

A session can end because of expiry, revocation, changed permission, a device security condition, or connectivity problems. Before signing in again, retain unresolved request identifiers. Use the official flow and verify UID, environment, and account records after recovery. Sign-in failure and order failure are separate events: a signed-out state does not mean an earlier order was cancelled. For persistent authentication errors, record the exact time, page, and complete message.

10.2 Biometrics

On supported clients and devices, the user enables biometrics and completes system verification as directed. Face or fingerprint templates remain with the operating system; KAI does not obtain them. Device authentication helps protect local access or sensitive actions but does not replace account permissions, admission, or server checks. Capabilities vary by device and browser. An absent biometric option is not evidence of an account-data problem.

10.3 Notifications

Enable notifications through the relevant client and system settings. They can provide order, fulfilment, capacity, or security notices, but visibility may be affected by permissions, connectivity, focus settings, power management, and application state. Missing a notification does not mean an order failed or fulfilment has not begun; inspect account records directly. Disabling system notifications does not delete in-application messages or end outstanding business. Test device notification behaviour where it is operationally relevant.

10.4 Suspected account or credential exposure

1. Stop entering secrets or performing sensitive actions on a possibly affected device.
2. Protect the account using a trusted device and official entry point, applying the revocation, rotation, or other controls actually available.
3. Retain discovery time, suspicious messages, and related request or order identifiers; inspect unusual business records.
4. Report through official support, describing the scope and measures already taken.
5. Do not send complete passwords, verification codes, recovery codes, or API secrets as evidence.

10.5 Shared devices and staff changes

Sign out normally after work on a shared device and protect downloaded records and screenshots containing account information. When staff leave or responsibilities change, review their access to credentials, business records, and automated tasks. Platform controls depend on actual account capability, while the organisation must also manage its own information and access. Shared personal credentials do not replace a clear business authorisation.

In support communications, check sender information and established contact channels. Independently verify any request for complete secrets or for disabling protections to handle funds before acting. Record what was requested without forwarding sensitive values to an unverified recipient. If an incident spans several accounts or devices, specify the known scope and distinguish confirmed observations from suspicions so that investigation can proceed on accurate information.

11. Common errors, targeted troubleshooting, and evidence

11.1 Excessive market requests, throttling, or 429

A market-data message indicating too many requests or 429 means the request encountered a rate or capacity-related restriction. It does not directly establish insufficient account funds or an order failure. Retain the message and time, stop repeated refreshing, reduce duplicate pages polling the same markets, and allow automatic synchronisation. For an application you operate, examine concurrency, polling, and retry behaviour instead of immediately repeating all failed calls. Follow instructions actually returned by the relevant interface.

Throttled market reads and exhausted inference allowance can arise in different parts of the service. Identify the page or request where the error occurred. Do not make another deposit, place another order, or switch accounts solely to address a market-read error. If it persists, provide affected markets, the time range, approximate number of active pages, and redacted errors so support can identify the scope.

11.2 Authentication failures, 404, or inaccessible pages

Check the official entry point, completeness of the address, network reachability, and device time. Avoid opening repeated authorisation flows. If the normal entry remains unavailable, record the address, client version, time and timezone, and full message. Do not send an unredacted callback link containing an authorisation code, session credential, or other secret parameter; preserve the necessary path while removing sensitive values.

11.3 Empty markets or no sellable capacity

Distinguish unloaded information from an actual absence of offers. Review environment, filters, model and region, data timestamp, and gate state. A heatmap's supply figure does not establish matching executable order-book depth, and historical fills do not guarantee present liquidity. If valid data remains empty, inspect filters consistent with the real requirement. Do not replace a required model or region without evaluating suitability.

11.4 Read-only, unknown outcomes, or amount differences

For read-only operation, follow section 7 on complete snapshots and permissions. For unknown results, use the original request process in section 6. For amounts, connect orders, fills, and ledger records as described in section 9. These cases have different recovery paths and should not all be treated by signing out, clearing storage, or resubmitting. Preserve original business information so the investigation retains its context.

11.5 Support evidence

Environment

UID, client or browser, page, live or demo mode, event time, and timezone.

Business object

Agreement code, request, order or fill identifier, affected window, and currency.

Observation

Complete error, expected and actual results, reproducible steps, and first and most recent occurrence.

Actions already taken

Whether synchronisation was allowed, sign-in repeated, network changed, or duplicate requests stopped, and what changed afterward.

Redacted evidence

Necessary screenshots and shareable records excluding credentials, unrelated personal information, and business input or output.

Keep follow-up information with the existing support correspondence. If scope increases or new funds, order, or security facts emerge, identify the new facts explicitly.

Separate confirmed observations from assumptions in the investigation record. State whether an operation was actually submitted, whether a receipt was obtained, and when information last refreshed. This helps support distinguish a screen message from a final result and gives colleagues sufficient context for a reliable handover.

12. Privacy requests, account closure, and formal contact

12.1 Understand information processing

Read the Privacy Policy for identity, account, order, fulfilment, metering, device, local-preference, and support information. Watchlists, recent items, batch templates, settings, and local API-key metadata are isolated by signed-in account. This local information is different from server business records. Clearing browser storage or uninstalling a client does not close an account or automatically remove records retained for lawful or necessary business purposes.

12.2 Access, correction, and other requests

Contact the service team from the registered email address, identifying UID, request type, information scope, and a contact method. Specify the period or fields involved where possible, rather than describe an account with outstanding business only as a request to delete everything. Proportionate identity verification may be necessary to protect the account and other persons' information. Rights, conditions, and processing follow the Privacy Policy and applicable law.

12.3 Account closure procedure

1. Organise necessary order, execution, billing, and delivery records and identify unknown outcomes.
2. Review open orders, positions, balances, fulfilment arrangements, and disputes, and stop automated tasks no longer required.
3. Apply from the registered email address with UID and contact information.
4. The service team will contact you through that email within 72 hours after receiving the request to verify identity and outstanding matters.
5. Address unresolved obligations under the confirmed procedure and use the final notice to establish closure.

The 72-hour period concerns initial contact. It is not a promise that closure, repayment, or deletion of all information will finish within that time. Legal retention, disputes, security, and accounting needs can require some records to remain under the applicable rules. A closure application does not itself cancel existing orders, stop fulfilment already underway, or remove outstanding obligations. Check those matters individually.

12.4 Formal contact details

The service provider is VN TECH LTD, and KAI service operations are in Hong Kong. General support and privacy requests can be sent to beidou@kai.com, or addressed through 400 108 2026. Correspondence address: VN TECH LTD, 1312 17th Street, Suite 769, Denver, Colorado 80202, United States.

Provide necessary and accurate information. Ordinary email must not include passwords, verification codes, recovery codes, or complete API secrets. Establish an appropriate submission method before supplying sensitive verification material. This Help Center explains procedures; rights and obligations should also be read with the applicable agreements and business confirmations.