Method and apparatus for processing transaction data of financial products

Abstract

This application discloses a method and apparatus for processing transaction data of financial products, relating to the field of financial technology. The method includes: receiving transaction parameters sent by a second server of the issuing institution of the target financial product through a first server of the sales institution; obtaining a transaction request uploaded by a user terminal device that meets the transaction parameters; determining a target transmission path based on the shared traffic rate of the data link between the first and second servers; and sending the transaction request to the second server based on the target transmission path. This application solves the technical problem in the prior art where, due to the limited purchase time of popular financial products, a large amount of transaction data needs to be transmitted between the sales institution, issuing institution, and user terminal device of the financial product within a short period of time, resulting in high data transmission latency for popular financial products, easily leading to data transmission congestion, and thus affecting the transaction success rate of popular financial products.

Description

Technical Field

[0001] This application relates to the field of financial technology, and more specifically, to a method and apparatus for processing transaction data of a financial product. Background Technology

[0002] With the accelerated digital transformation of the financial market, the rapid trading of high-yield, popular financial products has become a key means for many financial institutions to compete and attract customers. These products are often available for a limited time and in limited quantities, attracting a large number of users to rush to buy them within a very short time window. This not only tests the instantaneous high-concurrency processing capabilities of the banking system, but also poses unprecedented challenges to the timeliness and security of data transmission.

[0003] Within the existing technological framework, traditional data transmission mechanisms, especially those relying on public networks, often struggle to meet the specific needs of trading in popular financial products. Transaction data requires efficient flow between user terminals, bank branch servers, communication servers, and product issuing institutions. However, the uncertainty, high latency, and potential security threats of public networks lead to delays in data transmission, and even data transfer delays during peak trading periods, severely impacting transaction success rates.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method and apparatus for processing transaction data of financial products, which at least solves the technical problem in the prior art that, due to the limited purchase time of popular financial products, a large amount of transaction data needs to be transmitted between the sales institutions, issuing institutions and user terminal devices of financial products in a short period of time, resulting in high data transmission latency of transaction data of popular financial products, easy data transmission run problems, and thus affecting the transaction success rate of popular financial products.

[0006] According to one aspect of this application, a method for processing transaction data of a financial product is provided, comprising: receiving transaction parameters sent by a second server of the issuing institution of the target financial product through a first server of a sales institution of the target financial product, wherein the transaction parameters are used to characterize the restrictions on purchasing the target financial product, and the target financial product is a financial product that is specified to be sold within a preset time period; obtaining a transaction request that meets the transaction parameters uploaded by a user terminal device through the first server; determining a target transmission path from multiple data transmission paths between the first server and the second server through the first server based on the shared traffic rate of the data link between the first server and the second server; and sending the transaction request to the second server through the first server based on the target transmission path.

[0007] According to another aspect of this application, a transaction data processing apparatus for a financial product is also provided, comprising: a receiving unit, which receives transaction parameters sent by a second server of the issuing institution of the target financial product through a first server of the sales institution of the target financial product, wherein the transaction parameters are used to characterize the restrictions on purchasing the target financial product, and the target financial product is a financial product that is designated to be sold within a preset time period; an uploading unit, which obtains a transaction request that meets the transaction parameters uploaded by a user terminal device through the first server; a determining unit, which determines a target transmission path from multiple data transmission paths between the first server and the second server based on the shared traffic rate of the data link between the first server and the second server through the first server; and a sending unit, which sends the transaction request to the second server through the first server based on the target transmission path.

[0008] According to another aspect of this application, a computer-readable storage medium is also provided, which includes a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the above-described financial product transaction data processing method.

[0009] According to another aspect of this application, an electronic device is also provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the aforementioned method for processing transaction data of financial products during runtime.

[0010] According to another aspect of this application, a computer program product is also provided, including computer instructions, which, when executed by a processor, implement the steps of the transaction data processing method for the financial product described above.

[0011] In this application, the transaction parameters sent by the second server of the issuing institution of the target financial product are first received by the first server of the sales institution of the target financial product. The transaction parameters are used to characterize the restrictions on purchasing the target financial product, which is a financial product that is designated to be sold within a preset time period. Next, the transaction request that meets the transaction parameters is obtained by the user terminal device uploaded by the first server. Then, the target transmission path is determined from multiple data transmission paths between the first and second servers based on the shared traffic rate of the data link between the first and second servers. Based on the target transmission path, the transaction request is sent to the second server by the first server. That is, by intelligently selecting the most suitable transmission path, the transaction data transmission latency is reduced and the data run is avoided, thereby achieving the technical effect of improving the transaction success rate of popular financial products. This solves the technical problem in the prior art that due to the limited purchase time of popular financial products, a large amount of transaction data needs to be transmitted between the sales institution, issuing institution and user terminal device of the financial product in a short period of time, resulting in high data transmission latency and easy data run, which in turn affects the transaction success rate of popular financial products. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0013] Figure 1-1 This is a flowchart of an optional financial product transaction data processing method according to an embodiment of this application;

[0014] Figure 1-2 This is a connection diagram of a transaction data processing system for an optional financial product according to an embodiment of this application;

[0015] Figure 2 This is a schematic diagram of an optional branch application server according to an embodiment of this application;

[0016] Figure 3 This is a schematic diagram of an optional customer transaction terminal structure according to an embodiment of this application;

[0017] Figure 4 This is a schematic diagram of an optional communication server structure according to an embodiment of this application;

[0018] Figure 5 This is a flowchart illustrating an optional routing management module processing data according to an embodiment of this application;

[0019] Figure 6This is a flowchart of an optional hot financial product transaction data processing method according to an embodiment of this application;

[0020] Figure 7 This is a schematic diagram of a transaction data processing apparatus for an optional financial product according to an embodiment of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0024] According to an embodiment of this application, a method embodiment for processing transaction data of financial products is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0025] Figure 1-1 This is a flowchart of an optional financial product transaction data processing method according to an embodiment of this application, such as... Figure 1-1 As shown, the method includes the following steps:

[0026] Step S101: Receive transaction parameters sent by the second server of the target financial product's issuing institution through the first server of the target financial product's sales institution.

[0027] In step S101, the transaction parameters are used to characterize the restrictions on purchasing the target financial product, which is a financial product that is specified to be sold within a preset time period.

[0028] It should be noted that the first server of the sales institution of the target financial product can serve as the execution entity of the transaction data processing method for the financial product in this application embodiment. It is understood that the transaction data processing method for the financial product provided in this application embodiment can also be executed by other systems or devices, and this application embodiment does not specifically limit this.

[0029] Optionally, target financial products (hot financial products) refer to financial products that are launched within a specific time period and have high attractiveness (such as high returns), requiring customers to rush to purchase them within a preset sales period.

[0030] Optionally, the sales organization's first server refers to the sales organization's application server, that is, the application servers of each branch, which are responsible for receiving customer transaction requests and interacting with the product issuing organization; the issuing organization's second server refers to the product issuing party's server.

[0031] Optionally, transaction parameters describe the specific conditions for purchasing financial products, including but not limited to the start and end times of the transaction, the total inventory quota of financial products, and the quota of financial products allocated to each branch. These parameters constitute the restrictive conditions of the transaction, ensuring that the transaction is conducted fairly and orderly.

[0032] Step S102: Obtain the transaction request that meets the transaction parameters uploaded by the user terminal device through the first server.

[0033] Optionally, the system obtains the customer's request to purchase or snap up financial products sent to the bank's server through the first server, including customer information, product type, quantity, price, etc.

[0034] Step S103: Using the first server, a target transmission path is determined from multiple data transmission paths between the first server and the second server based on the shared traffic rate of the data link between the first server and the second server.

[0035] Optionally, since there may be multiple transmission lines or paths from the first server to the second server, and each path has different transmission conditions and efficiencies, the optimal data transmission path is determined from the multiple data transmission paths between the first server and the second server based on the shared traffic rate of the data link between the first server and the second server.

[0036] Step S104: Based on the target transmission path, the transaction request is sent from the first server to the second server.

[0037] Optionally, the transaction request can be sent to the second server via the first server based on the target transmission path.

