Distributed security transaction system based on cloud platform

Abstract

The invention discloses a distributed security transaction system based on a cloud platform, relates to the technical field of security transaction, and aims to solve the problem of poor security during transaction on a security platform. According to the method, the load state of the matchmaking engine is monitored in real time, the optimal engine is screened according to strict indexes such as the CPU utilization rate, the queuing order quantity and the average processing delay, the load of each engine can be dynamically balanced, the engine performance can be fully played, the performance bottleneck caused by overhigh load of part of engines is avoided, the order processing speed can be increased, and the service life of the engine is prolonged. According to the method, the user waiting time is shortened, a net amount settlement mode is adopted for fund and security settlement, multiple transactions in the same settlement period or the same security are subjected to summarizing and differential settlement processing, and compared with one-by-one settlement, the data processing amount and the fund and security transfer frequency are greatly reduced, and the operation complexity and the time cost are reduced.

Description

Technical Field

[0001] This invention relates to the field of securities trading technology, specifically a distributed securities trading system based on a cloud platform. Background Technology

[0002] Securities trading refers to the act of investors buying and selling issued securities through stock exchanges or other legal trading venues.

[0003] Chinese patent CN102129650A discloses a network finance system, which mainly utilizes new network interconnection technology to connect various local area networks or dedicated networks of financial institutions to form a financial network via the Internet. This network, together with electronic displays and electronic readers, constitutes a network finance system. The electronic displays can deposit and withdraw electronic currency through network payments via financial browsers. It can also store electronic currency for other electronic displays. The mainframes or servers in electronic banking, electronic insurance, and electronic securities systems contain "expert think tank software," which can provide various financial business services; provide various value-added financial information services; provide different financial risk warning functions; and enable banking institutions to develop towards full-service, international, intensive, and diversified directions. Network finance is an inevitable trend of modernization and plays an important role in promoting economic development. Although the above patent solves the problem of financial transactions, the following problems still exist in actual operation:

[0004] 1. The transaction information for each port was not processed effectively, resulting in errors in the original transaction information.

[0005] 2. The lack of targeted transaction processing for transaction orders and the lack of effective monitoring of transaction risks resulted in poor security for transaction orders.

[0006] 3. The lack of targeted account management and monitoring for trading accounts and management accounts in transaction orders resulted in poor security throughout the overall transaction process. Summary of the Invention

[0007] The purpose of this invention is to provide a distributed securities trading system based on a cloud platform. By monitoring the load status of the matching engine in real time and selecting the optimal engine based on strict indicators such as CPU utilization, queued order volume, and average processing latency, the system can dynamically balance the load of each engine. This not only fully utilizes the engine performance and avoids performance bottlenecks caused by excessive load on some engines, but also improves order processing speed and reduces user waiting time. Funds and securities clearing adopt a net settlement model, which summarizes and nets multiple transactions of the same clearing cycle or the same security. Compared with transaction-by-transaction clearing, this significantly reduces the amount of data processing and the number of fund and securities transfers, reduces operational complexity and time costs, and solves the problems in the prior art.

[0008] To achieve the above objectives, the present invention provides the following technical solution:

[0009] A cloud-based distributed securities trading system includes:

[0010] The transaction request receiving and processing unit is used to receive transaction requests from different ports and perform authentication and authorization checks.

[0011] The receiving data analysis unit is used to analyze the received transaction requests and process the orders based on the analysis results.

[0012] The distributed order matching unit is used to route completed orders to the distributed matching engine for order matching.

[0013] The order risk monitoring unit is used to monitor the transaction risks of completed orders.

[0014] The account and asset management unit is used to manage the account information and assets of trading accounts and management accounts, and to clear and settle transactions after they are completed.

[0015] The distributed order matching unit is also used for:

[0016] Once the order is processed, a structured order is obtained, including user ID, security code, transaction type, quantity, price, timestamp, and current transaction status;

[0017] The load status of the matching engine is monitored in real time. Based on the real-time monitoring results, the target engine is selected, and the optimal engine is selected. The load indicators of the optimal engine are: CPU utilization is less than 80% of the threshold, the current number of queued orders is less than 10,000, and the average processing latency is less than 50ms.

[0018] Preferably, the distributed order matching unit is further used for:

[0019] Confirm the real-time status of the optimal engine, including its health status, functional tags, and extended attributes;

[0020] The structured orders are routed and quality-controlled, and then sent to the optimal engine via a message queue.

[0021] After receiving an order, the optimal engine adds the received order to the corresponding order book queue according to the order type. The order book queue includes the limit order queue, the market order queue, and the cancellation queue.

[0022] The orders in the order book queue are matched according to the matching algorithm.

[0023] Preferably, the transaction request receiving and processing unit is further configured to:

[0024] The different ports are terminal ports, interface ports, and message ports. The access layer receives transaction requests from different ports, distributes the transaction requests to distributed server nodes through a load balancer, and converts the protocols of different ports into a recognizable format.

[0025] The system retrieves the user's identity credentials from the transaction request and performs format validation on the credentials transmitted by the access layer. If the format validation is invalid, the transaction request is rejected and an error code is returned.

[0026] The authenticity of the credentials that pass the format verification is then verified. The authenticity verification includes token verification, certificate verification, and password verification.

[0027] After all authenticity verifications are passed, a new user session is generated. The new user session includes the user ID, terminal device fingerprint, and login time.

[0028] The corresponding roles of the newly generated users will be obtained, including ordinary investors, institutional traders, and administrators;

[0029] At the same time, it matches the set of operation permissions that the corresponding role has, including buying, selling, order cancellation, and asset query;

[0030] Based on the transaction request, verify whether the user has the necessary permissions, including functional permissions, data permissions, and quota permissions.

