The digitalization of financial trading has enabled investors to access market data, manage their accounts, and execute trades more efficiently. At the same time, the growing range of financial products, increased price volatility, and accelerated dissemination of information have made investment decision-making more complex. For trading platforms, providing convenient access to trading functions is only a baseline requirement. The ability to clearly present product terms, transaction costs, and potential losses is equally important in shaping users’ assessment of the platform.
Options and contract-based products are subject to defined trading rules and carry a high degree of risk sensitivity. Differences in the underlying asset price, contract term, quotation method, and settlement conditions may materially affect the outcome of a transaction. Before making an investment decision, investors need to understand what they are trading, how orders are executed, what costs they may incur, and what may occur under adverse market conditions.
Automation tools have further changed the way trading information is accessed and utilized. Strategy signals and copy-trading functions can assist users in monitoring and executing specific trading approaches; however, their outputs remain dependent on strategy parameters, market data, and actual execution conditions. Historical performance does not guarantee future results, and automated execution cannot replace the user’s own assessment of risk tolerance. Accordingly, trading efficiency and risk disclosure should be given equal consideration within the same product workflow.
1.2 Project Positioning
Kinexys Ltd is positioned as a digital trading platform designed around options, contract trading, and strategy-following functionalities. The platform aims to establish an integrated user experience covering market information access, trading decision-making, and order management. From a product-design perspective, the platform should enable users to identify the relevant product category and understand its key rules before entering a trade, while also providing access to order records and account information after execution.
This positioning should be implemented through specific mechanisms. Product pages should clearly explain the underlying asset, contract term, and the methodology used to calculate potential gains and losses. The trading process should display quotations, applicable fees, and order confirmation details. Account pages should retain transaction and order records for users to review and reconcile. For strategy-following functions, the platform should also disclose the source of each strategy, applicable execution conditions, user-configurable restrictions, and the factors that may cause actual trading results to differ from strategy performance.
The long-term value of the project depends on the ability to establish consistent service standards across product information, trade execution, and risk management. Expanding functionality may provide users with greater choice, but each new feature should be accompanied by appropriate rule disclosures, technical support, and risk controls.
1.3 Target Users and Scope of Application
The platform is intended to serve users who wish to access relevant market information and participate in applicable trading activities through online tools. Different products may require different levels of knowledge, experience, and risk tolerance. Accordingly, the suitability of a particular product or function should be assessed with consideration given to the associated product risks, the user’s individual financial circumstances, and the requirements applicable in the user’s jurisdiction.
This white paper is intended to describe the project’s product design and operating framework and does not constitute investment advice or a guarantee of returns. The products actually offered by the platform, available jurisdictions, account eligibility requirements, and trading rules shall be subject to the applicable official documents and user agreements in effect at the relevant time. Functions that remain under development or planning will be identified separately from services that are already available, so as to avoid users interpreting prospective development plans as currently available products.
Chapter 2| Products and Services
2.1 Product Structure
Kinexys Ltd’s product structure is organized around three core areas: trading, strategies, and account management. Trading functions provide users with access to relevant products; strategy functions enable users to monitor or follow specific trading approaches; and account functions allow users to review fund movements, order status, and transaction history. Together, these functions form the platform’s overall user journey, while their respective rules, risks, and responsibilities should be clearly defined and addressed separately.
When presenting any trading product, the platform should provide users with sufficient information to understand the transaction before placing an order, including the underlying asset, trading direction, contract term, amount committed, applicable fees, settlement conditions, and potential losses. A product name may identify the category of a product, but it cannot substitute for the complete contractual terms and conditions.
2.2 Options Products
The outcome of an options transaction is closely linked to the price of the underlying asset and the terms specified in the relevant contract. Different products may vary significantly in terms of the rights and obligations of the parties, expiration procedures, and profit-and-loss calculations.
Accordingly, the platform should specify the trading rules for each product it actually offers rather than treating all options products as a single category.
For products in which the settlement outcome depends on whether specific conditions are satisfied, users should pay particular attention before trading to the applicable conditions, reference price, expiration time, and settlement amount. Any projected outcome displayed in the interface should be consistent with the applicable contractual terms and the underlying calculation methodology. Even where the amount committed to an individual transaction is clearly stated, repeated transactions may result in significant cumulative losses. Risk disclosures should reflect this potential exposure.
2.3 Contract Trading Products
Contract trading enables users to participate in movements in the price of an underlying asset in accordance with predefined contractual terms. The risks associated with contract trading are not determined solely by the direction of a price movement, but are also affected by position size, margin requirements, applicable fees, market liquidity, and conditions for closing positions. Where leverage is involved, even relatively small price movements may have a significant impact on account equity.
The platform should clearly display contract specifications, pricing and settlement methods, applicable fees, and the procedures that apply when available margin falls below the required level.
Users should also be able to review their positions, unrealized profit and loss, and realized profit and loss, while distinguishing the effects of market price movements from fee deductions on their account balance. The specific underlying assets and contract types available for trading shall be subject to the product rules formally published by the platform.
2.4 AI-Assisted Tools and Strategy Following
AI-assisted tools may be used to organize market data, present strategy signals, or support the trading process. Strategy-following functions, by contrast, may allow users to execute corresponding transactions based on the trading activity of a particular strategy and predefined conditions. These two types of functionality serve different purposes and should therefore be explained separately, including their respective inputs, triggering conditions, and execution methods.
In a strategy-following scenario, users should understand the applicable follow ratio, per-transaction and cumulative investment limits, conditions for suspending the strategy, and the treatment of existing positions after following is discontinued. The timing of a strategy signal, market quotations, and the actual execution time of a user’s order may not be identical. As a result, the historical performance displayed for a strategy may differ from the actual results ultimately achieved by a user.
Regardless of whether a strategy is developed by a human or generated with the assistance of a model, its effectiveness may change as market conditions evolve. The platform should provide verifiable performance metrics and clearly disclose whether the reported figures account for fees, include or exclude unexecuted orders, and cover what period of time.
2.5 Market Data, Accounts, and Transaction Records
Clear and accessible records are fundamental to effective trading risk management. The platform’s account interface should enable users to distinguish between available balance, allocated funds, current positions, and completed transactions, while presenting status changes such as order submission, execution, cancellation, and settlement in chronological order.
The market data interface should disclose the source of price data and the manner in which such data is updated. Where the displayed market price, the quotation available when an order is placed, and the final execution price may differ, the platform should explain the circumstances under which such differences may occur. This enables users to understand the factors affecting their trading results rather than viewing only the final account balance.
2.6 Product Usage Boundaries
Any analysis, signals, or strategy information provided by the platform should not be interpreted as a guarantee of future prices or returns. Before using automated functions, users should still understand the relevant products and independently determine the amount they are willing to commit and the level of loss they are able to tolerate.
Whether a specific product is available, which users are eligible to access it, and which jurisdictions it applies to shall be determined by the applicable official product documentation and account rules. Functions that have not yet been launched should be clearly identified as planned features. Where the rules governing an available product are amended, the platform should retain accessible records of the applicable version and its effective date.
Chapter 3| Platform Operating Mechanism
3.1 Account Opening and Identity Verification
Before accessing trading functions, users are required to complete account registration and the applicable identity verification procedures. The registration process should specify the eligibility requirements for account opening, required documentation, review procedures, and the process to be followed if an application is not approved. For products subject to different regional requirements or risk classifications, the platform should also clearly state the applicable eligibility criteria, so that users do not discover that they are unable to access a particular service only after depositing funds.
Identity verification is relevant not only to account security but also to the traceability of trading and financial transactions. The platform should inform users of the purposes for which personal information is collected, how such information is stored, and the requirements for keeping it up to date. Where material changes occur to account information, users should be provided with appropriate means to verify or correct the relevant information.
3.2 Deposits and Withdrawals
The funding process should enable users to clearly identify the party responsible for processing each stage. From the submission of a deposit request and receipt of funds to the creation of an available balance, and from the submission of a withdrawal request to the transfer of funds, the platform should separately specify the applicable processing conditions, estimated processing times, applicable fees, and circumstances that may result in delays.
The balance displayed in a user’s account should be capable of being reconciled with the underlying financial records. Where multiple currencies or payment methods are supported, the platform should also disclose the applicable exchange rates, conversion fees, and methodology used to calculate the amount ultimately credited. The legal entities responsible for receiving, holding, and processing user funds should be expressly identified by their legal names in the applicable official documentation, rather than being described only through general statements such as “platform protection.”
3.3 Quotation and Order Execution
A transaction typically involves a series of steps, including product selection, parameter configuration, quotation display, user confirmation, order submission, execution, and recording of the transaction result. Before confirmation, the platform should enable users to clearly review the trading direction, transaction amount, applicable price, fees, and key risks. After submission, users should be provided with a clear and accessible order status. Market data displays, order-entry quotations, and final execution prices may correspond to different points in time. For products where prices are subject to change, the platform should explain the validity period of quotations, the procedures applicable when price deviations occur, and the circumstances under which an order may be rejected, delayed, or partially executed. Where a particular product is subject to fixed settlement conditions, the platform should also specify the source of the price used for settlement and the applicable time standard.
Whether orders are executed directly by the platform or routed to a third-party execution provider is a material fact for understanding the trading relationship. The official white paper should identify the relevant execution entity and its responsibilities in accordance with the actual business arrangements, and should provide users with a means of accessing detailed order information.
3.4 Settlement and Transaction Records
Following the completion of a transaction, users should be able to access the order number, submission and execution times, execution or settlement price, transaction amount, applicable fees, and final outcome. For products subject to settlement at expiration, the platform should further explain how the settlement price is determined, when the resulting amount is credited to the account, and how the relevant data may be reviewed in the event of a dispute concerning pricing data.
Account records should distinguish among deposits and withdrawals, trading gains and losses, fee deductions, and other adjustments.
Where an order is not successfully completed due to system conditions, market conditions, or applicable rules, the platform should record the relevant status changes and processing outcome, enabling users to trace how their account balance was formed.
3.5 Fees and Economic Arrangements
Fee disclosures should cover all costs actually borne by users, including applicable trading fees, spreads, overnight or position-holding charges, currency conversion fees, and withdrawal fees. Where fee structures differ across products, they should be presented separately, together with an explanation of whether each fee is charged at order placement, during the holding period, upon settlement, or during the transfer of funds.
Where the platform derives revenue from quotation spreads, order execution, strategy-related services, or third-party partnerships, it should also disclose the relevant economic arrangements associated with user transactions. This enables users to assess a service based on its pricing, costs, and execution arrangements rather than relying solely on the profit or loss displayed for an individual transaction.
3.6 Handling of Exceptional Circumstances
Extreme market volatility, market data interruptions, network failures, and system maintenance may affect quotations and order processing. The platform should specify in advance the circumstances under which trading may be suspended, order placement may be restricted, execution may be delayed, or services may be restored, and should provide accessible notices and records of the relevant handling measures when such events occur.
For order-related disputes, users should have access to a clear channel for submitting complaints, a defined method for providing supporting materials, and a specified processing timeframe. Reviews should be conducted based on order logs, quotation records, and the applicable formal product rules. Where an error requiring correction is confirmed, the basis for the correction should be explained, and a record of the adjustment should be retained in the user’s account.
Chapter 4| Technology and Data Security
4.1 System Architecture and Service Stability
The technical architecture of a trading platform must support market data display, order processing, account records, and risk controls. Data transmitted between these components should follow clearly defined processing sequences and maintain corresponding status records, enabling user instructions to be identified, executed, and traced.
System stability should not be measured solely by whether the interface remains accessible. During periods of high trading volume, significant market volatility, or external data interruptions, quotation updates, order confirmations, and balance calculations may all be subject to varying levels of operational pressure. The platform should establish monitoring and contingency mechanisms based on its operational capacity and clearly define how outstanding orders will be handled during periods of degraded or suspended services.
Where the technical architecture relies on third-party market data, payment, cloud, or trading services, the responsibilities of each party should also be clearly defined. In the event of a failure involving an external service, the platform should remain capable of determining the scope of affected services and informing users of the status of their accounts and orders.
4.2 Account Protection and Access Control
User accounts are connected to identity information, trading permissions, and fund-related operations. Accordingly, login procedures and sensitive actions require layered protection. Password management, additional authentication, alerts for unusual login activity, and confirmation of important actions can help reduce the risk of unauthorized account access. Different operations should employ verification methods proportionate to their respective risks, particularly when modifying account information, resetting security settings, or submitting withdrawal requests.
Access permissions should also be controlled internally within the platform. Employees and service personnel who access user information or modify account status should receive only the permissions necessary for their respective responsibilities. Important operations should be logged and subject to review. Access permissions should also be promptly adjusted or revoked when an employee’s role changes or their employment ends.
Account security depends on the joint efforts of both the platform and its users. The platform should provide clear security notifications and channels for reporting suspicious activity, enabling users to promptly suspend relevant permissions and initiate an investigation when they identify activity that was not authorized by them.
4.3 Data Protection and Privacy Management
During account opening, trading, and customer service processes, the platform may process identity information, contact details, device information, and transaction records. Data collection should correspond to specific service purposes, and users should be informed of the scope of use, retention periods, and circumstances under which data may be shared.
Appropriate safeguards should be implemented for the transmission, storage, and access of sensitive information. For data used to analyze product usage, the platform should distinguish between information necessary for providing the relevant service and information that users may choose to provide, avoiding the use of data beyond its original stated purpose. Where data processing is outsourced to third parties, the platform should clearly specify the services performed by such parties and the applicable data protection requirements.
Users should be able to understand how to access and correct their account information and, where permitted under applicable rules, submit other data-related requests. Where the privacy policy undergoes material changes, the platform should notify users in a manner that is clear and readily accessible.
4.4 Integrity of Transaction Data
Order and fund records form the basis for resolving account-related disputes. The platform should retain information relating to key operations, including timestamps, account identifiers, instruction details, and processing results, so that each change to an account balance can be traced to its underlying basis. The methods used to retain such records should also protect them against unauthorized modification and support necessary internal reviews.
For market data and settlement data, the platform should record the data sources used and the applicable time standards. Where external data is missing, delayed, or materially anomalous, the platform should maintain procedures for identification and handling to prevent unverified data from directly affecting transaction outcomes.
4.5 Monitoring, Backup, and Incident Response
Security incidents may arise from account compromise, system vulnerabilities, configuration errors, or failures involving external services. The platform should continuously monitor anomalous access activity and the status of critical systems, and conduct investigations, implement measures to limit potential damage, and restore services according to the scope and impact of each incident.
The value of backups lies in their ability to support effective recovery. In addition to maintaining necessary data copies, the platform should define recovery priorities, responsible personnel, and validation procedures, and should periodically verify that backups remain usable. Recovery operations involving transaction and account information should be designed to prevent duplicate entries, missing orders, or alterations to original records.
Where an incident affects users’ ability to access accounts, conduct fund-related operations, or obtain transaction results, the platform should promptly communicate the known facts, scope of impact, temporary measures, and subsequent developments. Following the resolution of an incident, the platform should review its causes and response process and use the findings to improve its technical and administrative measures.
Chapter 5| Risk Management and User Protection
5.1 Risk Management Principles
Risk management should be integrated throughout product design, user eligibility, trade execution, and post-transaction processes. For a trading platform, risk disclosures should not be limited to the registration page or the end of an agreement. Users should be provided with information relevant to their immediate decisions when reviewing a specific product, setting a transaction amount, and confirming an order.
The platform should identify risks based on the characteristics of each product and incorporate applicable control measures into the relevant product rules. Risk controls may limit the rate at which losses accumulate, but they cannot eliminate price volatility or guarantee a positive return on any transaction. Users should make decisions only after understanding the relevant product and their own capacity to bear potential losses.
5.2 Market and Product Risks
The value of options and contract products may change rapidly in response to the price of the underlying asset, market volatility, time to expiration, and trading conditions. Even where the direction of a price movement is correctly anticipated, the expected return may not be achieved, as execution prices, fees, and expiration conditions may all affect the final outcome.
Certain products may result in the entire amount committed being lost upon expiration. Where leverage or additional margin requirements are involved, losses may accumulate more rapidly and, under certain trading arrangements, may exceed the initial amount committed. The platform should specify the maximum potential loss, conditions for closing positions, and any subsequent obligations that users may incur for each product category, rather than relying on a single generalized risk disclosure for all transactions.
5.3 Strategy and Automation Risks
AI-assisted analysis and strategy-following functions depend on data quality, model parameters, and execution conditions. Models may fail to identify unexpected events or changes in market structure in a timely manner. Historical strategy data may also reflect favorable conditions during particular periods and therefore may not be representative of future performance.
Followed trades are also subject to execution differences. After a strategy generates a signal, a user’s order may be executed at a different price, or may not be executed at all, due to changes in quotations, insufficient liquidity, or account restrictions. The platform should present strategy performance separately from users’ actual trading results and enable users to set investment limits, pause strategy following, or terminate subsequent instructions.
Descriptions of strategies should specify their methodology, statistical period, principal risks, and the basis used for calculating fees. Any backtested or historical return data should not be presented as a guarantee or commitment of future returns.
5.4 Liquidity, Execution, and Technology Risks
When market activity is limited, users may have difficulty establishing or exiting positions at their expected prices. During periods of heightened market volatility, significant differences may also arise between quoted prices and actual execution prices. The platform should disclose the circumstances under which delays, rejected orders, partial executions, or trading suspensions may occur, as well as how the relevant orders will be handled.
Network interruptions, device failures, and system maintenance may affect users’ ability to access market data or submit instructions. Where users are unable to take action immediately, existing positions may remain exposed to market movements. The platform should provide channels for service disruption notifications, order status inquiries, and dispute reviews, and should retain records of the relevant handling processes.
5.5 User Suitability and Trading Restrictions
Users may differ in their understanding of complex products and their capacity to bear potential losses. Based on the products actually offered, the platform should establish appropriate risk disclosures, knowledge acknowledgments, and trading permission controls. For higher-risk functions, access conditions may be established based on factors such as trading experience, amount committed, and product characteristics, with the reasons for such restrictions clearly communicated to users.
Trading restrictions should serve clearly defined risk management objectives. For example, per-transaction limits, cumulative risk exposure limits, margin requirements, and monitoring of anomalous activity should each be supported by rules that are transparent and understandable. When a restriction is triggered, users should be able to determine which functions are affected, the basis for the restriction, and the conditions under which it may be lifted.
5.6 Protection of Fund Operations and Dispute Resolution
Deposits and withdrawals directly affect users’ control over their accounts. The platform should publish the conditions for withdrawal requests, review procedures, estimated processing times, and applicable fees. Where a request is delayed or rejected, the platform should provide the user with a specific explanation and accessible channels for inquiry and appeal. Users should not be restricted from managing their account funds based on conditions that were not disclosed in advance.
Where users dispute a quotation, execution, settlement, or account balance, they should be able to submit the relevant order number and supporting materials. The platform should investigate based on traceable records and provide a response within a clearly defined timeframe. Where a dispute involves a third-party service provider, the platform should still inform the user which party is responsible for coordination and how the matter will be followed up.
5.7 Ongoing Updates to Risk Information
Product rules and market conditions may change, and risk disclosures should be updated accordingly. When introducing new products, adjusting fees, changing execution arrangements, or modifying funding procedures, the platform should communicate the relevant changes and their potential impact on existing users before they take effect.
Ultimately, user protection depends on the accuracy of information, the enforceability of applicable rules, and the ability to address issues in a timely manner when they arise. The mechanisms described in this white paper should remain consistent with the formal product documentation, user agreements, and actual operating practices.
Chapter 6| Operational and Compliance Information
6.1 Operating Entity and Responsibilities
Users need to know with whom they are establishing a service relationship. The platform should identify in its official documentation the legal name, place of registration, contact address, and specific responsibilities of the operating entity with respect to account management, product provision, order execution, and customer service.
Where website operations, trade execution, and fund processing are performed by different entities, the relationships among these parties should be presented through a clear business process. The contracting entity identified in the user agreement, the entity receiving user funds, and the entity identified in the white paper should be capable of being reconciled with one another. Disclosure of a platform brand name alone is insufficient to establish which entity bears the relevant legal responsibilities.
6.2 Service Regions and Product Access
Different jurisdictions may impose different requirements on trading products, marketing practices, and investor eligibility. Based on the services actually provided, the platform should clearly identify the jurisdictions in which services are available, restricted, or unavailable, as well as the products accessible to different categories of users. A user’s ability to access the website does not necessarily mean that all trading functions are permitted in the user’s jurisdiction.
Product access may also depend on factors such as the user’s identity, trading experience, and risk tolerance. The applicable conditions should be disclosed before account opening and prior to the use of relevant products. When the platform changes its service scope, it should inform existing users of how such changes may affect their accounts, positions, and fund-related operations.
6.3 Identity Verification and Transaction Monitoring
Account opening and financial transactions should be linked to the verified identity of the user. In accordance with applicable requirements, the platform should establish procedures for identity verification, information updates, retention of transaction records, and the review of anomalous activity, and should explain the circumstances under which users may be required to provide additional information.
Review procedures should have clearly defined boundaries. Where account activity is restricted due to incomplete information or anomalous transactions, the platform should, to the extent permitted by applicable rules, inform users of the requirements for resolving the matter and provide appropriate channels for further communication.
Such measures should support necessary risk management while avoiding indefinite or unexplained restrictions on normal account operations.
6.4 Client Funds and Asset Arrangements
How client funds are received, held, transferred, and reconciled should be addressed separately as a core component of operational information. The official white paper should identify the entity responsible for handling funds, the relevant account arrangements, how the available balance is established, and the procedures applicable when users request withdrawals.
Where funds are held or processed by a third-party institution, the platform should identify the institution by its legal name and specify its responsibilities, as well as explain how platform account records are reconciled with the relevant fund records. Where digital assets are involved, the platform should separately describe asset custody, transfer authorization, and related technology risks. Any statements concerning “segregation of funds,” “insurance protection,” or “full compensation” should be consistent with the actual contractual terms and supporting documentation.
6.5 Third-Party Services and Brand Relationships
The platform may use third-party services for market data, technology, payments, or customer support. The white paper should distinguish among technical service relationships, commercial partnerships, and regulated financial service relationships, and should clarify whether third parties assume any direct obligations toward users.
Institutional names appearing in brand names, interface elements, or promotional materials should not lead users to assume the existence of an affiliation, authorization, or guarantee that has not been substantiated. Statements concerning partner institutions should be based on formal documentation that can be independently verified by the relevant parties and should accurately define the scope of the relationship.
6.6 Information Disclosure and Document Consistency
The white paper, product rules, fee schedules, risk disclosures, and user agreements collectively shape users’ understanding of the services. These documents should use consistent entity names, product definitions, and descriptions of fund flows. Where discrepancies arise, the applicable document and version should be clearly identified.
Where material changes occur to operational information, including changes to operating entities, product rules, fund-handling arrangements, or third-party service relationships, the platform should promptly update the relevant documents and disclose the effective date and potential impact on existing users. The value of compliance information lies in enabling users to verify relevant facts, understand the allocation of responsibilities, and protect their rights and interests.
6.7 MSB Business Framework and Registration Disclosure
MSB (Money Services Business) is a classification under the U.S. regulatory framework covering certain activities, including money transmission and currency exchange. If Kinexys Ltd conducts services falling within this category directly or provides such services through partner institutions, it should determine the applicable registration, licensing, and ongoing compliance requirements based on the actual nature of its business activities, service jurisdictions, and assigned responsibilities, and should clearly identify the relevant legal entities and scope of business in its official documentation. Whether MSB requirements apply should be determined based on the substance of the business activities and should not be inferred solely from the platform name or its ability to receive or transfer funds.
Where MSB registration with the U.S. Financial Crimes Enforcement Network (FinCEN) is applicable, the platform should disclose the registered entity’s legal name, registration number, declared business categories, and official verification channel, and ensure that such information is consistent with the user agreement and fund-handling arrangements. Where the registered entity is a third-party service provider, the platform should clearly describe its relationship with that provider and the specific functions performed by the provider, avoiding any representation that the provider’s registration status constitutes a qualification held by the platform itself. Where registration information changes or renewal is required, the disclosed information should be promptly verified and updated.
MSB registration and the eligibility requirements applicable to options, contract trading, and investment management services should be addressed separately. Even where the relevant entity has completed MSB registration, the platform should independently determine the qualifications and permissions required for trading services based on the specific products, business model, and service jurisdictions. Arrangements concerning the custody, insurance, and compensation of client funds or losses should likewise be supported by separate contractual terms and documentary evidence and should not rely solely on MSB registration as the basis for such protection.
Where the actual business activities are subject to applicable MSB requirements, the platform should incorporate corresponding anti-money laundering and counter-terrorist financing measures into its operating processes. Based on the risks associated with its business activities, the platform should establish procedures for identity verification, review of fund flows, handling of anomalous activity, and record retention, and fulfill applicable reporting obligations. These measures should be integrated with account management, deposits and withdrawals, and customer service, with clearly defined internal responsibilities, review procedures, and information management requirements. Information that may not be disclosed by law should be handled in accordance with the applicable requirements.
Chapter 7| Development Plan
7.1 Development Principles
Kinexys Ltd’s development plan is based on clear product rules, verifiable transaction records, and effective risk management. The number of features is not the sole measure of the platform’s maturity. Before each feature is made available, its operating process, user eligibility conditions, technical capacity, and procedures for handling exceptional circumstances should be confirmed.
The project will be advanced in stages according to the readiness of its products. The objectives of each stage are intended to indicate the direction of development and do not constitute a commitment to feature availability or commercial results. The scope of the official launch shall be subject to the product documentation issued by the platform at the relevant time.
7.2 Basic Services Stage
The focus of the basic services stage is to establish complete account and transaction processes, including user registration, identity verification, product information display, order management, account records, and customer support.
At this stage, the platform should prioritize verifying the consistency of information: whether the rules displayed to users on product pages correspond to order confirmations, settlement results, and account records; whether the status of fund deposit and withdrawal processes can be clearly displayed; and whether relevant records can support review in the event of a dispute. Only when the basic processes operate stably can subsequent functional expansion have a reliable foundation.
7.3 Product Enhancement Stage
After stable processes have been established for basic services, the project may, based on user needs and applicable requirements, improve the presentation of trading product rules, fee disclosures, and risk control tools. Each product should provide clear contractual terms and profit and loss descriptions separately, enabling users to compare trading conditions rather than make choices solely based on expected results displayed on the interface.
This stage may also improve the presentation of account information, including position changes, transaction costs, and access to historical records. Such improvements should aim to help users understand their own trading activities, and their effectiveness should be evaluated using actual operational data.
7.4 Strategy Tools Stage
The development of strategy tools should begin with information transparency and user control. For market analysis, trading signals, or strategy following functions, the platform should disclose the sources of data, the applicable scope of the strategy logic, the methodology used for performance statistics, and potential execution deviations.
Users should be able to independently set participation conditions, review discrepancies between actual transactions and strategy displays, and remain informed of the current strategy status at all times. Before new tools are launched, their performance under market volatility, data interruptions, and system latency should also be evaluated to avoid automated processes amplifying risks that users do not fully understand.
7.5 Ongoing Evaluation and Version Updates
The development plan should be evaluated based on operational results. The platform may regularly assess existing functions based on system stability, order processing, customer feedback, and dispute resolution, and determine the order of improvements for the next stage accordingly.
When products or rules are updated, the version, effective date, and major changes should be disclosed. For adjustments that affect existing accounts or positions, the transition arrangements should also be explained. The project’s development direction may be adjusted in response to market and user needs, but each adjustment should retain a clear basis for decision-making and information that users can access and review.