[0038] Optionally, Figure 1-2 This is a connection diagram of a transaction data processing system for an optional financial product according to an embodiment of this application, such as... Figure 1-2As shown, the system includes customer transaction terminals, multiple bank branch application servers (Branch Application Servers A, B, C, D, and E), multiple bank branch communication servers (Branch Communication Servers A, B, C, D, and E), a product issuing institution communication server, and a product issuing institution application server. Each bank's customer transaction terminals connect to its branch application servers via wired or wireless networks; each bank's branch application servers connect to its branch's communication servers via the bank's fiber optic network; and each branch's communication servers are connected in pairs via dedicated fiber optic lines within the bank, forming a financial service network. The system comprises several components: a customer transaction terminal providing users with services such as financial product promotion information inquiry, wealth management product purchase, and financial product transaction; a branch application server filtering transaction requests based on configured hot financial product transaction parameters; a branch retaining valid transaction requests that meet preset hot financial product transaction conditions; a branch communication server interacting with other branch communication servers and product issuing institution communication servers; a data routing module deployed on the communication server employing load-optimized low-latency network control; a penalty function added to the ant colony algorithm to optimize congestion control, overload, and pheromone evaporation under time window transmission conditions; and a product issuing institution that can be a branch within the bank or a third-party institution. The product issuing institution's application server processes transaction requests from various branch communication servers and returns the transaction processing results to the transaction initiator via the communication server.

[0039] Optionally, Figure 2 This is a schematic diagram of an optional branch application server according to an embodiment of this application, such as... Figure 2 As shown, it includes: parameter configuration module 21, transaction filtering module 22, inventory control module 23, hot financial product transaction matching module 24, qualification generation module 25, and settlement module 26.

[0040] The parameter configuration module 21 is responsible for configuring the concurrency parameters of the branch application server, so that the branch application server limits the number of hot financial product transaction requests issued based on the concurrency parameters; the concurrency parameters include: configuration process data, maximum number of connections, and timeout time, etc.

[0041] The transaction filtering module 22 is responsible for controlling the access traffic based on the request information corresponding to each of the hot financial product transaction requests, and restricting the access traffic according to the token algorithm. This allows for filtering of each hot financial product transaction request, retaining only valid hot financial product transaction requests that meet the preset hot financial product transaction conditions. If the request interface corresponding to any URL address receives multiple hot financial product transaction requests from the same source IP, then only one hot financial product transaction request is retained as a valid hot financial product transaction request among the multiple requests from the same source IP.

[0042] The inventory control module 23 is responsible for storing the quotas for trading activities of hot financial products and setting up counters. The counters correspond to tokens. When the total number of hot financial product trading requests exceeds the inventory quota, the hot financial product trading requests will be blocked, thereby preventing the communication server from being overwhelmed by a huge amount of hot financial product trading request data due to excessive hot financial product trading requests.

[0043] The hot-spot financial product transaction matching module 24 is responsible for matching each transaction request for the hot-spot financial product with each inventory quota in the inventory control module. The module uses a list monitoring command to monitor in real time whether there are any unmatched inventory quotas in the product inventory queue. When the list monitoring command detects unmatched inventory quotas in the product inventory queue, it matches each transaction request with each inventory quota in the product inventory queue.

[0044] The qualification generation module 25 is responsible for binding the customer corresponding to the valid hot financial product transaction request to the inventory quota that matches the transaction request when any valid hot financial product transaction request is successfully matched with any inventory quota, and generating the order qualification certificate corresponding to the customer.

[0045] Settlement module 26 is responsible for settling customer transactions after receiving confirmation of successful transaction results from the product issuing institution's application server. It generates corresponding settlement orders based on order submission requests and returns the transaction results to the corresponding customer's trading terminal. The reserved order includes the financial product name, price, type, transaction time, and product reservation number. The settlement order includes the financial product name, price, type, transaction time, settlement time, and order number.

[0046] As can be seen from steps S101 to S104, in this application, firstly, the first server of the sales institution of the target financial product receives transaction parameters sent by the second server of the issuing institution of the target financial product. These transaction parameters characterize the restrictions on purchasing the target financial product, which is a financial product designated for sale within a preset time period. Secondly, the first server obtains transaction requests uploaded by user terminal devices that meet the transaction parameters. Then, based on the shared traffic rate of the data link between the first and second servers, the first server determines the target transmission path from multiple data transmission paths between the first and second servers. Based on the target transmission path, the first server sends the transaction request to the second server. This intelligent selection of the most suitable transmission path reduces transaction data transmission latency and avoids data runs, thereby improving the success rate of transactions for popular financial products. This solves the technical problem in the prior art where the limited purchase time of popular financial products leads to a large amount of transaction data needing to be transmitted between the sales institution, issuing institution, and user terminal devices within a short period, resulting in high data transmission latency and a tendency for data runs, thus affecting the success rate of transactions for popular financial products.

[0047] In one optional embodiment, the transaction parameters include at least one of the following parameters: a first parameter for limiting the transaction time of the target financial product; a second parameter for limiting the total quantity of the target financial product; a third parameter for limiting the maximum number of target financial products that each sales institution can sell; a fourth parameter for limiting the target financial product's purchase group; and a fifth parameter for limiting the maximum number of communication connections between the first server and the second server.

[0048] Optionally, the first parameter is set as the start and end time of the activity, ensuring that all customers can submit transaction requests within the specified time window. The second parameter controls the total quantity of the target financial product; for example, for a limited-edition wealth management product, the second parameter might be set to 1000 units. When the total quota is reached or exceeded, the system will automatically stop accepting new transaction requests. The third parameter limits the maximum number of target financial products that each branch can sell. For instance, if the total quota for a product is 1000 units, the third parameter might be set to no more than 100 units per branch, thus ensuring that even if some branches have a large number of customers, the maximum number of units that can be sold is limited. It also prevents the monopolization of all quotas, ensuring a reasonable allocation of products among different branches; the fourth parameter is used to limit the eligibility of the target financial product purchasers, such as restricting certain wealth management products to be open only to members or customers in specific regions. Through the eligibility parameter, the system can verify the identity and eligibility of customers, ensuring that only qualified customers can participate in transaction activities; the fifth parameter is used to limit the maximum number of communication connections between the first server and the second server. For example, setting the maximum number of connections to 1000 can prevent the communication server from being overwhelmed by a large number of connection requests in a short period of time, thereby reducing system processing latency and improving the efficiency of transaction data transmission.

[0049] As can be seen from the above, by implementing the aforementioned transaction parameter restrictions, the first server can effectively manage high-concurrency transaction activities, ensure the secure transmission of transaction data, and improve the system's response speed and processing efficiency. Furthermore, these parameter settings also protect the fair allocation of financial products among different branches, avoiding overselling or monopolistic practices by specific groups, improving user experience, and enhancing the system's stability and reliability during peak transaction periods.

[0050] In one optional embodiment, the first server sends transaction parameters and traffic restrictions to the application server of the sales organization. The traffic restrictions are used to limit the access traffic between the application server and the user terminal device through a token bucket algorithm. The application server is an intermediate server between the user terminal device and the first server. The application server is used to filter transaction requests based on the transaction parameters and traffic restrictions.

[0051] Optionally, the first server pre-sets transaction parameters for popular financial products, including but not limited to the start and end times of financial product trading activities, the total inventory quota of financial products, the quota of financial products allocated to each branch, and the eligibility parameters for participants in financial products. Simultaneously, the first server configures traffic limiting conditions based on a token bucket algorithm to control access traffic between the application server and user terminal devices. These traffic limiting conditions include the maximum number of connections and timeout period, and these parameters are distributed to the application servers of each bank branch acting as intermediary servers via secure communication channels.

[0052] It's important to note that the token bucket algorithm is a flow control mechanism used to smooth the rate of data packet transmission, prevent network congestion, and manage bandwidth limiting and bursts of traffic. It can be likened to a bucket that stores a certain number of tokens; data packets need to obtain a token from this bucket before transmission, and transmission is delayed or rejected if no token is available.

[0053] As can be seen from the above, the introduction of traffic limiting conditions, especially the application of the token bucket algorithm, ensures that the banking system can operate stably in a high-concurrency transaction environment, effectively avoiding system overload and data congestion.

[0054] In one optional embodiment, a request information packet is obtained from the application server of the sales organization through a first server. The request information packet includes at least the following information: multiple transaction requests that meet the transaction parameters; the network identifier of the user terminal device that initiates each transaction request; and the user information of the user who initiates each transaction request.