[0031] Finally, the permission verification was completed.

[0032] Preferably, the receiving data analysis unit is further configured to:

[0033] The received transaction requests are parsed to identify the various fields of the transaction requests;

[0034] The system analyzes the user's transaction intent based on the transaction request type and parameters, and verifies the transaction parameters.

[0035] The validation of trading parameters includes validating the trading quantity, trading unit, and price.

[0036] After analyzing transaction intent, we obtain users' buy requests, sell requests, and order cancellation requests;

[0037] Based on the transaction intent, abnormal transaction requests are identified, including high-frequency cancellations, large-scale impacts, and abnormal related accounts;

[0038] Finally, an order is generated based on the identification results of the transaction request.

[0039] Preferably, the order risk monitoring unit is further used for:

[0040] The matched orders will be monitored for multi-dimensional risk indicators, including transaction compliance, abnormal transaction behavior, market risk transmission indicators, and credit and asset risk indicators.

[0041] Among them, trading compliance includes price fluctuation limits, trading volume limits, and trading session limits; abnormal trading behavior includes monitoring high-frequency trading characteristics, large-volume trading characteristics, and price manipulation characteristics; market risk transmission indicators include monitoring liquidity shocks, related fluctuations, and risk warnings; and asset risk indicators include monitoring overdrafts, short selling of securities, and liquidation risks.

[0042] Automated risk identification is achieved by using machine learning models to analyze the monitoring results of multi-dimensional risk indicators.

[0043] After identification, the risk level of the matched orders is obtained, including low risk, medium risk, and high risk;

[0044] Risk control is implemented based on risk level. For medium-risk transactions, risk control personnel are notified via SMS, email, and internal system pop-ups for manual review. For high-risk transactions, the transaction is terminated, and the user account is locked to prohibit any further transactions.

[0045] Preferably, the account and asset management unit is further used for:

[0046] For orders that have passed risk monitoring, verify the transaction account and management account, and enter the account information after verification.

[0047] Account information entry involves entering basic information and risk assessment results for transaction accounts based on user type, then binding them to bank cards or escrow accounts, and finally generating a unique account identifier; management accounts involve entering the administrator's name, position, and department, assigning a set of operation permissions, and associating them with approval process nodes.

[0048] After the account information is entered, activate the transaction account and the management account, and then bind permissions.

[0049] After the permissions are bound, the account status of the trading account and the management account will be monitored. The status monitoring of the trading account will automatically freeze the account and notify the user if a risk event is triggered. Unfreezing requires the user to submit a written appeal and be reviewed by the risk control department. The status monitoring of the management account will periodically scan the permission usage. If abnormal login of the administrator account is found, the account will be locked immediately and a security audit will be triggered.

[0050] Finally, the management of the trading account and the administrative account is completed.

[0051] Preferably, the account and asset management unit is further used for:

[0052] The transaction data of the matched orders is confirmed. The transaction data includes the transaction time, transaction quantity, transaction price, account information of the buyer and seller and security code;

[0053] Funds clearing and securities clearing are carried out based on transaction data. Funds clearing includes the calculation of payable funds and net settlement. The calculation of payable funds involves the buyer calculating the total amount of funds to be paid based on the transaction amount and freezing the corresponding amount from the buyer's funds account. The seller calculates the net amount of funds to be received based on the transaction amount and marks it as funds to be transferred. Net settlement involves summarizing multiple transactions of the same account within the same clearing period and clearing them based on the net amount.

[0054] Securities clearing includes the calculation of securities payable and net settlement. The calculation of securities payable involves the seller freezing the corresponding number of securities from their securities account based on the transaction volume and marking them as securities to be transferred out; the buyer marks them as the number of securities to be transferred in. Net settlement involves netting multiple buy and sell transactions of the same security and clearing the number of securities on a net basis.

[0055] Preferably, the account and asset management unit is further used for:

[0056] After the funds clearing and evidence clearing are completed, the funds account and settlement account are verified;

[0057] Once verification is completed and passed, settlement execution will proceed. Settlement execution includes fund settlement and securities settlement. Fund settlement includes internal transfers and cross-system transfers; evidence settlement includes internal transfers and cross-custodian transfers.

[0058] Update and mark the settlement status of orders that have been settled. Once the update and marking are completed, the settled and cleared orders will be obtained.

[0059] Preferably, the distributed order matching unit is further configured to:

[0060] The matching algorithm includes matching orders in the limit order queue:

[0061] Let B be the buy order in the limit order queue. i The sell order is S j The purchase price is P. B The sell order price is P. S The order quantity is Q. B The number of sell orders is Q. S ;

[0062] Perform B i With S j When P is matched, if B ≥P S Then the first transaction volume matched, D1 = min(Q B Q S); where min(…,…) is the function that takes the minimum value;

[0063] Update the remaining quantity Q′ of the buy orders after the transaction is completed. B =Q B -D1;

[0064] Update the remaining quantity of sell orders after the transaction is completed, Q′ S =Q S -D1;

[0065] Order matching in the market order queue:

[0066] Let M be the number of market orders in the market order queue. k The current optimal market price is P. best The number of market orders is Q. M ;

[0067] The second transaction volume matched, D2 = Q M ;

[0068] Transaction price P deal =P best ;

[0069] Order matching in the cancellation queue:

[0070] Let C be the number of cancellation requests in the cancellation queue. l The order ID for the cancelled order is O. id The order status is status(O) id );

[0071] For C l During processing and matching, if status(O) id If C is in an unsold state, then... l Respond to O id The order was cancelled.

[0072] Preferably, the order risk monitoring unit is further used for:

[0073] Based on the multimodal characteristics of completed orders, a customized transaction risk monitoring strategy is planned; the multimodal characteristics include at least: price, quantity, market dynamics, transaction history, and account risk level.

[0074] Based on a customized transaction risk monitoring strategy, customized transaction risk monitoring is performed on the matched orders;

[0075] This involves identifying multiple potential risk factors during the process of customized transaction risk monitoring of matched orders; these potential risk factors include at least: market risk, liquidity risk, and credit risk of the order.

[0076] Based on various potential risk factors, plan strategies to optimize objectives;

[0077] Optimize customized transaction risk monitoring strategies to achieve strategy optimization goals;

[0078] Based on the optimized customized transaction risk monitoring strategy, customized transaction risk monitoring is then carried out on the matched orders.

[0079] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0080] 1. The distributed securities trading system based on a cloud platform provided by this invention can accurately identify buy, sell, and cancellation requests by analyzing trading intentions, and further conduct abnormal transaction identification to promptly detect risky behaviors such as high-frequency order cancellation, large-scale impacts, and abnormal related accounts. It can obtain user roles and match corresponding sets of operation permissions, and then verify them by combining functional permissions, data permissions, and quota permissions. It can achieve refined permission management based on user identity and business needs.

[0081] 2. The distributed securities trading system based on a cloud platform provided by this invention classifies risks into low, medium, and high levels and adopts differentiated risk control measures. It monitors the load status of the matching engines in real time and selects the optimal engine based on strict indicators such as CPU utilization, queued order volume, and average processing latency, dynamically balancing the load of each engine. This not only fully utilizes engine performance and avoids performance bottlenecks caused by excessive load on some engines, but also improves order processing speed and reduces user waiting time.

[0082] 3. The distributed securities trading system based on a cloud platform provided by this invention allows trading accounts to have their operating scope set according to user risk levels, and management accounts to have limited permissions based on job responsibilities and subject to approval processes, effectively preventing abuse of permissions. Funds and securities clearing adopt a net settlement model, summarizing and netting multiple transactions of the same clearing cycle or the same security. Compared with transaction-by-transaction clearing, this significantly reduces data processing volume and the number of fund and securities transfers, lowering operational complexity and time costs.

[0083] 4. Buy orders are prioritized for execution against higher-priced sell orders, and sell orders are prioritized for execution against lower-priced buy orders, ensuring market price fairness. Prioritizing limit orders improves market liquidity. Limit orders prevent users from being executed at undesirable prices, thus reducing trading risk. Market orders ensure immediate execution, providing efficient market trading. The rapid execution of market orders reduces order waiting time, improving overall market liquidity. Users don't need to worry about long-term order backlogs, improving execution efficiency. Users can cancel unexecuted orders at any time, avoiding unnecessary capital tied up and market volatility. The order cancellation mechanism ensures the market isn't overwhelmed by invalid orders, optimizing the order book. This prevents users from incurring unnecessary market risks due to unexecuted orders.

[0084] 5. Through multimodal feature analysis and customized risk monitoring strategies, the ability to identify and respond to risks during the trading process is improved. Risk control strategies can be dynamically adjusted to adapt to different market environments, thereby improving trading efficiency, reducing human intervention, enhancing the automation and flexibility of the system, and ensuring the security and compliance of transactions. Attached Figure Description

[0085] Figure 1 This is a schematic diagram of the distributed securities trading steps of the present invention. Detailed Implementation

[0086] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0087] To address the issue in existing technologies where effective order processing is not performed on transaction information for each port, leading to errors in the original transaction information, please refer to [link / reference needed]. Figure 1 This embodiment provides the following technical solution:

[0088] A cloud-based distributed securities trading system includes:

[0089] The transaction request receiving and processing unit is used to receive transaction requests from different ports and perform authentication and authorization checks.

[0090] The receiving data analysis unit is used to analyze the received transaction requests and process the orders based on the analysis results.

[0091] The distributed order matching unit is used to route completed orders to the distributed matching engine for order matching.

[0092] The order risk monitoring unit is used to monitor the transaction risks of completed orders.

[0093] The account and asset management unit is used to manage the account information and assets of trading accounts and management accounts, and to clear and settle transactions after they are completed.

[0094] Specifically, through distributed order processing and matching engines, transaction requests are distributed to multiple nodes for parallel processing, breaking through the performance bottleneck of traditional centralized systems. It can support millions of concurrent transaction requests, meet the needs of high-frequency trading scenarios, and perform real-time risk scanning on matched orders. Combined with a rule engine, it intercepts illegal transactions, meets regulatory compliance requirements, and automates the entire process from order receipt and matching to clearing and settlement, reducing manual intervention, lowering the risk of operational errors, and improving settlement efficiency.

[0095] The transaction request receiving and processing unit is also used for:

[0096] The different ports are terminal ports, interface ports, and message ports. The access layer receives transaction requests from different ports, distributes the transaction requests to distributed server nodes through a load balancer, and converts the protocols of different ports into a recognizable format.

[0097] The system retrieves the user's identity credentials from the transaction request and performs format validation on the credentials transmitted by the access layer. If the format validation is invalid, the transaction request is rejected and an error code is returned.

[0098] The authenticity of the credentials that pass the format verification is then verified. The authenticity verification includes token verification, certificate verification, and password verification.

[0099] After all authenticity verifications are passed, a new user session is generated. The new user session includes the user ID, terminal device fingerprint, and login time.

[0100] The corresponding roles of the newly generated users will be obtained, including ordinary investors, institutional traders, and administrators;

[0101] At the same time, it matches the set of operation permissions that the corresponding role has, including buying, selling, order cancellation, and asset query;