[0055] Optionally, when the activity begins, customer transaction requests are submitted to the sales organization's application server, i.e., the product issuing organization's application server. These requests are preprocessed, for example, by filtering out eligible transaction requests based on transaction parameters. The application server then packages these requests into request packets and sends them to the first server. The request packet includes at least the following key information: multiple transaction requests that meet the transaction parameters, ensuring that the requests received by the first server are valid and compliant, providing a basis for subsequent data processing and routing; the network identifier of the user terminal device initiating each transaction request, such as its IP (Internet Protocol) address, used to track and verify the source of the transaction request, improving the traceability of transaction data; and the user information of the initiating user for each transaction request, such as user ID (Identification) and account information, used to confirm user identity and ensure the legality of the transaction.

[0056] As can be seen from the above, the purpose of obtaining request packets is to ensure that the first server can receive all valid transaction requests from the client. These request packets contain all the necessary information required to process the transaction, thus laying the foundation for subsequent data transmission path optimization and transaction processing.

[0057] In one optional embodiment, the first server determines the ant colony based on a target rule, wherein the ant colony represents the search process for data transmission paths, the target rule is used to dynamically update the selection of data transmission paths based on pheromones and path distances, then updates the pheromones based on the shared traffic rate at the target time and the path lengths already traversed by the ant colony, and then determines the target transmission path from multiple data transmission paths between the first server and the second server based on the updated pheromones.

[0058] Optionally, before the activity begins, the first server initializes the ant colony optimization (ACO) algorithm according to the target rules. The ant colony optimization (ACO) algorithm is used here to characterize the search process for data transmission paths, simulating the behavior of ants searching for food in nature. The target rules define how to dynamically update the selection of data transmission paths based on pheromones (representing path preference) and path distance (another factor influencing path selection). This rule ensures that the algorithm can adjust its routing strategy in real time to changes in network conditions, improving the efficiency and security of data transmission.

[0059] Optionally, after determining the ant colony, the first server updates the pheromone based on the shared traffic rate at the target time and the path length already traversed by the ant colony. The shared traffic rate reflects the data transmission rate on the current network link and is a crucial real-time parameter influencing path selection. Path length represents the number of nodes or link distance that a data packet has traversed from the source to the destination. Updating the pheromone aims to reflect path usage and performance changes; for example, pheromone concentration increases for paths with high traffic rates and short path lengths, and decreases vice versa. This dynamic mechanism allows the system to automatically identify and prioritize the currently optimal transmission path. Based on the updated pheromone concentration, the first server determines the target transmission path from multiple data transmission paths between itself and the second server.

[0060] As described above, the first server dynamically optimizes the data transmission path with the second server by applying an optimized ant colony algorithm. Specifically, it dynamically updates pheromones to reflect network conditions in real time, ensuring the selection of the optimal path during data transmission. This mechanism not only significantly reduces data transmission latency and improves the efficiency of processing transaction data for hot financial products, but also enhances data transmission security, especially when handling high-concurrency requests, effectively avoiding network congestion and improving user experience. Furthermore, the dynamic path selection mechanism continuously optimizes network transmission strategies, enabling the system to respond quickly to real-time network changes, ensuring fast and reliable transmission of financial transaction data, and enhancing the overall performance and stability of the bank's transaction system.

[0061] In one optional embodiment, the first server detects the capacity of the data link, where capacity represents the maximum transmission rate of the data link; detects the average utilization of transaction requests entering the data link, where average utilization represents the ratio of total bandwidth to capacity when transaction requests enter the data link; detects the average round-trip time of transaction requests traversing the data link; and detects the average queue size of the data link at the target time, where the average queue size represents the amount of data waiting to be sent in the data link. Then, based on the capacity, average utilization, average round-trip time, and average queue size, the shared traffic rate of the data link at the target time is determined.

[0062] Optionally, the first server periodically monitors the data link capacity, which refers to the maximum transmission rate of the data link at a certain point in time, usually measured in bits per second (bps). This monitoring helps to understand the currently available bandwidth resources, providing a basis for subsequent flow control and path selection. The capacity of the data link directly affects the efficiency and speed of data transmission. The server also monitors the average utilization rate of transaction requests entering the data link. Average utilization rate is the ratio of the total bandwidth to the link capacity when transaction requests enter the data link at a target time. The first server can calculate the average utilization rate by analyzing the data link flow rate over a period of time. This parameter reflects the usage of the data link and helps the first server determine whether there is bandwidth waste or... The system detects link overload by detecting the average round-trip time (RTT) of transaction requests traversing the data link. RTT measures the average time it takes for a data packet to travel from source to destination and back. At the destination time, the first server detects the RTT of transaction requests traversing the data link, which helps assess data transmission efficiency and network latency. A lower RTT indicates faster data transmission speed and better network performance. The system also detects the average queue size of the data link, which refers to the amount of data waiting to be sent in the data link at the destination time. By monitoring the queue status, the first server can understand the current congestion on the link. A larger queue size means the link may be close to saturation, requiring measures to prevent data packet loss or delay.

[0063] Optionally, based on the detected capacity, average utilization, average round-trip time, and average queue size, the first server calculates the fair shared traffic rate (shared traffic rate) of the data link at the target time.

[0064] As described above, by monitoring the data link's capacity, average utilization, average round-trip time, and average queue size through the first server, the fair shared traffic rate of the data link at the target time is effectively determined. This mechanism not only ensures the rapid transmission of transaction requests for popular financial products but also avoids network congestion and resource waste through real-time monitoring of network status, ensuring the stability and security of data transmission. Furthermore, by dynamically adjusting the shared traffic rate, this embodiment can adapt to changes in network traffic, providing a highly efficient solution for handling instantaneous high-concurrency transaction requests for banking systems, significantly improving transaction processing efficiency and user experience.

[0065] In one optional embodiment, the first server first detects the data size of the transaction request, then determines the time range in which the transaction request arrives at the second server, and then detects the load parameter, which represents the load of the data link when the ant colony passes through the first server at the target time. Next, it detects the time parameter, which represents the degree of matching between the time of arrival of the transaction request at the second server and the time range selected by the ant colony when it passes through the first server at the target time. Then, based on the data size of the transaction request, the time range in which the transaction request arrives at the second server, the load parameter, and the time parameter, a path distance function is determined. Finally, based on the path distance function and the updated pheromone, a target transmission path is determined from multiple data transmission paths between the first and second servers.

[0066] Optionally, when the first server receives a transaction request, it detects and records the data size of each request. This step aims to assess the potential impact of each request on the data link. Detecting the data size helps with subsequent path selection and flow control, ensuring the rational allocation of network resources. Then, based on the nature and requirements of the transaction activity, the first server determines the time range from its origin to the second server for the transaction request. This time range may be based on the start and end times of the activity and the priority of transaction processing. Determining the time range helps optimize the transmission order of transaction requests, ensuring that transactions are completed within the effective timeframe. Finally, the first server detects the load on the data link; the load parameter reflects the link's performance. The first server assesses the workload of processing transaction requests and then further examines time parameters. These parameters reflect the degree of match between the arrival time of the transaction request to the second server, following the current path selection, and the predetermined time range. Subsequently, based on the data size of the transaction request, the arrival time range, the load parameters of the data link, and the time parameters, the first server calculates the path distance function. The path distance function is a quantitative indicator used to evaluate the merits of different paths. It comprehensively considers the physical distance of the path, network latency, bandwidth usage, and time window matching degree, providing data support for the subsequent selection of the optimal path. Finally, the first server determines the optimal target transmission path from multiple data transmission paths based on the path distance function and the updated pheromone concentration.

[0067] Alternatively, the path distance function μ is as shown in formula (1):

[0068]

[0069] Where size represents the data size, w represents the time range, and δ j (k,t) represents the load parameter (the load on the link when ant colony k passes through path j at time t), ε j (k,t) represents the time parameter (the degree of conformity between the path selection and the time window when ant colony k passes through path j at time t).

[0070] As described above, intelligent optimization of data transmission paths is achieved through this method. First, by detecting the data size, time range, data link load, and time parameters of transaction requests, the impact of transaction requests on the network can be comprehensively assessed, providing a basis for path selection. Second, the determination of the path distance function allows the first server to quantitatively compare the advantages and disadvantages of different paths, ensuring the selection of the most suitable transmission path. Finally, by combining the ant colony algorithm and pheromone update mechanism, the optimal path is dynamically selected, avoiding network congestion and improving the timeliness and stability of data transmission.

[0071] In one optional embodiment, the first server detects the shared traffic rate of the data link at time tT, where T is a preset shared traffic rate update period for the data link, and then determines the shared traffic rate of the data link at time t based on capacity, average utilization, average round-trip time, average queue size and the shared traffic rate of the data link at time tT.

[0072] Optionally, the first server periodically monitors the shared traffic rate of the data link at time tT. Simultaneously, the first server collects multiple real-time network parameters, including the data link capacity (i.e., maximum transmission rate), the average utilization rate of transaction requests entering the data link, the average round-trip time of transaction requests traversing the data link, and the average queue size of the data link at time t. These parameters reflect the current status and performance of the link, including bandwidth resource utilization, data transmission latency, and network congestion. Based on the shared traffic rate at time tT, combined with the currently collected network parameters (capacity, average utilization rate, average round-trip time, and average queue size), the first server calculates the shared traffic rate of the data link at time t. This calculation process comprehensively considers the real-time status and historical performance of the link, ensuring that the traffic rate setting fully utilizes the link's bandwidth resources while avoiding network congestion and latency, maintaining the stability and efficiency of data transmission.

[0073] Optionally, the shared flow rate R(t) is calculated as shown in formula (2):

[0074]

[0075] Where t represents the current time, T represents the time interval for rate updates, C is the capacity, y(t) is the average utilization of the incoming link, d is the average round-trip time of traffic (historical transaction requests) traversing the link, q(t) is the average queue size, and γ and δ are configurable parameters (used to adjust the degree of influence of y(t) and q(t) on the shared traffic rate R(t). They are configurable weight parameters in the RCP algorithm (Rate Control Protocol, a rate-based congestion control algorithm). The values ​​of γ and δ determine the relative importance of average utilization and queue size when calculating the new shared traffic rate).

[0076] As described above, the first server provides a mechanism for dynamically updating the shared traffic rate, effectively improving the banking system's ability to process transaction data for hot financial products. Firstly, by periodically detecting the shared traffic rate at time tT and combining it with real-time network parameters, the first server can accurately calculate the shared traffic rate at time t, avoiding excessive use of data links or resource waste. Secondly, the updated traffic rate guides the rational scheduling of transaction requests, ensuring that data packets arrive safely at their destination in the shortest possible time, improving transaction response speed and success rate. Finally, the strategy of dynamically adjusting the traffic rate enhances the system's adaptability and flexibility, maintaining data transmission stability even when the network environment changes, providing a reliable solution for high-concurrency transaction processing for the banking system, and significantly improving user experience and transaction security.

[0077] In one optional embodiment, the first server obtains the pheromone concentration on the h-th data transmission path from the first server to the second server, wherein the pheromone concentration is proportional to the usage frequency of the h-th data transmission path, and the h-th data transmission path is any data transmission path between the first server and the second server. Then, the reciprocal of the path distance of the h-th data transmission path is used as a heuristic value. Then, based on the heuristic value and the pheromone concentration, the probability of the ant colony choosing the h-th data transmission path to move from the first server to the second server is determined. Finally, the target rule is determined based on the probability, and the ant colony is initialized according to the target rule.

[0078] Optionally, the first server first obtains the pheromone concentration on the h-th data transmission path from the first server to the second server. Through this mechanism, the first server can identify which paths are relatively busy or reliable in the current environment. After obtaining the pheromone concentration, the first server uses the reciprocal of the path distance of the h-th data transmission path as a heuristic value. The reciprocal of the path distance reflects the shortness of the path; the shorter the path, the larger the heuristic value, indicating a greater advantage in distance. The heuristic value is an important parameter in the ant colony algorithm that guides the ant colony to choose a path. It, along with the pheromone concentration, affects the path selection probability. Then, based on the heuristic value and pheromone concentration of the h-th data transmission path... In the ant colony algorithm, the first server calculates the probability that the ant colony will choose a path to move from the first server to the second server. This probability calculation is the core of the algorithm, as it comprehensively considers the distance advantage and historical usage of the path, making the ant colony more inclined to choose paths that are short, frequently used, and currently in good condition. This improves the efficiency and timeliness of data transmission. Finally, the first server determines the target rule based on the calculated path selection probability and initializes the ant colony according to the target rule. The target rule defines how the ant colony considers the relative importance of pheromone concentration and heuristic value in path selection. Initializing the ant colony sets its initial state, including the number of ants and their location. This step prepares the ant colony for the path search process, ensuring that data transmission paths can be dynamically optimized based on the latest network conditions and historical data.

[0079] As can be seen from the above, by using the above method, the first server can continuously optimize path selection when handling instantaneous high-concurrency transaction requests, avoid network congestion, and ensure the stability and security of data transmission.

[0080] In one alternative embodiment, the first server obtains a first parameter, which is used to balance the dependence on heuristic value and pheromone concentration when selecting a data transmission path. Then, it detects the set of data transmission nodes that the ant colony can choose to move from the first server to the second server. Then, based on the first parameter, the set, the heuristic value, and the pheromone concentration, it determines the probability that the ant colony will choose the h-th data transmission path to move from the first server to the second server.

[0081] Optionally, the first server first obtains a first parameter, which is used to balance the importance of heuristic value and pheromone concentration when selecting a data transmission path. Then, the first server detects the set of data transmission nodes that the ant colony can choose from to move from the first server to the second server. This set includes all possible data transmission nodes, including communication servers of various bank branches and network switches within the bank. The purpose of detecting the set is to determine the currently available transmission paths so as to facilitate subsequent path probability calculations. Then, based on the obtained first parameter, the set of data transmission nodes, the heuristic value, and the pheromone concentration, the probability of the ant colony choosing the h-th data transmission path to move from the first server to the second server is determined.

[0082] Optionally, the above probability p k The calculation method for (a,b) is shown in formula (3):

[0083]

[0084] Where, p k (a,b) represents the probability that the ant colony chooses the h-th data transmission path (path a to b), J k (r) is the set of data transmission nodes that ant colony k (from a to b) can choose from (the set of data transmission nodes that the ant colony can choose from when moving from the first server to the second server), β is the first parameter, τ is the pheromone concentration, τ(a,b) represents the pheromone concentration on the path from a to b, μ(a,b) represents the heuristic value of the path from a to b (μ = 1 / δ(a,b) represents the reciprocal of the path distance δ(a,b) between a and b), a and b represent the first node and the second node, respectively. Usually, β>0, and the variable s represents the next node that ant colony k may choose from the current node a. This represents the weighted sum of pheromone heuristic values ​​from node a to all possible next nodes b.

[0085] As can be seen from the above, the first server significantly improves the path selection efficiency and reliability of the hot financial product transaction data processing system in a high-concurrency environment by setting the first parameter, detecting the data transmission node set, and calculating the path selection probability.

[0086] In one optional embodiment, the first server determines the target transmission path from the first server to the second server at the target time based on the random value, the preset constant parameter, the target random variable, the updated pheromone, and the path distance function. The random value is a value randomly determined from the data range of 0 to 1, the preset constant parameter is a constant greater than or equal to 0 and less than or equal to 1, and the target random variable is a variable randomly selected according to the target rules.

[0087] Optionally, the first server determines the target transmission path based on a random value, a preset constant parameter, a target random variable, the updated pheromone, and a path distance function. This path is the optimal path selected by the intelligent algorithm among all possible paths from the first server to the second server at the target time, comprehensively considering factors such as randomness, pheromone concentration, and physical distance.

[0088] Optionally, the calculation method of the target communication path s is shown in formula (4):

[0089]

[0090] where q is a random value distributed in [0...1], q0 (0 ≤ q0 ≤ 1) is a constant parameter (preset constant parameter), S is a randomly selected variable (target random variable) that follows the state transition rule, and τ(a,u) is the updated pheromone.