[0102] Based on the transaction request, verify whether the user has the necessary permissions, including functional permissions, data permissions, and quota permissions.

[0103] Finally, the permission verification was completed.

[0104] Specifically, the system receives transaction requests through terminal ports, interface ports, and message ports, ensuring compatibility with various business scenarios and access methods. Whether it's direct user operation or inter-system interface interaction and message transmission, seamless access is achieved. The access layer utilizes a load balancer to distribute requests to distributed server nodes and uniformly converts protocol formats, effectively solving the processing difficulties caused by differences in port protocols, reducing system coupling, facilitating rapid adaptation when adding ports or adjusting protocols, enhancing system scalability, and easily handling business growth and diversified needs. A multi-layered verification mechanism for credential information, including format validation and authenticity verification (token verification, certificate verification, and password verification), greatly improves the accuracy and security of user identification. Format validation initially filters invalid requests, while authenticity verification uses multi-dimensional verification methods to ensure that only legitimate users can enter the transaction process, effectively resisting malicious attacks, identity forgery, and other security threats, protecting user assets and system security. It obtains user roles and matches corresponding sets of operational permissions, then combines functional permissions, data permissions, and quota permissions for verification, enabling fine-grained permission management based on user identity and business needs. Different roles (ordinary investors, institutional traders, and administrators) have different permissions, which not only meets the diversity of business operations but also avoids the abuse of permissions, ensuring fair and compliant trading. At the same time, it also makes it possible to flexibly configure permission strategies for the system, making it easy to quickly adjust permission settings according to business changes.

[0105] The receiving data analysis unit is also used for:

[0106] The received transaction requests are parsed to identify the various fields of the transaction requests;

[0107] The system analyzes the user's transaction intent based on the transaction request type and parameters, and verifies the transaction parameters.

[0108] The validation of trading parameters includes validating the trading quantity, trading unit, and price.

[0109] After analyzing transaction intent, we obtain users' buy requests, sell requests, and order cancellation requests;

[0110] Based on the transaction intent, abnormal transaction requests are identified, including high-frequency cancellations, large-scale impacts, and abnormal related accounts;

[0111] Finally, an order is generated based on the identification results of the transaction request.

[0112] Specifically, the transaction request is parsed, identifying each field, thus building a clear framework for the transaction. This operation ensures the integrity and accuracy of transaction information, allowing the system to accurately understand the specific content of the transaction request and providing a solid data foundation for subsequent processing. Without this step, transaction information may be unclear, leading to processing errors. Analyzing the user's trading intent based on the transaction request type and parameters, and verifying the transaction parameters, clarifies the user's true needs and ensures the validity of the transaction data. Verification of transaction quantity, unit, and price can avoid transaction disputes caused by data errors, providing users with a reliable trading environment. Through the analysis of trading intent, buy, sell, and cancellation requests can be accurately identified, and abnormal transaction identification can be further carried out to promptly detect risky behaviors such as high-frequency order cancellations, large-scale impacts, and abnormal linked accounts. This proactive prevention and control mechanism effectively reduces the possibility of market manipulation and illegal transactions, maintains the fairness and stability of the trading market, and achieves efficient processing from request reception to order generation. Precise intent analysis and anomaly identification reduce manual intervention and error handling, improve transaction processing efficiency, bring users a convenient and fast trading experience, and enhance users' trust and satisfaction with the trading platform.

[0113] To address the shortcomings of existing technologies, such as the lack of targeted transaction processing and effective monitoring of transaction risks, which leads to inadequate transaction security, please refer to [link to relevant documentation]. Figure 1 This embodiment provides the following technical solution:

[0114] The distributed order matching unit is also used for:

[0115] Once the order is processed, a structured order is obtained, including user ID, security code, transaction type, quantity, price, timestamp, and current transaction status;

[0116] The load status of the matching engine is monitored in real time. The target engine is selected based on the real-time monitoring results. The target engine is the optimal engine. The load indicators of the optimal engine are: CPU utilization is less than 80% of the threshold, the current queued order volume is less than 10,000, and the average processing latency is less than 50ms.

[0117] Confirm the real-time status of the optimal engine, including its health status, functional tags, and extended attributes;

[0118] The structured orders are routed and quality-controlled, and then sent to the optimal engine via a message queue.

[0119] After receiving an order, the optimal engine adds the received order to the corresponding order book queue according to the order type. The order book queue includes the limit order queue, the market order queue, and the cancellation queue.

[0120] The orders in the order book queue are matched according to the matching algorithm.

[0121] Specifically, after order processing, a structured order containing multi-dimensional information is generated, making the order data clear and standardized, facilitating rapid system identification and processing. Sending orders to the optimal engine using a message queue achieves asynchronous decoupling, avoiding order backlog or congestion caused by engine processing delays, ensuring the continuity of order processing, and effectively handling high-concurrency scenarios. This improves system throughput, enhances system stability under high-volume transactions, and allows for real-time monitoring of the matching engine load. The optimal engine is selected based on strict indicators such as CPU utilization, queued order volume, and average processing latency, dynamically balancing the load of each engine. This not only fully utilizes engine performance and avoids performance bottlenecks caused by excessive load on some engines, but also improves order processing speed, reduces user waiting time, ensures efficient operation of the transaction system, improves resource utilization, and reduces operating costs. Orders are added to different order book queues according to type, and matching is performed based on the matching algorithm, achieving accurate order classification and efficient matching. By adopting corresponding processing logics for different types of orders such as limit orders, market orders, and order cancellations, we can meet diverse trading needs, improve order completion rates, ensure fair and just transactions, and provide a good foundation for the expansion and optimization of trading strategies, thereby enhancing the system's adaptability to complex trading scenarios.