[0091] Optionally, in formula (4) is to find which of all possible next nodes b from node a to node set J k (a) has the highest comprehensive evaluation value. The comprehensive evaluation value consists of two parts: the pheromone concentration (τ(a,u)) and the β power of the path heuristic value (μ(a,u)). The pheromone concentration reflects the frequency of past data packets or ant colonies using this path, and the heuristic value is usually related to the reciprocal of the path distance, indicating the relative attractiveness of the path. β is a parameter that controls the relative importance of the pheromone and the heuristic value. When β is larger, the heuristic value plays a more important role, and when β is smaller, the influence of the pheromone concentration is more significant. If the random number q is less than the preset threshold q0, then ant colony k will select the node b with the highest comprehensive evaluation value as the next node to move to. If the condition (q < q0) is not established, that is, q is greater than or equal to q0, then ant colony k will randomly select a node from all possible next nodes (J k (a)) as the target node S.

[0092] As can be seen from the above, the first server realizes the intelligent path selection from the first server to the second server at the target time, ensuring that the transaction data can be transmitted through the optimal path. By dynamically adjusting the pheromone concentration and optimizing the path distance function, this embodiment effectively improves the ability to process instantaneous high-concurrency transaction requests, reduces network latency, improves the stability and security of transaction data transmission, provides an optimized solution for transaction processing in a high-concurrency environment for the banking system, and significantly enhances the user experience and the overall performance of the banking system.

[0093] In one optional embodiment, a communication encryption protocol is sent to the user terminal device through a first server. The communication encryption protocol is used to generate a registered account, key information bound to the user, and a personal digital certificate for the user based on the user information provided by the user. After the registered account is generated, a master key, user key, and public key corresponding to the registered account are generated. The first server then receives a transaction request from the user terminal device that meets the transaction parameters after being encrypted based on the communication encryption protocol.

[0094] Optionally, the first server sends a communication encryption protocol to the user terminal device. This protocol includes rules for key generation and data encryption, used to generate a registered account, key information bound to the account (including a master key and a user key), and a personal digital certificate based on the information provided by the user. The user registers by submitting relevant personal information through the interface provided by the communication encryption protocol on the terminal device. After receiving this information, the first server generates a registered account for the user and generates a master key and a user key corresponding to the account. The master key is used to encrypt and decrypt transaction data, while the user key is used to protect the security of the user's personal data. After generating the registered account and key information, the first server generates a personal digital certificate for the user. The digital certificate contains the user's registration information and public key, used to prove the legitimacy of the user's identity and the integrity of the transaction data. After completing registration and obtaining the key information and digital certificate, the user terminal device can use the communication encryption protocol to encrypt transaction requests. The encrypted transaction requests are transmitted to the bank's internal system for processing through the first server. The first server receives these encrypted transaction requests, ensuring the security of transaction data during transmission. Even if attacked in the network environment, the transaction information can be protected.

[0095] As can be seen from the above, the first server ensures the secure processing of transaction data through the aforementioned methods, providing users with a safe and convenient financial product trading environment.

[0096] In one optional embodiment, the first server obtains the generator and order of the bijective group, wherein the generator represents the set of elements that generate the entire bijective group, and the order represents the total number of elements in the bijective group. Then, it randomly selects a first value, a second value, and a third value, wherein the first value, the second value, and the third value are different values. Then, it generates a master key based on the first value, the second value, and the generator. Then, it generates a user key based on the generator, the third value, and the first value. Finally, it generates a public key based on the generator, the order, the first value, and the second value.

[0097] Optionally, the first server first obtains the generator and order of a bijective group. The generator is an element that can generate the entire bijective group (a finite set of elements with certain specific properties), while the order represents the total number of elements in the bijective group. By explicitly defining the generator and order of the bijective group, the first server can ensure the determinism and security of the key generation process. Next, the first server randomly selects three distinct values. These random values ​​are crucial for key generation, and their selection must follow cryptographic security principles to ensure that the generated key has sufficient randomness and complexity to resist potential cryptographic attacks. Then, the first server generates a master key based on the first value, the second value, and the generator. Next, the first server generates a user key based on the generator, the third value, and the first value. Finally, the first server generates a public key based on the generator, the order of the bijective group, and the first and second values.

[0098] Optionally, Figure 3 This is a schematic diagram of an optional customer transaction terminal structure according to an embodiment of this application, such as... Figure 3 As shown, the customer transaction terminal can be a user's smartphone, tablet, laptop, or other terminal device. The device may include: a user registration module 31, a key generation module 32, a transaction query module 33, and a transaction request module 34. The user registration module 31 provides an interface for bank customers to register on the system and obtain a bank user identity. During registration, customers need to submit relevant personal identity information. After successful registration, they download the relevant key and personal digital certificate to ensure data security during transactions. The key generation module 32 generates a master key M for the customer after successful registration. k and user key S k The specific generation method is as follows:

[0099] Step 1: After a customer successfully registers, the system submits a request to initialize security parameters;

[0100] Step 2: After receiving the request, the client calls the key initialization module `setup` to generate the master key; then it calls the key generation module to generate the key `S`. k The specific steps are as follows:

[0101] (1) Initialization (Setup): The setup module selects a bijective group G0 with generators g and prime order p. In Z p Two random numbers α, β ∈ Z are randomly selected. p As an index, the master key M is obtained from the random numbers α and β and the generator g. k The calculation method is shown in formula (5), and the public key PK is represented as a tuple as shown in formula (6):

[0102] M k =(β,g α (5)

[0103]

[0104] Among them, DID H ∈DID represents the DID (digital identity) of the digital file owner, and e(g,g) is a value calculated on the generator (g) using the bilinear mapping (e).

[0105] (2) Generate key S k : Supplementary input parameters, represented as keyGen(M) k ,S), where M k The function takes the master key S as its value and the set of attributes S (containing all attributes or services that the key holder has the right to access or operate). The value produced by this function is the key S. k The key is represented as shown in formula (7):

[0106]

[0107] Where, r∈Z p For each attribute j∈S, r is a random number. j ∈Z p It is a random number. It is a hash function used to convert attribute j into a fixed-length numeric value, r. j It is a random number associated with attribute j, used to generate the attribute-related key part.

[0108] Step 3: Call the encryption algorithm to initialize the security parameters.

[0109] Step 4: Perform evidence storage process to store the user's public key and master key.

[0110] Step 5: Transfer the Digital Identity (DID) and Master Key (M) k The user's public key PK is stored as evidence, and the following encryption function is executed to encrypt the symmetric key, generating the symmetric key pk. b ciphertext The encrypted message is then sent back to the user, and its representation is shown in formula (8):

[0111]

[0112] Encry is an encryption function used to encrypt plaintext data into ciphertext, sk b This represents the user's private key.

[0113] Step 6: Send the security parameters back to the client, store the symmetric private key locally, and return a message indicating successful initialization of the security parameters.

[0114] The transaction query module 33 is responsible for providing the interface and interface to customers, who can query the financial products that can be traded and query historical transaction records; the transaction request module 34 is responsible for providing the interface and interface to customers, who can submit buy and sell transaction requests to the bank application server. The request data includes at least the type, quantity, and price of the financial products to be bought or sold.

[0115] As can be seen from the above, the first server, by defining the generator and order of the bijective group and combining it with randomly selected values ​​to generate the master key, user key, and public key, has constructed a key generation mechanism based on the bijective group, which significantly improves the security of transaction data for hot financial products.

[0116] In one optional embodiment, when the first server detects that the ant colony has traversed the h-th data transmission path, it determines the incremental update value corresponding to the pheromone concentration based on the shared traffic rate and the length of the path already traversed by the ant colony. When it detects that the ant colony has not traversed the h-th data transmission path, it determines the incremental update value corresponding to the pheromone concentration to be 0. Finally, it updates the pheromone based on the incremental update value, the number of ant colonies, and the pheromone decay factor, wherein the pheromone decay factor is used to simulate the rate at which the pheromone disappears over time.

[0117] Optionally, during the transmission of transaction requests, the first server continuously monitors the movement path of the ant colony and detects whether the ant colony has traversed the h-th data transmission path. When it detects that the ant colony has traversed the h-th data transmission path, the first server calculates the incremental update value corresponding to the pheromone concentration based on the shared traffic rate and the length of the path already traversed by the ant colony. If the first server detects that the ant colony has not traversed the h-th data transmission path, it determines that the incremental update value corresponding to the pheromone concentration is 0. This means that unused paths will not receive additional concentration increases in the current round of pheromone updates. The purpose of this is to avoid excessive preference for unverified paths and maintain the fairness and diversity of path selection. Finally, the first server updates the pheromone concentration based on the incremental update value determined above, the number of ant colonies, and the pheromone decay factor. The pheromone decay factor is used to simulate the rate at which pheromones disappear over time, ensuring that the pheromone concentration can reflect the latest usage of the path.