[0122] The order risk monitoring unit is also used for:

[0123] The matched orders will be monitored for multi-dimensional risk indicators, including transaction compliance, abnormal transaction behavior, market risk transmission indicators, and credit and asset risk indicators.

[0124] Among them, trading compliance includes price fluctuation limits, trading volume limits, and trading session limits; abnormal trading behavior includes monitoring high-frequency trading characteristics, large-volume trading characteristics, and price manipulation characteristics; market risk transmission indicators include monitoring liquidity shocks, related fluctuations, and risk warnings; and asset risk indicators include monitoring overdrafts, short selling of securities, and liquidation risks.

[0125] Automated risk identification is achieved by using machine learning models to analyze the monitoring results of multi-dimensional risk indicators.

[0126] After identification, the risk level of the matched orders is obtained, including low risk, medium risk, and high risk;

[0127] Risk control is implemented based on risk level. For medium-risk transactions, risk control personnel are notified via SMS, email, and internal system pop-ups for manual review. For high-risk transactions, the transaction is terminated, and the user account is locked to prohibit any further transactions.

[0128] Specifically, the system monitors completed orders across multiple dimensions, including transaction compliance, abnormal trading behavior, market risk transmission, and credit asset risk, covering more than ten specific indicators such as price fluctuation limits and high-frequency trading characteristics. This comprehensive monitoring model acts like a finely woven risk filter for trading orders, leaving no potential risk unchecked and preventing crises caused by omissions in single-dimensional monitoring. Automated risk identification using machine learning models, compared to traditional manual analysis, can quickly process massive amounts of data and accurately determine risk types and levels. Machine learning models can continuously learn from historical data to optimize their identification capabilities, promptly discovering complex and hidden risk patterns, greatly improving the efficiency and accuracy of risk identification, reducing human error and subjective judgment bias. Risk levels are categorized as low, medium, and high, and differentiated risk control measures are implemented. Medium-risk transactions are notified to risk control personnel for manual review, maintaining the rigor of human intervention while avoiding excessive intervention that could disrupt normal trading; high-risk transactions are directly terminated and accounts are locked to promptly prevent the spread of risk. This tiered management approach ensures transaction security while maintaining flexibility and efficiency. Through proactive risk monitoring and intelligent control, it nipps risks in the bud, effectively preventing systemic crises caused by the spread of risk from a single order. It protects investor interests, maintains a fair and orderly trading market, enhances market participants' confidence in the platform, and promotes the healthy and stable development of the trading market.

[0129] To address the issue of inadequate security in the overall transaction process due to the lack of targeted account management and monitoring for trading and management accounts within existing technologies, please refer to [link to relevant documentation]. Figure 1 This embodiment provides the following technical solution:

[0130] The account and asset management unit is also used for:

[0131] For orders that have passed risk monitoring, verify the transaction account and management account, and enter the account information after verification.

[0132] Account information entry involves entering basic information and risk assessment results for transaction accounts based on user type, then binding them to bank cards or escrow accounts, and finally generating a unique account identifier; management accounts involve entering the administrator's name, position, and department, assigning a set of operation permissions, and associating them with approval process nodes.

[0133] After the account information is entered, activate the transaction account and the management account, and then bind permissions.

[0134] After the permissions are bound, the account status of the trading account and the management account will be monitored. The status monitoring of the trading account will automatically freeze the account and notify the user if a risk event is triggered. Unfreezing requires the user to submit a written appeal and be reviewed by the risk control department. The status monitoring of the management account will periodically scan the permission usage. If abnormal login of the administrator account is found, the account will be locked immediately and a security audit will be triggered.

[0135] Finally, the management of the trading account and the administrative account is completed.

[0136] Specifically, for orders that pass risk monitoring, the transaction account and management account are verified before information is entered. This avoids the creation of accounts associated with invalid or risky orders, ensuring account quality from the source. Transaction accounts are entered with basic information, risk assessment results, and linked bank cards according to user type. Management accounts record detailed administrator job information, assigned permissions, and linked approval processes. This hierarchical and precise data entry method ensures complete and standardized account information, facilitating subsequent management and risk control, while also providing strong support for compliant operations. The permission binding after account activation, combined with the management account's permission allocation and approval process, forms a multi-dimensional permission management system. Transaction accounts have their operational scope set according to user risk levels, while management accounts have their permissions limited according to job responsibilities and are subject to approval processes, effectively preventing permission abuse. Regular scanning of management account permission usage reveals anomalies that are promptly locked and audited, further strengthening the security and compliance of account operations, reducing internal risks, and implementing dynamic status monitoring of transaction and management accounts, with differentiated monitoring strategies set for different account characteristics. The trading account is automatically frozen and the user is notified when a risk event is triggered. Combined with a strict unfreezing process, this effectively prevents the spread of risk. Rapid locking and security auditing of abnormal logins to management accounts effectively defend against external attacks and internal violations. This proactive risk monitoring mechanism significantly improves the system's response speed and handling capabilities to various risks, maximizing the protection of user assets and system security.

[0137] The account and asset management unit is also used for:

[0138] The transaction data of the matched orders is confirmed. The transaction data includes the transaction time, transaction quantity, transaction price, account information of the buyer and seller and security code;

[0139] Funds clearing and securities clearing are carried out based on transaction data. Funds clearing includes the calculation of payable funds and net settlement. The calculation of payable funds involves the buyer calculating the total amount of funds to be paid based on the transaction amount and freezing the corresponding amount from the buyer's funds account. The seller calculates the net amount of funds to be received based on the transaction amount and marks it as funds to be transferred. Net settlement involves summarizing multiple transactions of the same account within the same clearing period and clearing them based on the net amount.