[0118] Optionally, the incremental update value Δτ corresponding to the pheromone concentration k The calculation method for (a,b) is shown in formula (9):

[0119]

[0120] Where R(t) is the shared flow rate, L k Let be the path length traversed by ant colony k. Formula (9) means that if (a,b)∈Routes for every k holds true, that is, ant colony k has indeed traversed the path from node a to node b during the current search process, then Δτ k (a, b) will be set to If the condition if(a,b)∈Routes for every k does not hold, meaning the ant colony k has not used the path from node a to node b, then Δτ k (a,b) will be set to 0.

[0121] Optionally, the pheromone update rule τ(a,b) is as shown in formula (10):

[0122]

[0123] Where 0<α<1 represents the pheromone decay factor, and m represents the ant colony size.

[0124] Optionally, Equation (10) indicates that the update of pheromone concentration includes both the decay of pheromones (achieved through ((1-α).τ(a,b)) and the incremental update of pheromone concentration for all ant colonies k that have traversed the path, based on their path selection (through (Partial implementation).

[0125] As described above, the first server provides a dynamic pheromone update mechanism based on the ant colony algorithm to optimize the transmission path of transaction data for popular financial products. First, by detecting the paths traversed by the ant colony, the utilization efficiency and traffic conditions of each path can be accurately assessed. Next, based on the target traffic rate and the length of the path, the pheromone concentration is dynamically adjusted, implementing a reward mechanism for efficient paths. Finally, by employing a pheromone decay factor, a dynamic balance in path selection is maintained.

[0126] In one alternative embodiment, Figure 4 This is a schematic diagram of an optional communication server structure according to an embodiment of this application, such as... Figure 4As shown, the communication server includes a communication module 41, a traffic acquisition module 42, a security calculation module 43, a message processing module 44, and a routing management module 45. The communication module 41 serves as the entry point for the data transmission node, interacting with other communication servers to send and receive data packets. The traffic acquisition module 42 is responsible for collecting traffic data for the data transmission node, managing network traffic, and tracking, collecting, and recording data transmission traffic. The secure computing module 43 is responsible for using cryptographic algorithms to encrypt and decrypt the generated data packets. The packet processing module 44 is responsible for parsing and splitting user data, forming data vectors, and assembling user data packets. Table 1 shows an example of an optional packet format according to an embodiment of this application. As shown in Table 1, the IP header represents the data packet header, Next hop represents the next-hop routing information, type represents the message type (TYPE=0x1 indicates a sent message, TYPE=0x2 indicates a received message, etc.), reserved represents the receiver's public key, sender represents the sender's public key, SwitchID represents the switch ID, QueueSize represents the queue length, ephemeral represents a temporary credential, timestamp represents the sending timestamp, mac1 represents physical address 1, mac2 represents physical address 2, and static represents static information. In this table, bytes refers to the basic unit of data storage or transmission, i.e., bytes. For example, in the given table, mac1 (16 bytes) and mac2 (16 bytes) represent the physical address (MAC address) field, with each MAC address occupying 16 bytes of storage space. Furthermore, to ensure the integrity and security of data packets during network transmission, the intelligent processing system generates hash-format header information corresponding to the data packets using a hash algorithm. The generation method of the hash-format header information is shown in formula (11):

[0127] H i =Hash(Hash(Construct)||PK(i)) (11)

[0128] Where Hash represents the SHA-256 hash algorithm (Secure Hash Algorithm 256-bit), Construct represents the content information of the structure, PK(i) represents the public key of data transmission node i, and || represents the byte sequence concatenation operator.

[0129] Table 1

[0130]

[0131] Routing Management Module 45: Responsible for managing the routing of data transmission packets, including saving, deleting, and adding routing information. The routing management module's execution includes two phases: initialization and dynamic pheromone updating. This module's operating principle involves two algorithms (Congestion Control Program (RCP) and Ant Colony Algorithm), as detailed below:

[0132] Phase 1: Initialization

[0133] Step 1: Assume there are m concurrent processes, and divide the n data packets of the data asset into m equal parts;

[0134] Step 2: Let the value of the pheromone τ(a,b) be a constant c, and initialize it as τ(a,b)=c, where a and b represent the source node and the destination node, respectively;

[0135] Step 3: Initialize the pheromone gain Δτ(a,b) k =0.

[0136] Step 4: Initialize C as the link capacity, α, β, γ and δ as constants, and d0 (representing the average flow velocity), calculated as shown in formula (12):

[0137]

[0138] Where, d i (t) represents the instantaneous flow rate of link i at time t, d0 represents the average flow rate (average transmission rate), and C represents the capacity of the data link.

[0139] Phase Two: Low-Latency Network Control Routing Strategy Algorithm

[0140] Input: Number of concurrent processes M, number of data asset partitions N;

[0141] Output: Shortest low-latency network control routing policy;

[0142] The algorithm steps are as follows:

[0143] Step 1: Collect traffic data. The traffic collection module periodically collects information such as switch ID, queue size, link utilization, and average shared link rate, calculates d0, and updates the corresponding variables in local memory. For example, (PUSH[SwitchID]; PUSH[QueueSize]; PUSH[LinkUtilization]; PUSH[Average Shared Rate]).

[0144] Step 2: Initialize the dynamic update routing algorithm parameters. Construct the 1-MTSP parameter set, initialize the pheromone matrix PM, and initialize the solution s. kLet Shortest be the optimal path in each iteration;

[0145] Step 3: Initialize ant colony routing information and calculate heuristic information for each node;

[0146] Step 4: If the number of iterations is less than N max Then the following loop process will be performed:

[0147] Step 5: For each process k≤m, perform the following steps:

[0148] Step 5.1: For each node i≤n, perform the following steps:

[0149] Step 5.1.1: Perform the following calculation steps of the flow rate control protocol to calculate the fair shared rate for each link (as in formula (2));

[0150] Step 5.1.2: Execute the following state transition function to calculate the pheromone from the ant colony to each node (as shown in formula (3));

[0151] Step 5.1.2.1: Update pheromone τ(a,b). The pheromone parameters are updated iteratively. The basic idea is that the concentration of pheromone is proportional to the fair sharing rate. The specific method for updating pheromone is as follows: calculate the pheromone concentration based on the path distance μ and the fair sharing rate R(t) of the link, and continuously update the pheromone τ. The pheromone update rules are as shown in formulas (9)-(10).

[0152] Step 5.1.2.2: If a node satisfies the constraints, add that node to the solution s. k ;

[0153] Step 5.1.2.3: Obtain the file fragment size (size) (assuming all file fragment sizes are the same), and the time window w, where w is a time range [e i ,l i ], e i Indicates the earliest arrival time, l i This represents the latest arrival time (stay time is negligible). The path distance function μ for optimizing the pheromone transfer matrix is ​​then adjusted as follows: Formally represented as formula (1);

[0154] Step 5.1.3: If a node does not meet the constraints, start searching for the next node;

[0155] Step 6: For each process k≤m, perform the following steps:

[0156] Step 6.1: Calculate the length of each path and update the shortest path (shortest);

[0157] Step 6.1.1: For each node i≤n, perform the following steps to update the pheromone function:

[0158] Step 6.1.1.2: Update the pheromone matrix PM;

[0159] Step 6.1.1.3: Set the unupdated paths to the worst-case scenario;

[0160] Step 7: Output the best routing information. The best route selection is to select the best path s based on the pheromone concentration, as shown in formula (4).

[0161] In one alternative embodiment, Figure 5 This is a flowchart illustrating an optional routing management module processing data according to an embodiment of this application, such as... Figure 5 As shown, the steps include: Step S501: Initialize security parameters, ant colony parameters, generate public and private keys, such as the initialization parameters of the elliptic curve algorithm X25519 used in this example; Execute the GenKey() function, for each data transmission node i (i∈[1,n]), generate the public key pk(i) and private key sk(i) of the data transmission node i in a loop, and upload pk(i) to the blockchain for evidence storage; in form as shown in formula (13):

[0162] (pk(i),sk(i))=genkey(1 k (13)

[0163] Among them, 1 k It represents a k-bit binary number where all bits are 1.

[0164] Step S502: For each process or ant colony k (k∈[1,n]), perform the following processing in a loop;

[0165] Step S503: For all nodes i (i∈[1,n]), if i is not the target node, execute the following loop;

[0166] Step S504: Perform the following calculation steps of the flow rate control protocol to calculate the fair shared rate R(t) for each link (Formula (2));

[0167] Step S505: Initialize the path search process (ant colony), calculate the state transition rules, and define the state transition rules as shown in formula (3);

[0168] Step S506: Update the pheromone τ(a,b) according to the instantaneous flow velocity, and cyclically update the pheromone parameters. The specific method for updating the pheromone is as follows: calculate the pheromone concentration based on the path distance μ and the fair sharing rate R(t) of the link, and continuously update the pheromone τ. The pheromone update rules are shown in formulas (9)-(10).

[0169] Step S507: If the currently accessed node does not exist in the set of accessed nodes, then perform the following steps;

[0170] Step S508: Add the currently visited node I to the set of visited nodes;

[0171] Step S509: Update pheromone parameters and other information based on the time window and load conditions. Obtain the file fragment size (size) (assuming all file fragment sizes are the same), and the time window w, where w is a time range [e i ,l i ], e i Indicates the earliest arrival time, l i This represents the latest arrival time (stay time is negligible). The path distance function μ for optimizing the pheromone transfer matrix is ​​then adjusted as follows: As shown in formula (1);

[0172] Step S510: For each ant colony process k (k∈[1,n]), perform the following processing;

[0173] Step S511: Update the pheromone τ(a,b) based on the instantaneous flow velocity, and cyclically update the pheromone parameters. The specific method for updating the pheromone is as follows: calculate the pheromone concentration based on the path distance μ and the fair sharing rate R(t) of the link, and continuously update the pheromone τ.

[0174] Step S512: Update the dynamic routing table. Execute the optimized path selection function to select the optimal path. The operation is as follows: Select the best path s based on the pheromone concentration, as shown in formula (4);

[0175] Step S513: Complete the routing table update and begin multi-party data transmission.

[0176] In one alternative embodiment, Figure 6 This is a flowchart of an optional hot financial product transaction data processing method according to an embodiment of this application, such as... Figure 6 As shown, for example, if a customer of Bank A branch participates in a product promotion event organized by a wealth management product issuer, the specific steps are as follows:

[0177] Step S601: The wealth management product issuing institution configures the trading parameters for hot financial products on its application server, including: the start and end times of the financial product trading activities, the total inventory quota of the financial products, the financial product quota allocated to each branch, the eligibility parameters for financial product participants, the maximum number of connections, and the timeout period, etc., and synchronizes them to the application servers of all other branches through the communication server. Branch A customers complete real-name user registration on their trading terminals, the customer trading terminals are initialized, and the keys are downloaded to the customer terminals.

[0178] Step S602: After the activity begins, the customer submits a financial product transaction request on their trading terminal. The transaction request is submitted to the application server of Branch A. This application server is configured with high concurrency parameters, including the use of a token bucket algorithm to limit access traffic. This filters the transaction requests for various popular financial products, retaining only valid requests that meet the preset conditions. Each transaction request is matched one-to-one with the inventory quotas in the inventory control module, generating a corresponding order qualification certificate for the customer. The branch application server uploads the qualified transaction request data to the communication server. The application server categorizes and packages transaction requests for the same target product. The request packet includes the client's source IP, the URL of the request interface, and user information. The data packet is then sent to the communication server of Branch A.

[0179] Step S603: After the communication server of Branch A receives the authentication request transaction request, the routing management module on the server is initialized. The routing management module executes the GenKey() function (an algorithm or program function for generating key pairs (public key and private key)). For each data transmission node i (i∈[1,n]), the public key pk(i) and private key sk(i) of data transmission node i are generated in a loop. For all nodes i (i∈[1,n]), if i is not the target node, the following flow rate control protocol calculation steps are executed: the fair sharing rate of each link is calculated as shown in formula (2), the path search process is initialized, and the state transition rule is added as shown in formula (3). The routing management module updates the pheromone τ(a,b) according to the instantaneous flow rate and updates the pheromone parameters in a loop. The specific method for updating pheromones is as follows: based on the path distance μ and the fair sharing rate R(t) of the link, calculate the pheromone "concentration" and continuously update the pheromone τ. The pheromone update rules are as shown in formulas (9)-(10). If the currently accessed communication server node does not exist in the accessed node library, the routing management module adds the currently accessed node to the accessed node library. Update pheromone and other information based on time sharding and load conditions. Obtain the file shard size size (assuming the file shard sizes are the same), time window w, and set w as a time range [e i ,l i ],e i Indicates the earliest arrival time, l i This represents the latest arrival time (stay time is negligible). The path distance function μ for optimizing the pheromone transfer matrix is ​​then adjusted as follows: Formally represented as formula (1);

[0180] Step S604: The routing management module updates the dynamic routing table and executes the optimized path selection function to select the optimal path and transmit the data packet to the next communication node server. The operation is as follows: Based on the "concentration" of pheromones, the optimal path s is selected, as shown in formula (4);

[0181] Step S605: After receiving the communication packet, the next communication server continues to calculate the fair sharing rate of each link based on the address of the communication destination node server in the communication packet, executes the optimized path selection function, selects the optimal path, and transmits the data packet to the next communication server. The communication servers along the way repeatedly execute this step until the data packet is transmitted to the communication server of the product issuing organization.

[0182] Step S606: The product issuing institution's communication server sends the transaction data packet to the product issuing institution's application server. The product issuing institution's application server receives the transaction request data and processes the transaction based on the transaction quantity and amount in the request data. After successful communication, it processes the crediting to the branch's corporate account and returns the transaction result to the product issuing institution's communication server.

[0183] Step S607: Each communication server of the bank uses the same data processing method to transmit the transaction result data packet to the application server of Branch A. The application server of Branch A updates the customer's personal account according to the transaction result and returns the transaction result to the customer's transaction terminal. The transaction ends.

[0184] This application also provides a transaction data processing apparatus for financial products. It should be noted that the transaction data processing apparatus for financial products in this application can be used to execute the transaction data processing method for financial products provided in this application. The transaction data processing apparatus for financial products provided in this application will be described below.

[0185] According to an embodiment of this application, a transaction data processing apparatus for implementing the above-described financial products is also provided. Figure 7 This is a schematic diagram of a transaction data processing apparatus for an optional financial product according to an embodiment of this application, as shown below. Figure 7 As shown, the device includes: a receiving unit 701, an uploading unit 702, a determining unit 703, and a sending unit 704.

[0186] Optionally, the receiving unit 701 is used to receive transaction parameters sent by the issuing institution of the target financial product through the first server of the sales institution of the target financial product, wherein the transaction parameters are used to characterize the restrictions on purchasing the target financial product, and the target financial product is a financial product that is specified to be sold within a preset time period; the uploading unit 702 is used to obtain a transaction request that meets the transaction parameters uploaded by the user terminal device through the first server; the determining unit 703 is used to determine a target transmission path from multiple data transmission paths between the first server and the second server through the first server based on the shared traffic rate of the data link between the first server and the second server; and the sending unit 704 is used to send the transaction request to the second server through the first server based on the target transmission path.

[0187] Optionally, the transaction parameters include at least one of the following parameters: a first parameter for limiting the transaction time of the target financial product; a second parameter for limiting the total quantity of the target financial product; a third parameter for limiting the maximum number of target financial products that each sales institution can sell; a fourth parameter for limiting the target financial product's target customer group; and a fifth parameter for limiting the maximum number of communication connections between the first server and the second server.

[0188] Optionally, the transaction data processing device for financial products further includes: a distribution unit, used to distribute transaction parameters and traffic restriction conditions to the application server of the sales institution through the first server, wherein the traffic restriction conditions are used to limit the access traffic between the application server and the user terminal device through the token bucket algorithm, the application server is an intermediate server between the user terminal device and the first server, and the application server is used to filter transaction requests based on the transaction parameters and traffic restriction conditions.

[0189] Optionally, the financial product transaction data processing device further includes: an acquisition unit, used to acquire a request information packet from the application server of the sales institution through a first server, wherein the request information packet includes at least the following information: multiple transaction requests that meet the transaction parameters; the network identifier of the user terminal device that initiates each transaction request; and the user information of the user who initiates each transaction request.

[0190] Optionally, the determining unit 703 includes: a first determining subunit, a first updating subunit, and a second determining subunit. The first determining subunit is used to determine the ant colony based on target rules, wherein the ant colony represents the search process for data transmission paths, and the target rules are used to dynamically update the selection of data transmission paths based on pheromones and path distances. The first updating subunit is used to update the pheromones based on the shared traffic rate at the target time and the path lengths already traversed by the ant colony. The second determining subunit is used to determine the target transmission path from multiple data transmission paths between the first server and the second server based on the updated pheromones.

[0191] Optionally, the transaction data processing device for financial products further includes: a first detection unit, a second detection unit, a third detection unit, a fourth detection unit, and a first determination unit. The first detection unit is used to detect the capacity of the data link, where capacity represents the maximum transmission rate of the data link; the second detection unit is used to detect the average utilization rate of transaction requests entering the data link, where average utilization rate represents the ratio of total bandwidth to capacity when transaction requests enter the data link; the third detection unit is used to detect the average round-trip time of transaction requests traversing the data link; the fourth detection unit is used to detect the average queue size of the data link at the target time, where the average queue size represents the amount of data waiting to be sent in the data link; and the first determination unit is used to determine the shared traffic rate of the data link at the target time based on the capacity, average utilization rate, average round-trip time, and average queue size.

[0192] Optionally, the second determining subunit includes: a first detection module, a first determining module, a second detection module, a third detection module, a second determining module, and a third determining module. The first detection module is used to detect the data size of the transaction request; the first determining module is used to determine the time range within which the transaction request arrives at the second server; the second detection module is used to detect load parameters, where the load parameters characterize the load on the data link when the ant colony passes through the first server at the target time; the third detection module is used to detect time parameters, where the time parameters characterize the degree of matching between the time and time range of the transaction request arriving at the second server according to the path selected by the ant colony when it passes through the first server at the target time; the second determining module is used to determine a path distance function based on the data size of the transaction request, the time range within which the transaction request arrives at the second server, the load parameters, and the time parameters; the third determining module is used to determine the target transmission path from multiple data transmission paths between the first server and the second server based on the path distance function and the updated pheromone.

[0193] According to another aspect of this application, a computer-readable storage medium is also provided, which includes a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the above-described financial product transaction data processing method.

[0194] According to another aspect of this application, an electronic device is also provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the aforementioned method for processing transaction data of financial products during runtime.

[0195] According to another aspect of this application, a computer program product is also provided, including computer instructions, which, when executed by a processor, implement the steps of the transaction data processing method for the financial product described above.

[0196] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0197] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0198] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0199] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0200] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0201] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0202] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for processing transaction data of a financial product, characterized in that, include: The transaction parameters are received from the second server of the issuing institution of the target financial product through the first server of the sales institution of the target financial product. The transaction parameters are used to characterize the restrictions on purchasing the target financial product, and the target financial product is a financial product that is designated to be sold within a preset time period. The transaction request that meets the transaction parameters is obtained by the user terminal device uploaded by the first server. Based on the shared traffic rate of the data link between the first server and the second server, the target transmission path is determined from multiple data transmission paths between the first server and the second server using the first server. Based on the target transmission path, the transaction request is sent from the first server to the second server; Specifically, the method involves determining a target transmission path from multiple data transmission paths between the first server and the second server based on the shared traffic rate of the data link between the first server and the second server, using the first server as the primary server. This includes: determining an ant colony based on target rules, where the ant colony represents the search process for data transmission paths, and the target rules are used to dynamically update the selection of the data transmission path based on pheromones and path distance; updating the pheromones based on the shared traffic rate at the target time and the path lengths already traversed by the ant colony; and determining the target transmission path from multiple data transmission paths between the first server and the second server based on the updated pheromones. Before updating the pheromone based on the shared traffic rate at the target time and the path length already traversed by the ant colony, the capacity of the data link is detected, wherein the capacity represents the maximum transmission rate of the data link; the average utilization of the transaction requests entering the data link is detected, wherein the average utilization represents the ratio of the total bandwidth when the transaction requests enter the data link to the capacity; the average round-trip time of the transaction requests traversing the data link is detected; the average queue size of the data link at the target time is detected, wherein the average queue size represents the amount of data waiting to be sent in the data link; and the shared traffic rate of the data link at the target time is determined based on the capacity, the average utilization, the average round-trip time, and the average queue size. Among them, shared traffic rate The calculation formula is: t represents the current time, T represents the time interval for flow rate updates, C represents the capacity, y(t) represents the average utilization rate of traffic entering the data link, d represents the average round-trip time of traffic traversing the data link, and q(t) represents the average queue size. and Represents the weight parameters. and The values ​​are used to determine the relative importance of average utilization and queue size when calculating a new shared traffic rate.