[0140] Securities clearing includes the calculation of securities payable and net settlement. The calculation of securities payable involves the seller freezing the corresponding number of securities from their securities account based on the transaction volume and marking them as securities to be transferred out; the buyer marks them as the number of securities to be transferred in. Net settlement involves netting multiple buy and sell transactions of the same security and clearing the number of securities on a net basis.

[0141] After the funds clearing and evidence clearing are completed, the funds account and settlement account are verified;

[0142] Once verification is completed and passed, settlement execution will proceed. Settlement execution includes fund settlement and securities settlement. Fund settlement includes internal transfers and cross-system transfers; evidence settlement includes internal transfers and cross-custodian transfers.

[0143] Update and mark the settlement status of orders that have been settled. Once the update and marking are completed, the settled and cleared orders will be obtained.

[0144] Specifically, a comprehensive confirmation of matched order transaction data, covering key elements such as transaction time and account information, ensures the authenticity and reliability of clearing data. This step acts as a "quality control station" for transactions, preventing deviations in fund and securities clearing due to data errors, providing accurate basis for subsequent processes, and protecting the rights and interests of all parties involved in the transaction. Fund and securities clearing adopts a net settlement model, summarizing and netting multiple transactions of the same clearing cycle or the same security. Compared with transaction-by-transaction clearing, this significantly reduces the amount of data processing and the number of fund and securities transfers, lowering operational complexity and time costs. Especially in high-frequency trading scenarios, it significantly improves clearing efficiency and releases market liquidity. After fund and securities clearing is completed, the fund account and settlement account are strictly verified, which is equivalent to adding "double insurance" to the transaction funds and securities. It promptly detects issues such as account anomalies and discrepancies in fund and securities balances, effectively preventing the risk of fund losses caused by account anomalies, ensuring the safety of the clearing and settlement process, clearly distinguishing between internal and cross-system transfers in fund settlement, and internal and cross-custodian transfers in securities settlement, and clarifying the settlement rules under different scenarios. By combining settlement status updates and marking, a closed-loop management system is achieved for the entire transaction process from clearing to settlement, ensuring the accurate delivery of funds and securities for each transaction and maintaining market trading order.

[0145] The matching algorithm includes:

[0146] Order matching in the limit order queue:

[0147] Let B be the buy order in the limit order queue. i The sell order is S j The purchase price is P. B The sell order price is P. S The order quantity is Q. B The number of sell orders is Q. S ;

[0148] Perform B i With S j When P is matched, if B ≥P S Then the first transaction volume matched, D1 = min(Q B Q S ); where min(…,…) is the function that takes the minimum value;

[0149] Update the remaining quantity Q′ of the buy orders after the transaction is completed. B =Q B -D1;

[0150] Update the remaining quantity of sell orders after the transaction is completed, Q′ s =Q S -D1;

[0151] Order matching in the market order queue:

[0152] Let M be the number of market orders in the market order queue. k The current optimal market price is P. best The number of market orders is Q. M ;

[0153] The second transaction volume matched, D2 = Q M ;

[0154] Transaction price P deal =P best ;

[0155] Order matching in the cancellation queue:

[0156] Let C be the number of cancellation requests in the cancellation queue. l The order ID for the cancelled order is O. id The order status is status(O) id );

[0157] For C l During processing and matching, if status(O) id If C is in an unsold state, then... l Respond to O id The order was cancelled.

[0158] The working principle and beneficial effects of the above technical solution are as follows:

[0159] A limit order is an order to trade at a specified price. The trade is only executed when the market price reaches or exceeds the specified price. Orders are matched only when the buy price is greater than or equal to the sell price. Buy orders are arranged from highest to lowest price, and sell orders from lowest to highest price; a trade is matched when the buy price is greater than or equal to the sell price. The trading volume is determined by the minimum number of buy and sell orders. Buy orders are prioritized for higher-priced sell orders, and sell orders are prioritized for lower-priced buy orders, ensuring market price fairness. By prioritizing the execution of limit orders, market liquidity is improved. The use of limit orders prevents users from trading at undesirable prices, thereby reducing trading risk.

[0160] A market order is an order that a user hopes will be executed as quickly as possible at the best available market price. A market order is executed directly against the best limit order. A market order is immediately matched with the best buy or sell order in the market. Market orders have no price limit; the system will execute the market order immediately based on the best buy or sell order price. Market orders ensure immediate execution, providing efficient market trading. The rapid execution of market orders reduces order waiting time and improves overall market liquidity. Users do not need to worry about orders remaining pending for extended periods, thus improving transaction execution efficiency.

[0161] The order cancellation feature is used to cancel unfilled limit or market orders, ensuring users can safely cancel orders when they no longer wish to trade. If the corresponding limit or market order for the cancellation order has not yet been filled, it is removed from the order book. The system locates the corresponding unfilled order based on the cancellation order's ID and removes it from the appropriate queue. Users can cancel unfilled orders at any time, avoiding unnecessary capital tied up and market volatility. This cancellation mechanism ensures the market is not overwhelmed by invalid orders, optimizing the market's order book and preventing users from incurring unnecessary market risks due to unfilled orders.

[0162] The transaction risk monitoring of matched orders includes:

[0163] Based on the multimodal characteristics of completed orders, a customized transaction risk monitoring strategy is planned; the multimodal characteristics include at least: price, quantity, market dynamics, transaction history, and account risk level.

[0164] Based on a customized transaction risk monitoring strategy, customized transaction risk monitoring is performed on the matched orders;

[0165] This involves identifying multiple potential risk factors during the process of customized transaction risk monitoring of matched orders; these potential risk factors include at least: market risk, liquidity risk, and credit risk of the order.

[0166] Based on various potential risk factors, plan strategies to optimize objectives;

[0167] Optimize customized transaction risk monitoring strategies to achieve strategy optimization goals;

[0168] Based on the optimized customized transaction risk monitoring strategy, customized transaction risk monitoring is then carried out on the matched orders.

[0169] The working principle and beneficial effects of the above technical solution are as follows:

[0170] After a trade order is matched, the system acquires the order's multimodal features. These features include not only basic order information such as price and quantity, but also dynamic market information, trading history, and account risk level. Through comprehensive analysis of these features, the system plans a customized trading risk monitoring strategy based on preset rules or a machine learning-based model (pre-trained using a large number of customized trading risk monitoring strategies labeled with applicable multimodal features as training samples).

[0171] After the strategy planning is completed, the system begins to implement risk monitoring. For each matched order, the system applies its customized transaction risk monitoring strategy to assess potential risks and take corresponding risk control measures.

[0172] During transaction risk monitoring, the system identifies potential risk factors through in-depth analysis of order characteristics. For example, the system may identify multiple potential factors such as market risk, liquidity risk, and credit risk. Potential risk factors refer to those that could affect transaction security, transparency, compliance, and efficiency. Once identified, the system plans optimization goals based on these factors. Optimization goals refer to the objectives the system aims to achieve during the transaction process, such as reducing slippage risk in large transactions or controlling the risk of excessive trading frequency. Specifically, for example, in a particular transaction with high liquidity risk, the optimization goal might be to reduce the probability of the order failing to execute and lower this risk to a certain threshold level.

[0173] Based on the optimization objectives, the system will optimize existing customized risk monitoring strategies. Optimization methods may include adjusting risk control thresholds, changing order matching methods, and improving transaction time limits. Specifically, for example, if an order fails to be executed due to excessive market volatility, the system can optimize the trading strategy by dynamically adjusting risk control parameters (such as maximum tolerable slippage and time limits).

[0174] Finally, the optimized, customized transaction risk monitoring strategy will continue to be applied to the risk monitoring of subsequent orders. The system will monitor each order in real time under the optimized strategy to ensure that risks are controllable during the transaction process and that orders can be completed smoothly.

[0175] The above technical solution improves the ability to identify and respond to risks during the trading process through multimodal feature analysis and customized risk monitoring strategies. It can dynamically adjust risk control strategies to adapt to different market environments, thereby improving trading efficiency, reducing human intervention, enhancing the automation and flexibility of the system, and ensuring the security and compliance of the transaction.

[0176] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus.

[0177] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention.

Claims

1. A distributed securities trading system based on a cloud platform, characterized in that: include: The transaction request receiving and processing unit is used to receive transaction requests from different ports and perform authentication and authorization checks. The receiving data analysis unit is used to analyze the received transaction requests and process the orders based on the analysis results. The distributed order matching unit is used to route completed orders to the distributed matching engine for order matching. The order risk monitoring unit is used to monitor the transaction risks of completed orders. The account and asset management unit is used to manage the account information and assets of trading accounts and management accounts, and to clear and settle transactions after they are completed. The distributed order matching unit is also used for: Once the order is processed, a structured order is obtained, including user ID, security code, transaction type, quantity, price, timestamp, and current transaction status; The load status of the matching engine is monitored in real time. Based on the real-time monitoring results, the target engine is selected, and the optimal engine is selected. The load indicators of the optimal engine are: CPU utilization is less than 80% of the threshold, the current number of queued orders is less than 10,000, and the average processing latency is less than 50ms.

2. The distributed securities trading system based on a cloud platform according to claim 1, characterized in that, The distributed order matching unit is also used for: Confirm the real-time status of the optimal engine, including its health status, functional tags, and extended attributes; The structured orders are routed and quality-controlled, and then sent to the optimal engine via a message queue. After receiving an order, the optimal engine adds the received order to the corresponding order book queue according to the order type. The order book queue includes the limit order queue, the market order queue, and the cancellation queue. The orders in the order book queue are matched according to the matching algorithm.

3. The distributed securities trading system based on a cloud platform according to claim 1, characterized in that, The transaction request receiving and processing unit is further configured to: The different ports are terminal ports, interface ports, and message ports. The access layer receives transaction requests from different ports, distributes the transaction requests to distributed server nodes through a load balancer, and converts the protocols of different ports into a recognizable format. The system retrieves the user's identity credentials from the transaction request and performs format validation on the credentials transmitted by the access layer. If the format validation is invalid, the transaction request is rejected and an error code is returned. The authenticity of the credentials that pass the format verification is then verified. The authenticity verification includes token verification, certificate verification, and password verification. After all authenticity verifications are passed, a new user session is generated. The new user session includes the user ID, terminal device fingerprint, and login time. The corresponding roles of the newly generated users will be obtained, including ordinary investors, institutional traders, and administrators; At the same time, it matches the set of operation permissions that the corresponding role has, including buying, selling, order cancellation, and asset query; Based on the transaction request, verify whether the user has the necessary permissions, including functional permissions, data permissions, and quota permissions. Finally, the permission verification was completed.

4. The distributed securities trading system based on a cloud platform according to claim 1, characterized in that, The receiving data analysis unit is further configured to: The received transaction requests are parsed to identify the various fields of the transaction requests; The system analyzes the user's transaction intent based on the transaction request type and parameters, and verifies the transaction parameters. The validation of trading parameters includes validating the trading quantity, trading unit, and price. After analyzing transaction intent, we obtain users' buy requests, sell requests, and order cancellation requests; Based on the transaction intent, abnormal transaction requests are identified, including high-frequency cancellations, large-scale impacts, and abnormal related accounts; Finally, an order is generated based on the identification results of the transaction request.