2. The method for processing transaction data of financial products according to claim 1, characterized in that, The transaction parameters include at least one of the following parameters: The first parameter is used to limit the trading time of the target financial product; The second parameter is used to limit the total number of the target financial products; The third parameter is used to limit the maximum number of the target financial product that each of the sales institutions can sell. The fourth parameter is used to limit the target group of people who can purchase the financial product. The fifth parameter is used to limit the maximum number of communication connections between the first server and the second server.

3. The method for processing transaction data of financial products according to claim 1, characterized in that, Before obtaining a transaction request that meets the transaction parameters uploaded by the user terminal device through the first server, the method further includes: The first server sends the transaction parameters and traffic restrictions to the application server of the sales organization. The traffic restrictions are used to limit the access traffic between the application server and the user terminal device through a token bucket algorithm. The application server is an intermediate server between the user terminal device and the first server. The application server is used to filter the transaction requests based on the transaction parameters and the traffic restrictions.

4. The method for processing transaction data of financial products according to claim 3, characterized in that, After sending the transaction parameters and traffic restrictions to the application server of the sales organization via the first server, the method further includes: The request information packet is obtained from the application server of the sales organization through the first server, wherein the request information packet includes at least the following information: Multiple transaction requests that satisfy the transaction parameters; The network identifier of the user terminal device that initiated each of the transaction requests; User information of the user who initiated each transaction request.