5. The distributed securities trading system based on a cloud platform according to claim 1, characterized in that, The order risk monitoring unit is also used for: The matched orders will be monitored for multi-dimensional risk indicators, including transaction compliance, abnormal transaction behavior, market risk transmission indicators, and credit and asset risk indicators. Among them, trading compliance includes price fluctuation limits, trading volume limits, and trading session limits; abnormal trading behavior includes monitoring high-frequency trading characteristics, large-volume trading characteristics, and price manipulation characteristics; market risk transmission indicators include monitoring liquidity shocks, related fluctuations, and risk warnings; and asset risk indicators include monitoring overdrafts, short selling of securities, and liquidation risks. Automated risk identification is achieved by using machine learning models to analyze the monitoring results of multi-dimensional risk indicators. After identification, the risk level of the matched orders is obtained, including low risk, medium risk, and high risk; Risk control is implemented based on risk level. For medium-risk transactions, risk control personnel are notified via SMS, email, and internal system pop-ups for manual review. For high-risk transactions, the transaction is terminated, and the user account is locked to prohibit any further transactions.

6. The distributed securities trading system based on a cloud platform according to claim 1, characterized in that, The account and asset management unit is also used for: For orders that have passed risk monitoring, verify the transaction account and management account, and enter the account information after verification. Account information entry involves entering basic information and risk assessment results for transaction accounts based on user type, then binding them to bank cards or escrow accounts, and finally generating a unique account identifier; management accounts involve entering the administrator's name, position, and department, assigning a set of operation permissions, and associating them with approval process nodes. After the account information is entered, activate the transaction account and the management account, and then bind permissions. After the permissions are bound, the account status of the trading account and the management account will be monitored. The status monitoring of the trading account will automatically freeze the account and notify the user if a risk event is triggered. Unfreezing requires the user to submit a written appeal and be reviewed by the risk control department. The status monitoring of the management account will periodically scan the permission usage. If abnormal login of the administrator account is found, the account will be locked immediately and a security audit will be triggered. Finally, the management of the trading account and the administrative account is completed.

7. The distributed securities trading system based on a cloud platform according to claim 1, characterized in that, The account and asset management unit is also used for: The transaction data of the matched orders is confirmed. The transaction data includes the transaction time, transaction quantity, transaction price, account information of the buyer and seller and security code; Funds clearing and securities clearing are carried out based on transaction data. Funds clearing includes the calculation of payable funds and net settlement. The calculation of payable funds involves the buyer calculating the total amount of funds to be paid based on the transaction amount and freezing the corresponding amount from the buyer's funds account. The seller calculates the net amount of funds to be received based on the transaction amount and marks it as funds to be transferred. Net settlement involves summarizing multiple transactions of the same account within the same clearing period and clearing them based on the net amount. Securities clearing includes the calculation of securities payable and net settlement. The calculation of securities payable involves the seller freezing the corresponding number of securities from their securities account based on the transaction volume and marking them as securities to be transferred out; the buyer marks them as the number of securities to be transferred in. Net settlement involves netting multiple buy and sell transactions of the same security and clearing the number of securities on a net basis.

8. The distributed securities trading system based on a cloud platform according to claim 7, characterized in that, The account and asset management unit is also used for: After the funds clearing and evidence clearing are completed, the funds account and settlement account are verified; Once verification is completed and passed, settlement execution will proceed. Settlement execution includes fund settlement and securities settlement. Fund settlement includes internal transfers and cross-system transfers; evidence settlement includes internal transfers and cross-custodian transfers. Update and mark the settlement status of orders that have been settled. Once the update and marking are completed, the settled and cleared orders will be obtained.

9. The distributed securities trading system based on a cloud platform according to claim 2, characterized in that, The distributed order matching unit is also used for: The matching algorithm includes matching orders in the limit order queue: Let B be the buy order in the limit order queue. i The sell order is S j The purchase price is P. B The sell order price is P. S The order quantity is Q. B The number of sell orders is Q. S ; Perform B i With S j When P is matched, if B ≥P S Then the first transaction volume matched, D1 = min(Q B Q S ); where min(…,…) is the function that takes the minimum value; Update the remaining quantity Q′ of the buy orders after the transaction is completed. B =Q B -D1; Update the remaining quantity of sell orders after the transaction is completed, Q′ S =Q S -D1; Order matching in the market order queue: Let M be the number of market orders in the market order queue. k The current optimal market price is P. best The number of market orders is Q. M ; The second transaction volume matched, D2 = Q M ; Transaction price P deal =P best ; Order matching in the cancellation queue: Let C be the number of cancellation requests in the cancellation queue. l The order ID for the cancelled order is O. id The order status is status(O) id ); For C l During processing and matching, if staus(O) id If C is in an unsold state, then... l Respond to O id The order was cancelled.

10. The distributed securities trading system based on a cloud platform according to claim 1, characterized in that, The order risk monitoring unit is also used for: Based on the multimodal characteristics of completed orders, a customized transaction risk monitoring strategy is planned; the multimodal characteristics include at least: price, quantity, market dynamics, transaction history, and account risk level. Based on a customized transaction risk monitoring strategy, customized transaction risk monitoring is performed on the matched orders; This involves identifying multiple potential risk factors during the process of customized transaction risk monitoring of matched orders; these potential risk factors include at least: market risk, liquidity risk, and credit risk of the order. Based on various potential risk factors, plan strategies to optimize objectives; Optimize customized transaction risk monitoring strategies to achieve strategy optimization goals; Based on the optimized customized transaction risk monitoring strategy, customized transaction risk monitoring is then carried out on the matched orders.

Images