5. The method for processing transaction data of financial products according to claim 1, characterized in that, Based on the updated pheromone, a target transmission path is determined from multiple data transmission paths between the first server and the second server, including: Detect the data size of the transaction request; Determine the time range within which the transaction request arrives at the second server; Detect load parameters, wherein the load parameters characterize the load of the data link when the ant colony passes through the first server at the target time; The detection time parameter represents the degree of matching between the time when the transaction request arrives at the second server according to the path selected by the ant colony when the ant colony passes through the first server at the target time and the time range. The path distance function is determined based on the data size of the transaction request, the time range in which the transaction request arrives at the second server, the load parameters, and the time parameters. Based on the path distance function and the updated pheromone, a target transmission path is determined from multiple data transmission paths between the first server and the second server.

6. A transaction data processing apparatus for a financial product, used to implement the transaction data processing method for the financial product according to any one of claims 1 to 5, characterized in that, include: The receiving unit receives transaction parameters sent by the second server of the issuing institution of the target financial product through the first server of the sales institution of the target financial product. The transaction parameters are used to characterize the restrictions on purchasing the target financial product, and the target financial product is a financial product that is designated to be sold within a preset time period. The upload unit obtains a transaction request that meets the transaction parameters uploaded by the user terminal device through the first server; The determining unit determines the target transmission path from multiple data transmission paths between the first server and the second server based on the shared traffic rate of the data link between the first server and the second server, through the first server. The sending unit, based on the target transmission path, sends the transaction request to the second server through the first server.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device containing the computer-readable storage medium to perform the transaction data processing method for the financial product according to any one of claims 1 to 5.

8. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein, when the program is running, the processor executes the transaction data processing method for the financial product according to any one of claims 1 to 5.

9. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the transaction data processing method for the financial product according to any one of claims 1 to 5.

Images