A method and related device for assisting in bond trading quotation

Abstract

The application provides a bond transaction inquiry assisting method and related equipment, by acquiring inquiry text in a bond transaction inquiry process, and converting the inquiry text in natural language form into structured transaction elements by using a recognition model, the transaction information in the form of natural language text in the inquiry stage can be directly read and understood, and the technical limitation that the existing compliance checking system can only identify structured order information is broken. On this basis, by acquiring compliance related data, the structured transaction elements are subjected to compliance checking, compliance verification of the proposed transaction is realized in the inquiry process, and the effective time point of the compliance checking is advanced. When the proposed transaction does not conform to the preset compliance rules, compliance warning information is sent to the terminal in time, so that the trader knows the potential compliance risk before formally reaching a transaction intention with the counterparty, thereby avoiding invalid early communication due to compliance problems at the source, and significantly reducing invalid communication and time cost.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and related equipment for assisting in bond trading price inquiry. Background Technology

[0002] Interbank bond transactions typically involve traders using instant messaging platforms to conduct real-time price inquiries with counterparties. Both parties communicate regarding key transaction elements such as the underlying bond, transaction direction, quantity, and price. During the transaction process, traders also need to assess compliance requirements for the proposed transaction, taking into account factors such as portfolio concentration, intraday reverse transactions, counterparty credit lines, and due diligence on reverse repurchase counterparties.

[0003] Existing bond trading compliance check systems are typically set up after a transaction is concluded but before the formal order placement, during the transaction entry stage. After traders and counterparties complete price inquiries and form a trading intention, they enter structured transaction information such as bond code, trading direction, quantity, price, and counterparty into the trading system. The system then uses this information to access relevant data such as holdings, transaction records, credit lines, and due diligence, and performs corresponding verifications according to preset compliance rules, outputting compliance check results. However, existing compliance check systems require the structured order information entered into the trading system as the basis for compliance verification, while the transaction elements in the price inquiry stage mainly exist in the form of natural language text in instant messaging messages. Therefore, the system cannot directly perform corresponding compliance checks based on the price inquiry message before the trading intention is sent out; verification can only be performed after the transaction information is entered into the trading system. When compliance issues are discovered at this point, traders and counterparties have often already engaged in lengthy price inquiry communication, rendering the initial communication ineffective and increasing ineffective communication and time costs. Summary of the Invention

[0004] In view of the shortcomings of the prior art, this application provides a bond trading inquiry assistance method and related equipment to solve the problem that the failure of preliminary communication to form an effective transaction increases in ineffective communication and time costs.

[0005] To achieve the above objectives, this application provides the following technical solution:

[0006] The first aspect of this application provides a method for assisting in bond trading price inquiries, including:

[0007] Obtain the inquiry text during the bond trading inquiry process;

[0008] The inquiry text is input into the recognition model to obtain the structured transaction elements corresponding to the inquiry text;

[0009] Obtain compliance-related data corresponding to the structured transaction elements; the compliance-related data includes at least position data, transaction record data, and counterparty data;

[0010] Based on the aforementioned compliance-related data, a compliance check is performed on the structured transaction elements to obtain the compliance check results;

[0011] If the compliance check result indicates that the proposed transaction corresponding to the structured transaction element does not comply with the preset compliance rules, then a compliance warning message corresponding to the proposed transaction is generated based on the compliance check result; the preset compliance rules are the compliance rules corresponding to the compliance-related data.

[0012] The compliance warning information is sent to the terminal corresponding to the inquiry text, and a confirmation result for the compliance warning information is obtained;

[0013] Based on the confirmation result, an inquiry message corresponding to the inquiry text is generated.

[0014] Optionally, the step of inputting the inquiry text into the recognition model to obtain the structured transaction elements corresponding to the inquiry text includes:

[0015] The inquiry text is input into the recognition model, where the inquiry text is encoded into characters to obtain text representation data.

[0016] Based on the text representation data, local feature extraction and bidirectional temporal feature extraction are performed in parallel to obtain local features and temporal features;

[0017] The local features are aligned by time steps, and the aligned local features are concatenated with the temporal features to obtain the concatenated features;

[0018] The spliced ​​features are then subjected to feature mapping to obtain sequence decoding features;

[0019] Based on the sequence decoding features, the emission score of each candidate tag corresponding to the position of each character in the query text is determined, and the transition score between adjacent candidate tags is obtained;

[0020] Based on the launch score and the transfer score, calculate the sequence score corresponding to each candidate tag sequence, and determine the candidate tag sequence with the highest sequence score as the tag sequence;

[0021] The tag sequence is aggregated to obtain the structured transaction elements corresponding to the inquiry text.

[0022] Optionally, the compliance check on the structured transaction elements based on the compliance-related data to obtain the compliance check result includes:

[0023] Based on the bond identifier in the structured transaction elements, the holding information corresponding to the bond identifier is determined from the holding data, and the holding information is compared with a preset holding ratio threshold to obtain a first comparison result;

[0024] Target transaction records corresponding to the bond identifier within a preset time range are selected from the transaction record data, and the transaction direction in the structured transaction elements is compared with the transaction direction corresponding to the target transaction records to obtain a second comparison result;

[0025] Credit information is determined from counterparty data, and the comparison result of the credit limit corresponding to the proposed transaction is determined based on the number of transactions in the structured transaction elements and the credit information.

[0026] Due diligence information is determined from the counterparty data, and the due diligence information is matched with preset counterparty admission criteria to obtain a matching result;

[0027] Based on the first comparison result, the second comparison result, the credit limit comparison result, and the matching result, a compliance check result is generated.

[0028] Optionally, generating compliance warning information corresponding to the proposed transaction based on the compliance check results includes:

[0029] Filter out target inspection results that do not conform to the preset compliance rules from the compliance inspection results;

[0030] Determine the target preset compliance rule corresponding to the target inspection result and the target inspection data that triggers the target preset compliance rule;

[0031] Based on the target's preset compliance rules and the target's inspection data, a compliance warning information corresponding to the proposed transaction is generated.

[0032] Optionally, generating the inquiry message corresponding to the inquiry text based on the confirmation result includes:

[0033] If the confirmation result indicates that the proposed transaction should continue, then obtain the dialogue context information corresponding to the inquiry text;

[0034] The structured transaction elements and the dialogue context information are input into the large language model to obtain the inquiry message.

[0035] Optional, also includes:

[0036] Obtain the counterparty information corresponding to the inquiry message;

[0037] Based on the counterparty information, determine the instant messaging session corresponding to the inquiry message;

[0038] Send the inquiry message to the instant messaging session;

[0039] Once the inquiry message is sent, the conversation status of the instant messaging session will be updated to "waiting for reply".

[0040] Optional, also includes:

[0041] If the message type corresponding to the inquiry text is an external inquiry type, then the bond type corresponding to the inquiry text is determined based on the structured transaction elements;

[0042] Based on the bond type, the target trader responsible for the bond type is determined from the preset trader assignment data;

[0043] Based on the structured trading elements, obtain the corresponding bond market data and trading indicator data;

[0044] A structured inquiry summary is generated based on the structured transaction elements, the bond market data, and the transaction indicator data;

[0045] The structured query summary is sent to the terminal corresponding to the target trader, and the intention confirmation result for the structured query summary is obtained;

[0046] The instant messaging session corresponding to the inquiry text is processed based on the intention confirmation result.

[0047] A second aspect of this application provides a bond trading inquiry auxiliary device, comprising:

[0048] The first acquisition unit is used to acquire the inquiry text during the bond transaction inquiry process;

[0049] The input unit is used to input the inquiry text into the recognition model to obtain the structured transaction elements corresponding to the inquiry text;

[0050] The second acquisition unit is used to acquire compliance-related data corresponding to the structured transaction elements; the compliance-related data includes at least position data, transaction record data, and counterparty data;

[0051] The inspection unit is used to perform compliance checks on the structured transaction elements based on the compliance-related data, and obtain compliance check results;

[0052] The first generation unit is configured to generate compliance warning information corresponding to the proposed transaction based on the compliance inspection result if the compliance inspection result indicates that the proposed transaction corresponding to the structured transaction element does not comply with the preset compliance rules; the preset compliance rules are the compliance rules corresponding to the compliance-related data.

[0053] The sending unit is used to send the compliance warning information to the terminal corresponding to the inquiry text, and to obtain the confirmation result for the compliance warning information;

[0054] The second generation unit is used to generate an inquiry message corresponding to the inquiry text based on the confirmation result.

[0055] A third aspect of this application provides a computer-readable storage medium comprising a stored program, wherein the program, when executed by a processor, performs the bond trading inquiry assistance method provided in the first aspect of this application.

[0056] A fourth aspect of this application provides an electronic device, comprising: a processor, a memory, and a bus; wherein the processor and the memory are connected via the bus;

[0057] The memory is used to store a program, and the processor is used to run the program, wherein the program is executed by the processor to perform the bond trading inquiry assistance method provided in the first aspect of this application.

[0058] This application provides a bond trading inquiry assistance method and related equipment. By acquiring the inquiry text during the bond trading inquiry process and using a recognition model to convert the natural language inquiry text into structured transaction elements, it can directly read and understand transaction information existing in natural language text form during the inquiry stage, breaking the technical limitation of existing compliance inspection systems that can only recognize structured order information. Based on this, by acquiring compliance-related data, compliance checks are performed on the structured transaction elements, enabling compliance verification of the proposed transaction during the inquiry process, thus advancing the effective timing of compliance checks. When the proposed transaction does not comply with preset compliance rules, a compliance warning is promptly sent to the terminal, allowing traders to be aware of potential compliance risks before formally reaching a transaction agreement with the counterparty. This avoids ineffective early communication due to compliance issues at the source, significantly reducing ineffective communication and time costs. Attached Figure Description

[0059] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0060] Figure 1 A flowchart illustrating a bond trading inquiry assistance method provided in this application embodiment;

[0061] Figure 2A schematic diagram of the architecture of a bond trading inquiry auxiliary device provided in this application embodiment;

[0062] Figure 3 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0063] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0064] In this application, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0065] like Figure 1 The flowchart shown is a method for assisting in bond trading price inquiry according to an embodiment of this application, which specifically includes the following steps:

[0066] S101: Obtain the inquiry text during the bond transaction inquiry process.

[0067] Specifically, the front-end interaction module can retrieve the quote text exchanged between traders and their counterparties during real-time communication. The quote text can include quote messages entered by the trader or transaction communication information sent by the counterparty.

[0068] The inquiry text can be in natural language, and its content may include bond identification, trading direction, trading quantity, price information, and other trading communications. Because traders typically use colloquial language in bond trading, the inquiry text may contain abbreviations, industry jargon, and non-standard expressions.

[0069] For example, the instant messaging platform could be the one used in the interbank bond market. The front-end interaction module could be a lightweight component embedded in the instant messaging client (such as a desktop client or a WebView built into a mobile application) as a plug-in, which is only responsible for message pass-through and status prompts, and does not perform business logic processing.

[0070] Optionally, after obtaining the inquiry text from the bond transaction inquiry process, the process also includes preprocessing the inquiry text. Preprocessing includes identifying message types and cleaning the text. Message types include inquiries initiated by the party itself, inquiries initiated by the party itself, external inquiries, and casual conversations or system notifications. For example, message types can be identified through keyword matching; keywords such as "help me inquire," "ask," "receive," and "issue" are used to identify inquiries; keywords such as "have interest," "can," and "no problem" are used to identify inquiries. Text cleaning includes removing emoticons, mention marks, and redundant whitespace, and segmenting long sentences using periods, question marks, exclamation marks, or line breaks.

[0071] S102: Input the inquiry text into the recognition model to obtain the structured transaction elements corresponding to the inquiry text.

[0072] Specifically, the recognition model is used to perform semantic recognition and entity extraction on inquiry texts, converting natural language inquiry texts into structured transaction elements.

[0073] Optionally, in another embodiment of this application, the specific implementation of step S102 includes processes A1 to A7.

[0074] A1: Input the inquiry text into the recognition model. In the recognition model, the inquiry text is encoded into characters to obtain the text representation data.

[0075] The recognition model includes a character embedding layer. First, the input natural language sentence is segmented into sequences [s1, s2, ..., s...] based on its characters. n ], where n is the sentence length. Then, each character s is retrieved by looking up a table. i Mapped to the corresponding word vector e i =E[s i ]∈ ¹² 8 The word vectors are obtained through pre-training on a large-scale financial corpus.

[0076] For example, the input natural language sentence is "Help me inquire about sample bonds worth 50 million at around 3.50". The preprocessing steps include: converting full-width numbers and English letters to half-width characters (e.g., converting "3.50" to "3.50"); converting traditional Chinese characters to simplified Chinese characters (if applicable); and segmenting the sentence into a sequence with a length of 20 characters after segmentation.

[0077] For example, the Word2Vec (Skip-gram) algorithm can be run on hundreds of thousands of bond trading chat records for domain-adaptive pre-training to obtain the word embedding matrix E∈ ^{V×d}, where d is the embedding dimension (e.g., 128), and V is the character set size (approximately 8000 commonly used Chinese characters in the financial field). For the input sentence S, the embedding matrix X = [e1;e2;...;e...] is obtained. n ]∈ ^{n×128}.

[0078] Optionally, a Dropout layer can be included after the word embedding layer. During training, the Dropout layer randomly sets the dimensions of some word vectors to zero with a preset probability (e.g., 50%) to prevent the model from overfitting to specific entity representations in the training set. Simultaneously, this mechanism enables the model to learn to infer entity boundaries and types using contextual information, rather than relying solely on single-character pattern matching. It should be noted that during the inference phase, the Dropout layer does not perform any random zeroing operation; that is, all word vector dimensions remain intact and participate in the forward computation.

[0079] A2: Based on text representation data, local feature extraction and bidirectional temporal feature extraction are performed in parallel to obtain local features and temporal features.

[0080] Local feature extraction is implemented using a Convolutional Neural Network (CNN) branch to capture short-range N-gram patterns in the text.

[0081] Specifically, multiple one-dimensional convolutional kernels of various sizes (e.g., kernel_size=2, 3, 4, 5) are applied in parallel to convolve the embedding matrix X. Multiple kernels of each size are used (e.g., 64), and each kernel slides with a stride of 1 and outputs a feature map. Global max pooling is applied to each feature map to obtain a fixed-length feature vector. The feature vectors output by convolutional kernels of different sizes are concatenated to obtain the local feature h_CNN∈ ² 56 .

[0082] Bidirectional temporal feature extraction is implemented using a branch of a bidirectional long short-term memory (Bi-LSTM) network to model long-distance contextual dependencies.

[0083] Specifically, the bidirectional Long Short-Term Memory (LSTM) network comprises a forward LSTM network and a backward LSTM network, scanning sentences in the forward and backward directions respectively, with each layer containing 128 hidden units (hidden_size). At time step t, the output of the forward LSTM network is h_forward_t = LSTM_forward(e_t, h_forward_{t-1}), and the output of the backward LSTM network is h_backward_t = LSTM_backward(e_t, h_backward_{t+1}). Concatenating these two outputs yields the bidirectional LSTM network output h_BiLSTM_t = [h_forward_t; h_backward_t] ∈ [0, 1, 2, 3]. ² 56 The output matrix of the bidirectional long short-term memory network for the entire sentence is H_BiLSTM=[h_BiLSTM_1;…;h_BiLSTM_n]∈ ^{n×256} represents the time sequence feature.

[0084] A3: Align local features with time steps, and then concatenate the aligned local features with the temporal features to obtain concatenated features.

[0085] Since the output of the convolutional neural network branch is a global feature vector h_CNN, it needs to be copied n times to align to each time step. The copied local features are then concatenated with the time-step sequential features output by the bidirectional long short-term memory network along the feature dimension to obtain the concatenated feature H_fusion∈ ^{n×(256+256)}= ^{n×512}.

[0086] A4: Perform feature mapping on the spliced ​​features to obtain sequence decoding features.

[0087] Specifically, the concatenated feature H_fusion is input into a fully connected layer for dimensionality reduction and feature mapping, with tanh as the activation function and an output dimension of 128. This yields the final sequence decoding feature H_final∈ ^{n×128}.

[0088] A5: Based on sequence decoding features, determine the emission score of each candidate tag corresponding to the position of each character in the inquiry text, and obtain the transition score between adjacent candidate tags.

[0089] The decoding layer uses a Conditional Random Field (CRF). The tagging system adopts the BIO annotation scheme, including tag types such as B-BOND (bond entity start), I-BOND (bond entity internal), B-DIRECTION (trading direction start), B-AMOUNT (trading quantity start), I-AMOUNT, B-YIELD (yield start), I-YIELD, and O (non-entity).

[0090] The Conditional Random Field (CRF) layer contains an emission matrix and a transition matrix. The emission score is obtained by mapping the 128-dimensional feature vector of the sequence decoding feature H_final at each time step to a score vector representing the number of labels using a fully connected layer. The transition score is obtained through the transition matrix T∈ ^{L×L} is determined, where L is the number of labels, and T[i][j] represents the score for transitioning from label i to label j (e.g., T[B-BOND][I-BOND]=+5.0 indicates that transitions from "bond entity start → bond entity interior" are encouraged; T[B-BOND][B-PRICE]=-10.0 indicates that transitions from "bond entity start → price entity start" are severely penalized). T is learned automatically during training.

[0091] A6: Calculate the sequence score corresponding to each candidate tag sequence based on the launch score and transfer score, and determine the candidate tag sequence with the highest sequence score as the tag sequence.

[0092] Specifically, for the input sentence, the score of all possible label sequences is calculated. The score is the sum of the emission score at each position on the path and the transition score of adjacent labels. The Viterbi dynamic programming algorithm is used to find the globally optimal label sequence with the highest score in polynomial time complexity. Its loss function is the negative log-likelihood, which is the proportion of the score of the correct label sequence to the sum of the scores of all possible sequences (the partition function is efficiently calculated through a forward-backward algorithm).

[0093] A7: Aggregate the tag sequence to obtain the structured transaction elements corresponding to the inquiry text.

[0094] Exemplarily, if the label sequence is "帮 / O我 / O询 / O一 / O下 / O21 / B-BOND国 / I-BOND开 / I-BOND05 / I-BOND, / O收 / B-DIRECTION5000 / B-AMOUNT万 / I-AMOUNT, / O3.50 / B-YIELD左 / I-YIELD右 / I-YIELD", the aggregated structured transaction element JSON (JavaScript Object Notation) is: {"bond_code":"210205","bond_name":"example bond","direction":"BUY","amount":50000000,"target_yield":3.50}, as well as the corresponding confidence score.

[0095] Optionally, after obtaining the structured transaction elements, the method further includes a dialog state updating step and a parsing result distributing step. Specifically, the dialog state of the current dialog session is updated to a compliance checking state, the state is stored in a Redis cache, and a timeout period (30 minutes) is set, after which the state automatically rolls back to an idle state. The parsed structured transaction elements are written into the parsed structured transaction element topic of the Kafka message middleware in a JSON format, with the dialog session identifier as the message key, so as to ensure that messages of the same dialog are written in order.

[0096] Optionally, the training data of the recognition model is pre-annotated bond transaction chat sentences. In the training process, an Adam optimizer is adopted, and an early stopping strategy and regularization means (such as Dropout, L2 regularization, gradient clipping) are applied. The character embedding layer is obtained by performing domain adaptive pre-training by running a Word2Vec algorithm on a large-scale bond transaction chat corpus. The annotation consistency is double-checked, and the consistency coefficient reaches 0.91. In the training process, the batch size is set to 32, the number of training epochs is 50, and the early stopping strategy is that the training is stopped when the F1-score of the verification set does not increase for 5 consecutive training epochs. After the model training is completed, the model can be exported into an Open Neural Network Exchange (ONNX) format, and ONNX Runtime is used to perform inference acceleration on a Graphics Processing Unit (GPU). An A / B test strategy is adopted for model version management, the new version of the model is gradually switched to full volume when the core indicators (F1-score, inference latency) are not inferior to those of the old version of the model, and all model version files are stored in an internal object storage, supporting one-click rollback.

[0097] S103: Obtain compliance related data corresponding to the structured transaction elements.

[0098] The compliance-related data includes at least the following: holdings data, transaction records data, and counterparty data. Holdings data includes the current holdings of each fund product managed by the entity in specific bonds or issuers, and the percentage of these holdings relative to the fund's net asset value. Transaction records data includes all trader inquiries and transactions within a preset time frame (e.g., the current day). Counterparty data includes counterparty credit line information, blacklist / whitelist status, latest credit rating, and due diligence findings.

[0099] Specifically, based on information such as bond codes and counterparty identifiers in structured transaction elements, compliant related data is obtained by querying multi-source heterogeneous data storage systems.

[0100] For example, you can query position data and credit limit data from a MySQL relational database; query historical transaction records from MongoDB or ElasticSearch; and query real-time aggregated credit limit usage from a Redis cache.

[0101] In one optional embodiment of this application, the unified authentication subsystem implements a unified authentication and authorization entry point for all microservice APIs based on an API gateway, and provides functions for collecting, storing, and querying end-to-end operation audit logs. Specifically, the unified authentication subsystem includes an authentication module, a permission module, and an audit module.

[0102] The authentication module implements stateless authentication based on JWT tokens. After a user logs in through the enterprise unified identity authentication system, the authentication module issues a JWT token. The token payload contains the user identifier, role, permission list, and expiration time, and the signing key is stored in the key management service of the API gateway. Each microservice can complete authentication by verifying the token using public key verification, without needing to access the authentication module, thus achieving stateless horizontal scaling.

[0103] The permissions module employs a role-based access control model. Roles are defined in the permissions table of the relational database, with each role associated with a set of permission enumeration values. For example, the inquiry sending function is only granted to users with the "trader" role and whose user identifier is in the trading department's whitelist. Adding a user to the whitelist requires two levels of approval (the head of the trading department and the head of the risk control department). The approval process is streamlined through the office automation system, and the whitelist table in the relational database is automatically updated after approval.

[0104] The auditing module collects all metadata for each API request (including request time, source IP, request path, HTTP method, user ID, request body size, response status code, and response latency) through the API gateway's global log plugin, and asynchronously writes it in batches to Elasticsearch, supporting retrieval and visualization by any combination of fields. Critical operations (such as user login and logout, permission changes, and inquiry submissions) are additionally recorded in detailed operation information to a MongoDB audit log collection.

[0105] Optionally, an authorization verification step can be included before performing compliance checks. The authorization verification interface of the unified authentication subsystem is called to confirm whether the current trader is authorized to send price inquiries. If not authorized, an error is returned directly, and subsequent checks are not performed; if authorized, the compliance check process continues.

[0106] S104: Conduct compliance checks on structured transaction elements based on compliance-related data to obtain compliance check results.

[0107] Specifically, compliance checks refer to the process of comparing and verifying the proposed transaction information in structured transaction elements with compliance-related data obtained from a multi-source data storage system.

[0108] Optionally, in another embodiment of this application, the specific implementation of step S104 includes processes B1 to B5.

[0109] B1: Based on the bond identifier in the structured transaction elements, determine the holding information corresponding to the bond identifier from the holding data, and compare the holding information with the preset holding ratio threshold to obtain the first comparison result.

[0110] The first comparison result includes the concentration check result for a single bond and the concentration check result for the same issuer. In practice, the current market value of the bond corresponding to the bond identifier is retrieved from the holdings data as a percentage of the fund's net asset value, as well as the total market value of all outstanding bonds held by the same bond issuer as a percentage of the fund's net asset value. These are then compared with preset thresholds for the single bond holding ratio (e.g., 10%) and the single issuer holding ratio (e.g., 10%) to determine whether a concentration warning has been triggered or is close to being triggered.

[0111] B2: Filter out the target transaction records corresponding to the bond identifier within a preset time range from the transaction record data, and compare the transaction direction in the structured transaction elements with the transaction direction corresponding to the target transaction record to obtain the second comparison result.

[0112] The preset time range can be the current day (T+0) or include the previous trading day (T+1), and the time window is configurable. The second comparison result is used to detect the existence of reverse transaction risk. Specifically, if a transaction record with the same bond identifier as the structured transaction element but in the opposite direction is found in the historical records of the current trader or other traders, a corresponding warning message is generated.

[0113] For example, if the transaction direction in the structured transaction element is buy, but there are sell inquiries or transaction records for the same bond in the transaction record data, a reverse transaction warning will be triggered.

[0114] B3: Determine credit information from counterparty data and determine the corresponding credit limit comparison results for the proposed transaction based on the transaction volume and credit information in the structured transaction elements.

[0115] The credit information includes the counterparty's total credit limit, used credit limit, and remaining available credit limit. The credit limit comparison result is generated by comparing the number of transactions in this proposed transaction with the counterparty's remaining available credit limit.

[0116] It should be noted that the used credit limit is a cross-trader aggregated value, that is, it aggregates the transaction amounts of all traders who have entered into but not yet settled with this counterparty. For example, the counterparty's current used credit limit can be maintained and read in real time from the Redis cache through atomic operations (such as INCRBY), and the amount of the proposed transaction can be compared with the remaining available credit limit (total credit limit minus used credit limit).

[0117] B4: Determine due diligence information from the counterparty's data and match the due diligence information with the preset counterparty admission criteria to obtain the matching results.

[0118] The due diligence information includes whether the counterparty is on the counterparty whitelist, its latest credit rating, and whether there is any negative public opinion surrounding it. Preset counterparty eligibility criteria include, but are not limited to: being on the whitelist, having a credit rating no lower than a preset level, and having completed due diligence for the reverse repurchase agreement. The matching result is either "pass" or "fail".

[0119] B5: Generate compliance check results based on the first comparison result, the second comparison result, the quota comparison result, and the matching result.

[0120] The compliance check results can include individual check results for each rule dimension (e.g., pass, warning, fail) and a comprehensive overall compliance rating. For example, the overall compliance rating could be Level 1 (all passed), Level 2 (close to the threshold or non-substantial risk exists), or Level 3 (clear violation of compliance rules). The compliance check results are organized in a structured data format (e.g., JSON).

[0121] It should be noted that the generation order of the first comparison result, the second comparison result, the credit limit comparison result, and the matching result is not important. Each inspection dimension is independent and can be executed simultaneously using parallel computation to improve the overall efficiency of compliance checks. For example, in the rule engine, each compliance rule is treated as an independent rule unit. The working memory of the rule engine simultaneously activates parallel rule evaluation threads. The evaluation results of each rule are written into their respective result variables, and finally, they are aggregated into a unified compliance check result. With parallel execution, the total time for multi-dimensional compliance checks is approximately equal to the longest-running dimension among all inspection dimensions, rather than the sum of the times for each dimension, thus significantly reducing overall processing latency.

[0122] Optionally, the overall compliance level in the compliance check results is determined according to the following rules: if all rule dimensions have a "pass" check result, the overall compliance level is Level 1; if any rule dimension has a "warning" check result and there are no "fail" check results, the overall compliance level is Level 2; if any rule dimension has a "fail" check result, the overall compliance level is Level 3. It should be noted that a "warning" means that although the check result does not exceed the preset prohibition threshold, it is close to that threshold (e.g., concentration reaches more than 80% of the threshold) or there is a risk warning that traders need to pay attention to (e.g., there is reverse trading but it has not yet constituted a substantial violation); a "fail" means that the check result has clearly exceeded the preset prohibition threshold or does not meet the mandatory access conditions.

[0123] S105: If the compliance check results indicate that the proposed transaction corresponding to the structured transaction element does not comply with the preset compliance rules, then a compliance warning message corresponding to the proposed transaction will be generated based on the compliance check results.

[0124] The proposed transaction refers to the trading intentions that traders plan to reach based on this inquiry and communication.

[0125] Optionally, in another embodiment of this application, the specific implementation of generating compliance warning information corresponding to the proposed transaction based on the compliance check results in step S105 includes processes C1 to C3.

[0126] C1: Filter out target inspection results that do not conform to preset compliance rules from the compliance inspection results.

[0127] Among them, the target inspection result refers to the inspection result of a single rule dimension in the compliance inspection results, where the inspection status is warning or failure.

[0128] Specifically, the method for filtering target inspection results from compliance inspection results is as follows: iterate through the inspection results of each rule dimension in the compliance inspection results, and determine whether its status field is equal to warning or failure. If the condition is met, the inspection result is included in the target inspection result set.

[0129] For example, if the compliance check results include five dimensions of check results, where the concentration check result for the same issuer is a warning, the reverse transaction check result is a failure, the single bond concentration check result is a success, the counterparty quota check result is a success, and the counterparty due diligence check result is a success, then the target check result set only includes the check results for the two dimensions of the same issuer concentration and reverse transactions.

[0130] C2: Determine the target preset compliance rules corresponding to the target inspection results and the target inspection data that triggers the target preset compliance rules.

[0131] Among them, the target preset compliance rule refers to the compliance rule definition corresponding to the target inspection result. The target inspection data refers to the specific data value or data status that triggers the target preset compliance rule.

[0132] Specifically, the method for determining the target's preset compliance rules is as follows: From the rule definition table of the rule engine, query the corresponding rule name, rule description, rule threshold, and rule type based on the rule identifier (e.g., rule_id). The method for determining the target's inspection data is as follows: Extract data field values ​​directly related to the target's preset compliance rules from the compliance-related data.

[0133] For example, if the target's pre-set compliance rule is a concentration rule for the same issuer, which defines that the total market value of all outstanding bonds held by the same issuer shall not exceed 10% of the fund's net asset value, then the corresponding target inspection data is the ratio of the total market value of all outstanding bonds held by the issuer to the fund's net asset value. If this ratio is 14.5%, then the target inspection data is 14.5%. As another example, if the target's pre-set compliance rule is a prohibition on reverse transactions, which defines that the same trader shall not conduct opposite inquiries or transactions on the same bond on the same day, then the corresponding target inspection data includes the trader's identifier (the current trader), bond code (same as the bond to be traded), transaction direction (opposite to the intended transaction direction), inquiry time (within the same day), and transaction status (intention reached or transaction completed).

[0134] C3: Generate compliance warning information corresponding to the proposed transaction based on the target's preset compliance rules and target inspection data.

[0135] The compliance warning information is organized in a structured data format and includes at least the following fields: warning level (corresponding to the overall compliance level, i.e., the first level does not trigger a warning, while the second and third levels do), warning rule list (containing the names of all compliance rules that trigger warnings), warning details list (each compliance rule that triggers a warning corresponds to one warning detail, and each warning detail includes a specific risk description, the numerical or status information that triggered the warning, and suggested follow-up actions), warning generation timestamp, and warning unique identifier.

[0136] After compliance warning information is generated, in addition to being sent to the trader's terminal, it can also be sent simultaneously to the monitoring terminal of risk control and compliance personnel, so that risk control personnel can keep abreast of the dynamics of transaction risks in real time.

[0137] S106: Send compliance warning information to the terminal corresponding to the inquiry text and obtain confirmation results for the compliance warning information.

[0138] The terminal corresponding to the inquiry text can be the instant messaging client used by the trader who sends or receives the inquiry text. Compliance warning information is displayed to traders through front-end plugins in the form of pop-ups, inline warning cards, or system notifications.

[0139] The confirmation result is used to instruct traders, after reviewing the compliance warning, whether to confirm the submission (i.e., continue to execute the proposed transaction) or cancel the submission (i.e., suspend the current inquiry).

[0140] It is important to emphasize that even if the compliance warning indicates the highest risk level, it is only a warning and a reminder; the final decision to send it always rests with the trader. The trader can choose to continue executing the proposed transaction based on their own assessment of the exemption scenario.

[0141] Specifically, when compliance warning information is sent to the terminal, different visual display formats are used depending on the warning level: For level two, a yellow warning card is used to display the warning content, including a list of warning rules, specific risk data, and two operation buttons: confirm send and cancel send. For level three, a red warning card is used to display the warning content, highlighting the name of the violation rule and the violation data, and additionally displaying a risk warning (such as "This operation may constitute a compliance violation; please confirm with caution"). The confirm send button on the card requires secondary confirmation from the trader (e.g., clicking "I understand the risk, confirm send" again) to take effect. For example, secondary confirmation can be achieved by popping up a secondary confirmation dialog box after the initial click of "confirm send," requiring the trader to read the complete risk description, check the "I fully understand the above risks" checkbox, and click confirm again to complete the sending operation.

[0142] Optionally, when a trader chooses to cancel sending, the confirmation result will further perform the following operations: record the audit log of this cancellation operation (including trader ID, timestamp, bond code, transaction direction, transaction quantity, triggered compliance rules, and specific values), update the instant messaging session's chat status to canceled, and optionally automatically generate a backup message to the counterparty (e.g., "Sorry, internally confirming, will reply later"), which the trader confirms and then sends to avoid affecting interbank cooperation due to prolonged non-reply. If the trader chooses to confirm sending, the audit log of this confirmation operation will be recorded, and the subsequent inquiry message generation and sending process will continue.

[0143] Optionally, after a compliance alert is sent to the terminal, if the trader does not confirm it within a preset time (e.g., 5 minutes), the following actions will be taken: the instant messaging session's chat status will be updated to a timeout waiting state; a reminder notification will be sent to the trader (e.g., "You have a pending compliance alert, please confirm it promptly"); if no confirmation is received again after the preset time (e.g., after another 3 minutes), the system will automatically revert the chat status to an idle state and record the unprocessed audit log. The aforementioned timeout period can be dynamically adjusted through the configuration center to accommodate different traders' operating habits.

[0144] S107: Generate an inquiry message corresponding to the inquiry text based on the confirmation result.

[0145] Specifically, an inquiry message refers to a natural language-based inquiry text generated based on the trader's confirmation and structured transaction elements, intended for transmission to the counterparty. The inquiry message is generated by automatically generating an inquiry statement conforming to natural language expression habits using a large language model, based on information such as bond code, transaction direction, transaction quantity, and target price from the structured transaction elements, combined with historical message records of the current dialogue session and the historical interaction habits between the trader and the counterparty.

[0146] Optionally, in another embodiment of this application, step S107 is specifically implemented by including the following process:

[0147] D1: If the confirmation result indicates that the proposed transaction should continue, then obtain the dialogue context information corresponding to the inquiry text.

[0148] The dialogue context information includes the historical message records of the current dialogue session (with the session identifier as the key), the dialogue status, and the historical interaction habits between the trader and the counterparty.

[0149] D2: Input the structured transaction elements and dialogue context information into the large language model to obtain the inquiry message.

[0150] Among them, the large language model is a pre-trained language model with 7B parameters deployed locally and privately. It is fully deployed on the GPU server of the internal business network (each machine is equipped with a GPU, and multiple cards can perform cross-card inference through tensor parallelism). The model weight file is completely physically isolated from the external network to ensure that transaction dialogue data does not leave the network.

[0151] The inquiry message is a text formatted in natural language and sent to the counterparty. Specifically, the large language model can generate initial inquiry text based on predefined templates and structured transaction elements, and then refine it for conversational language. For example, if the input structured transaction elements are {bond_code:“210205”,direction:“BUY”,amount:50000000,target_yield:3.50}, and the dialogue context is the historical dialogue record with the counterparty, then the generated inquiry message could be: “Hello, for example bonds, I'd like to purchase 50 million at around 3.50, is that possible?”

[0152] For example, when initiating a quote request to the counterparty after passing compliance checks, the message template could be: "Hello Mr. / Ms. {counterparty_name}, {bond_short_name}, can you do it for around {amount} ten thousand, {yield}?" If the counterparty is not interested, the message template could be: "Okay, thank you Mr. / Ms. {counterparty_name}, let's cooperate again when we have the opportunity." After filling in the specific values ​​in the structured transaction elements, the message is polished by a large language model to generate the final quote or response message sent to the counterparty.

[0153] Optionally, the large language model adopts a solution of "local private deployment + lightweight fine-tuning + retrieval-enhanced generation + three-layer security barrier". Specifically, low-rank adaptation (LoRA) is used for lightweight domain fine-tuning, configured with a rank of 8 and a scaling factor of 16. Only a portion of the projection matrix of the attention layer is fine-tuned, and the trainable parameters account for only about 0.1% of the base model parameters. Fine-tuning on a single GPU takes approximately 2 hours. The plug-and-play nature of low-rank adaptation allows for rapid fine-tuning and hot-switching of low-rank adaptation weights in response to domain knowledge updates (such as adding compliance rules).

[0154] The Retrieval-Augmented Generation (RAG) framework's workflow includes: encoding the user's question into a query vector via an embedded model; retrieving the most relevant knowledge fragments (e.g., Top-K, K=5) from the vector index of the local knowledge base; concatenating the retrieved knowledge fragments with the user's question to form a pre-defined prompt word template; and inputting the concatenated prompt words into a large language model to generate an answer. Retrieval-Augmented Generation decouples the parameterized knowledge of the large model from externally retrieved knowledge, effectively suppressing model illusions. Three layers of security checks are implemented on the output side of the large language model: a sensitive word filter scans the output content for sensitive words based on a multi-pattern matching algorithm, blocking the output if a match is found; compliance checks the output for specific investment advice based on rules, blocking the output if a match is found; and output format checks the generated inquiry or response message for necessary transaction elements (e.g., bond code, direction, quantity), using a template as a fallback if missing. Only after all three checks pass is the output sent to the front-end plugin.

[0155] Optionally, after step S107, in order to facilitate continued state management of the corresponding instant messaging session after the inquiry message is sent, a state update method is provided in another embodiment of this application, including processes E1 to E4.

[0156] E1: Obtain the counterparty information corresponding to the inquiry message.

[0157] The counterparty information refers to the relevant identification data of the recipient of the inquiry message, i.e., the counterparty in the transaction, which includes at least the counterparty's unique user identifier on the instant messaging platform, the name and code of the institution to which the counterparty belongs. The counterparty information can be obtained from the context information of the conversation.

[0158] For example, in an instant messaging session, each message header contains a sender identifier and a receiver identifier. By reading the receiver field of the current conversation, the counterparty information can be determined. If the current conversation is an inquiry initiated by a trader, the counterparty information is the user information corresponding to the chat object selected by the trader when initiating the inquiry; if the current conversation is an external inquiry, the counterparty information is the user information corresponding to the sender of the inquiry text.

[0159] E2: Determine the instant messaging session corresponding to the inquiry message based on the counterparty information.

[0160] E3: Send the inquiry message to the instant messaging session.

[0161] The specific method for sending the inquiry message to the instant messaging session is as follows: through the message uplink module of the front-end plugin, the open message sending interface provided by the instant messaging platform is called to send the inquiry message in text message format to the specified session.

[0162] For example, the open message sending interface can use the POST method of the HTTP / HTTPS protocol, with the request body in JSON format, including fields such as the recipient's session identifier, message content, and message type. After calling the sending interface, the front-end plugin receives the sending status code returned by the interface. If the status code indicates successful sending, the message uplink is complete; if the status code indicates sending failure, a retry mechanism is triggered, retrying sending according to an exponential backoff strategy until successful sending or the maximum number of retries is exceeded. During message sending, the message uplink module also ensures the idempotency of message sending through message deduplication and idempotency modules, preventing the same query message from being sent repeatedly due to network retransmissions.

[0163] E4: After the inquiry message is sent, the chat status of the instant messaging session will be updated to "Waiting for reply".

[0164] The conversation state is stored in the Redis cache and has a timeout period (30 minutes). After the timeout, the state will automatically revert to the idle state.

[0165] Optionally, after the inquiry message is sent to the instant messaging session, the process further includes: listening for the counterparty's reply message in the instant messaging session; upon receiving the counterparty's reply message, parsing the reply message using a recognition model to obtain the structured reply elements corresponding to the reply message; comparing the structured reply elements with the structured transaction elements corresponding to the aforementioned inquiry message to determine whether the bond code, transaction direction, transaction quantity, and price in the counterparty's reply are consistent with the content of this party's inquiry; if they are consistent, updating the dialogue status to a pending confirmation status and pushing a transaction element confirmation card to the trader's terminal; if they are inconsistent (e.g., the counterparty has modified the quantity or price), updating the dialogue status to a pending negotiation status and pushing a difference prompt to the trader's terminal, allowing the trader to decide whether to accept the counterparty's modified conditions or continue negotiation.

[0166] In one optional embodiment of this application, the system network is physically divided into an external interaction area and an internal service area:

[0167] The external interaction zone (Demilitarized Zone, DMZ) deploys only a front-end proxy gateway (two servers in primary / backup mode, with virtual IP (VIP) migration). It connects to the instant messaging platform's message interface via a dedicated line. Hardware firewalls are installed at both ends of the dedicated line, opening only specific ports required for message exchange, while all other ports are closed. The external interaction zone does not store any business data; the gateway only performs secure transport layer protocol termination and request reverse proxying.

[0168] The internal business area deploys all core services, including microservice application clusters, AI model servers, and various database clusters. The internal business area is completely physically isolated from the external network—there is no Network Address Translation (NAT) traversal, no Virtual Private Network (VPN) access, and no wireless network connection. All operational and maintenance tasks are performed through the bastion host's physical console or out-of-band management port. The only communication path between the external interaction area and the internal business area is as follows: the external interaction area's proxy gateway forwards requests to the internal business area's API gateway (through a specific IP + port whitelist rule in the internal firewall). The API gateway enforces token verification for all requests; requests without a valid token are rejected at the gateway layer and never reach any internal microservices.

[0169] In terms of security defense, a multi-layered, in-depth defense system is adopted:

[0170] Network layer security: leased line isolation, regional firewall, IP whitelist, TLS 1.2 and above encrypted transmission.

[0171] Application layer security: unified API gateway entry point, JWT token stateless authentication, role-based access control (RBAC) with fine-grained permission control (roles include traders, risk control specialists, and administrators), API rate limiting, and circuit breaker degradation.

[0172] Data layer security: The database only listens to the internal business network IP, adheres to the principle of least privilege for database accounts (each microservice has an independent database account, and only the minimum necessary privileges are granted), enables TLS 1.2 for database connections, encrypts sensitive fields, encrypts backup files, and automatically de-identifies logs.

[0173] Operational audit security: full API request logs, detailed audit logs of key operations (JSON format including snapshots before and after the operation), audit log retention period meets financial regulatory requirements, and logs are tamper-proof (once written, they cannot be modified or deleted, only appending and querying are supported).

[0174] In one optional embodiment of this application, each data storage engine performs regular data backups: MongoDB performs a full backup (automatically executed daily at 1 AM), compresses the backup file, stores it on network-attached storage, retains approximately two copies, and automatically cleans up backups older than 30 days; MySQL performs a full backup (automatically executed daily at 2 AM), retains approximately two copies on network-attached storage, and automatically cleans up backups older than 30 days, while simultaneously enabling real-time binary log backups, with log files synchronized to a dedicated log backup server in real time; Redis achieves data persistence through append-only file (AOF) log persistence and RDB (Redis Database) snapshot backups; StarRocks performs daily incremental backups based on the snapshot mechanism of the underlying distributed file system; application logs are automatically archived and compressed at the end of each day, packaged and stored in network-attached storage by monthly directory, and automatically deleted after 12 months. Furthermore, a disaster recovery drill is performed quarterly, fully restoring the database from backup files to an independent disaster recovery drill environment to verify the integrity of the backup files and the feasibility of the recovery process.

[0175] Optionally, in actual bond trading inquiry processes, besides traders actively initiating inquiries to counterparties, there are also cases where counterparties actively send inquiry texts to traders. Therefore, another embodiment of this application provides an auxiliary method for bond trading inquiry of the external inquiry type, including processes F1 to F6.

[0176] F1: If the message type corresponding to the inquiry text is an external inquiry type, then the bond type corresponding to the inquiry text is determined based on the structured transaction elements.

[0177] External inquiries refer to inquiries whose text is not actively entered by the trader but sent by the counterparty's trader to the trader or the system's instant messaging session. Bond types can include interest rate bonds, credit bonds, interbank certificates of deposit, etc. The corresponding bond type can be obtained by querying a pre-set bond information database and identifying the bond code.

[0178] F2: Based on the bond type, determine the target trader responsible for the bond type from the preset trader assignment data.

[0179] The data on trader roles is pre-stored in a database, recording the types of bonds each trader is responsible for. By querying this data, external inquiries can be automatically routed to the specific trader responsible for that type of bond.

[0180] F3: Obtain corresponding bond market data and trading indicator data based on structured trading elements.

[0181] The bond market data should include at least the following fields: bond code, bond abbreviation, current best market buy price, current best market sell price, latest transaction price, latest transaction time, opening price of the day, highest price of the day, lowest price of the day, and corresponding yield curve data. The trading indicator data should include at least the following fields: the current number of bonds held by the investor, the market value of the holdings, the percentage of the holdings to the fund's net asset value, the available trading quota for the bond type, the current valuation price of the bond, and the source of the valuation.

[0182] For example, bond market data is obtained by the market data engine through a real-time market data interface and returned in structured JSON format; trading indicator data is calculated in real-time by the indicator calculation engine from the holdings database and quota management system based on the bond code and fund product code in the structured trading elements and then returned. By correlating and comparing the above market data and indicator data with the trading direction and target price in the structured trading elements, traders can quickly determine whether the counterparty's quote is within a reasonable market range and whether they have the capacity to undertake the transaction.

[0183] F4: Generates a structured query summary based on structured transaction elements, bond market data, and transaction indicator data.

[0184] The structured inquiry summary is a formatted information card containing the aforementioned multi-dimensional information, facilitating quick decision-making by traders. Its content may include: counterparty name, bond abbreviation, transaction direction, transaction quantity, target price, current market conditions, and the trader's trading capabilities. For example: External Inquiry | Counterparty Name | Sample Bond (Interest Rate Bond) | Offer 30 million | Target Rate 3.48% | Current Best Market Bid Price = 3.47% / Ask Price = 3.50% | Available Quota = Sufficient.

[0185] F5: Send the structured query summary to the terminal corresponding to the target trader and obtain the intention confirmation result for the structured query summary.

[0186] For example, a structured query summary is pushed to the target trader's instant messaging client in the form of a card. The trader can use this to quickly determine whether they have a trading intention for the external query and click the "intention" or "no intention" button to confirm.

[0187] F6: Process the instant messaging session corresponding to the inquiry text based on the intention confirmation result.

[0188] Specifically, if the confirmation result indicates that there is interest, the instant messaging session will be marked as ready for manual processing, allowing the target trader to directly negotiate with the counterparty on the instant messaging platform; if the confirmation result indicates that there is no interest, a response message will be automatically generated and sent to the corresponding session through the front-end plugin.

[0189] It's important to note that in external inquiry scenarios, compliance-related data also needs to be acquired and used for compliance checks. Unlike proactive inquiry scenarios, compliance check results in external inquiry scenarios are not a prerequisite for generating inquiry messages (because the inquiry text has already been sent by the counterparty), but rather serve as a reference for traders to determine whether to express trading intentions regarding this external inquiry. In specific implementation, the structured inquiry summary generated in step F4 includes not only bond market data and trading indicator data, but also relevant early warning information from the compliance check results (such as concentration warnings, quota warnings, etc.), so that traders can consider compliance factors when expressing their intentions. The compliance early warning information in the structured inquiry summary adopts the same hierarchical display method as in proactive inquiry scenarios, enabling traders to quickly identify potential compliance risks.

[0190] In one optional embodiment of this application, the bond trading inquiry assistance method is deployed in a strictly layered six-layer architecture. From bottom to top, it includes: infrastructure layer, data storage layer, service middleware layer, application service layer, gateway layer, and front-end presentation layer.

[0191] The infrastructure layer is deployed on the server cluster of the internal business network, providing basic support capabilities such as computing resources, operating environment, version management, continuous integration and continuous deployment, monitoring and alarm, and distributed coordination for the upper-layer components.

[0192] Specifically, the operating system uses Linux, and all nodes are integrated into an enterprise-level virtualization management platform to form a hyperconverged resource pool, enabling unified management and elastic scheduling of computing, storage, and network resources.

[0193] In terms of code management and building, source code version management tools are used for source code version management, dependency management tools are used for project dependency management, and a continuous integration and continuous deployment pipeline is built to achieve full-process automation from code submission to automatic building and automatic deployment to the test environment.

[0194] In terms of the operating environment, a containerized operating solution is adopted, with each microservice encapsulated as an independent container and uniformly orchestrated and managed through container orchestration tools to ensure consistency between the development, testing, and production environments.

[0195] In terms of monitoring and alarms, indicator collection tools are used to collect system operation indicators, and a visual dashboard is used to display the indicators. An alarm push mechanism is also configured to promptly push alarm information when the system is abnormal.

[0196] In terms of distributed coordination, a distributed coordination service cluster is adopted to provide service registration, service discovery and distributed configuration management functions, ensuring the collaborative operation of service nodes under the microservice architecture.

[0197] The data storage layer employs a multi-source heterogeneous storage architecture integrating five engines to match the optimal storage engine for data loads with different characteristics. Specifically:

[0198] Engine ①, Redis Cluster: Employs Sentinel mode for automatic failover, storing session tokens (valid for 2 hours), real-time compliance calculation results cache (valid for 30 seconds to avoid duplicate calculations), real-time aggregated values ​​of counterparty credit limits, and price thresholds for price alerts (using an ordered set structure). Data persistence uses a combination of AOF logs (synchronized once per second) and RDB snapshots.

[0199] Engine ②, MongoDB Cluster: Employing a replica set architecture (3 nodes), it stores complete documents of original instant messaging chat logs (including message body, sender identifier, receiver identifier, timestamp, and message type), parsing results from the recognition model, training corpus for the artificial intelligence model, and system operation audit logs. It leverages MongoDB's schema-less nature to adapt to flexible changes in business fields.

[0200] Engine ③, MySQL Master-Slave Cluster: Employs semi-synchronous replication (2 nodes; if the master node fails, the slave node is automatically promoted to master, with a recovery time target of less than 60 seconds). The master node handles write operations, and the slave nodes handle read operations. It stores core structured data requiring atomicity, consistency, isolation, and durability (ACID) transaction guarantees, including transaction record tables, position information tables, user and permission tables, compliance rule configuration tables, counterparty information tables, and credit limit tables. When a single table contains more than ten million rows, query performance is optimized through date-based partitioning and indexing.

[0201] Engine 4, StarRocks Cluster: Employs columnar storage and a vectorized execution engine (3 nodes, one master and two slaves, with high availability and automatic failover) to store massive amounts of historical market data (millions of new records added daily). It supports second-level online analysis and processing queries, including transaction deviation analysis (the difference between the transaction price and the market average price), counterparty behavior profiling (price activity and preferred trading instruments over the past 30 days) and aggregation of regulatory reporting data. Typical queries with millions of data points have a response time of less than 2 seconds.

[0202] Engine ⑤, Kafka Message Middleware: As the asynchronous message hub across subsystems (3 broker nodes, 3 topic partitions, 2 replication factors), it defines multiple core topics for the asynchronous transmission of raw chat messages, parsed structured transaction elements, real-time market data, and compliance alert messages. Kafka's persistence (messages are written to disk) and partition ordering (messages with the same conversation identifier are routed to the same partition) ensure reliable message delivery and ordering.

[0203] Optionally, the data storage layer also includes an ElasticSearch cluster (3 nodes) for building full-text indexes on chat logs and audit logs in MongoDB, supporting quick retrieval of historical conversations by keywords (bond code, counterparty name, date range).

[0204] In one optional embodiment of this application, the service middleware layer includes six core processing engines, each deployed independently as a microservice:

[0205] (a) Quotation Parsing Engine: Exposes an Application Programming Interface (API) to receive raw chat text (JSON format, including text content, session identifier, sender, timestamp, etc.), calls the recognition model to extract structured transaction elements (average processing latency less than 200 milliseconds, P99 less than 500 milliseconds), and manages the state machine of multi-round quotation dialogues. Dialogue states include idle state, parsing state, compliance check state, waiting for reply state, and reply received state. The states are stored in Redis and have a timeout period (30 minutes, automatically returning to the idle state after timeout).

[0206] (b) Risk and Compliance Engine: Exposes an API to receive structured transaction elements and trader identifiers, performs multi-dimensional compliance checks based on the rule engine, and returns the compliance check results. The rules of the rule engine are stored in the compliance rule configuration table of the relational database in rule language format, and support dynamic hot loading through the configuration center.

[0207] (c) Market Data Engine: The market data engine specifically includes a market data access module, a market data cleaning and standardization module, and a price alert module. The market data access module receives real-time binary market data streams via a TCP Socket long connection and decodes them into an internal standard format according to a preset message format (fixed-length header plus variable-length message body). The market data cleaning and standardization module performs deduplication, outlier filtering, and field standardization on the decoded market data. The deduplication rule is: for duplicate quotes from the same quoting party for the same bond within a preset time window, only the latest one is retained. The outlier filtering rule is: quotes with yields exceeding the preset basis point range of the previous day's closing price are marked as outliers and manually reviewed before being stored. Field standardization includes unifying the bond code format, unifying the yield calculation method to annualized, and unifying the quote type enumeration value. The price alert module allows traders to set target prices or target yields for bonds they are interested in through a front-end plugin, for example, "Alert me when the yield of the example bond is below 3.50%." These settings are stored in Redis as an ordered set, with the key being the alert identifier and the score being the target yield or target price. Each time the market data engine receives new market data, it checks if there is a matching price alert condition in Redis. If a match is found, an alert message is sent to a specific topic in the Kafka message broker.

[0208] (d) Indicator Calculation Engine: Provides real-time query APIs for business indicators such as position concentration, trading deviation, and counterparty quota utilization. The indicator calculation engine adopts a dual-mode strategy of scheduled full calculation and event-driven incremental updates. For daily frequency indicators (such as position concentration), a full calculation is performed from the relational database before the market opens each day and written to the cache. For real-time indicators (such as the current quota occupied by the counterparty), an incremental update is triggered after each query and parsing of the structured trading element topic by subscribing to the Kafka message middleware, and the summary value is maintained in real time through atomic operations of the cache. Through the indicator query API interface, it prioritizes reading from the cache. If the cache is not hit, it returns to the relational database or columnar database for real-time calculation, and sets a short-term temporary cache to prevent cache breakdown.

[0209] (e) Artificial Intelligence Question Answering Engine: Deploy a large language model and combine it with a retrieval-enhanced generation framework to provide intelligent question answering services in the field of bond trading.

[0210] (f) Scheduling and monitoring engine: manages scheduled tasks (data backup, daily report generation, market snapshot) and collects all microservice operation metrics (queries per second, QPS, latency, error rate, JVM / Central Processing Unit (CPU) / memory) for visual monitoring and alerting.

[0211] In one optional embodiment of this application, the gateway layer adopts a two-layer API gateway architecture:

[0212] The outer gateway is used for Transport Layer Security (TLS) 1.2 and above termination, static resource (frontend plugin HTML / JS / CSS files) caching, IP whitelist filtering (allowing only IP ranges from the instant messaging platform's dedicated line and internal business network), and request logging. The inner API gateway is used for unified identity authentication (verifying JWT (JSON Web Token) tokens), API routing and forwarding (routing to the corresponding microservice based on the URL path prefix), traffic control (rate limiting based on user and API dimensions, default 100 times / minute / user), circuit breaking and degradation (circuit breaking is triggered after 5 consecutive failures, and the system attempts again after 30 seconds), and blacklists and whitelists (supporting access control at both IP and user levels).

[0213] The front-end presentation layer is an embedded plugin for the instant messaging platform, developed using HTML5, CSS3, and front-end frameworks. The plugin interacts with the backend via a request-response API (HTTP / 1.1, JSON format) and receives market data and compliance alert pop-ups proactively pushed by the server via the WebSocket protocol (WSS: / / , heartbeat mechanism with PING / PONG every 30 seconds, automatic reconnection after disconnection using an exponential backoff strategy, maximum interval 30 seconds). The plugin includes a message listening module, a message uplink module, and a message deduplication and idempotency module. The message listening module listens for new messages in all sessions in real time through the instant messaging platform's open API, generates a globally unique message identifier (Universally Unique Identifier, UUID) v4, and writes it to the Kafka message middleware. Specifically, after capturing a message, the message listening module generates a globally unique message identifier, encapsulates the message into a JSON message body, and writes it asynchronously and non-blockingly to the original chat message subject in the Kafka message middleware. Upon successful writing, the front-end plugin displays a temporary status message indicating that the system is processing the message in the instant messaging client's chat window. It should be noted that the front-end plugin is only responsible for message pass-through and status prompts, and does not perform business logic processing, in order to ensure the lightweight nature and security of the front-end plugin.

[0214] The message uplink module subscribes to the reply message topics and compliance warning message topics generated by the backend, and sends messages and displays warnings respectively. The message deduplication and idempotency module prevents message duplication by maintaining a cache of processed message identifiers (the most recent 1000 messages, Least Recently Used (LRU) strategy) and a cache-based idempotent lock (valid for 5 minutes).

[0215] In summary, this application, by acquiring the inquiry text during the bond transaction inquiry process and using a recognition model to convert the natural language inquiry text into structured transaction elements, enables the system to directly read and understand transaction information existing in natural language text form during the inquiry stage. This overcomes the technical limitation of existing compliance inspection systems that can only recognize structured order information. Based on this, by acquiring compliance-related data such as position data, transaction record data, and counterparty data, compliance checks are performed on the structured transaction elements. This achieves compliance verification of the proposed transaction during the inquiry process, shifting the effective timing of compliance checks from the traditional "after the transaction is concluded, before the order is placed" to "during the inquiry process, before the intention is sent." When the compliance check results indicate that the proposed transaction does not comply with preset compliance rules, a compliance warning is promptly generated and sent to the terminal, allowing traders to be aware of potential compliance risks before formally reaching a transaction intention with the counterparty. This avoids ineffective early communication due to compliance issues at the source, significantly reducing ineffective communication and time costs.

[0216] like Figure 2 The diagram shown is an architectural schematic of a bond trading inquiry auxiliary device provided in this application embodiment. The auxiliary device includes: a first acquisition unit 100, an input unit 200, a second acquisition unit 300, an inspection unit 400, a first generation unit 500, a sending unit 600, and a second generation unit 700.

[0217] The first acquisition unit 100 is used to acquire the inquiry text during the bond transaction inquiry process.

[0218] Input unit 200 is used to input the inquiry text into the recognition model to obtain the structured transaction elements corresponding to the inquiry text.

[0219] The input unit 200 is specifically used for: inputting the inquiry text into the recognition model; in the recognition model, encoding the inquiry text into characters to obtain text representation data; based on the text representation data, performing local feature extraction and bidirectional temporal feature extraction in parallel to obtain local features and temporal features; aligning the local features by time steps and concatenating the aligned local features with the temporal features to obtain concatenated features; performing feature mapping on the concatenated features to obtain sequence decoding features; determining the emission score of each candidate label corresponding to each character position in the inquiry text based on the sequence decoding features, and obtaining the transition score between adjacent candidate labels; calculating the sequence score corresponding to each candidate label sequence based on the emission score and transition score, and determining the candidate label sequence with the highest sequence score as the label sequence; and performing aggregation processing on the label sequences to obtain the structured transaction elements corresponding to the inquiry text.

[0220] The second acquisition unit 300 is used to acquire compliance-related data corresponding to the structured transaction elements; the compliance-related data includes at least position data, transaction record data and counterparty data.

[0221] Inspection unit 400 is used to perform compliance checks on structured transaction elements based on compliance-related data and obtain compliance check results.

[0222] The inspection unit 400 is specifically used for: determining the holding information corresponding to the bond identifier from the holding data based on the bond identifier in the structured transaction elements, and comparing the holding information with a preset holding ratio threshold to obtain a first comparison result; filtering the target transaction records corresponding to the bond identifier within a preset time range from the transaction record data, and comparing the transaction direction in the structured transaction elements with the transaction direction corresponding to the target transaction records to obtain a second comparison result; determining the credit information from the counterparty data, and determining the amount comparison result corresponding to the proposed transaction based on the transaction quantity and credit information in the structured transaction elements; determining the due diligence information from the counterparty data, and matching the due diligence information with preset counterparty access conditions to obtain a matching result; and generating a compliance inspection result based on the first comparison result, the second comparison result, the amount comparison result, and the matching result.

[0223] The first generation unit 500 is used to generate compliance warning information corresponding to the proposed transaction based on the compliance inspection results if the compliance inspection results indicate that the proposed transaction corresponding to the structured transaction element does not comply with the preset compliance rules; the preset compliance rules are the compliance rules corresponding to the compliance-related data.

[0224] The first generation unit 500 includes:

[0225] The filtering sub-unit is used to filter out target inspection results that do not conform to preset compliance rules from the compliance inspection results.

[0226] The sub-unit is used to determine the target preset compliance rules corresponding to the target inspection results and the target inspection data that triggers the target preset compliance rules.

[0227] The generation sub-unit is used to generate compliance warning information corresponding to the proposed transaction based on the target's preset compliance rules and target inspection data.

[0228] The sending unit 600 is used to send compliance warning information to the terminal corresponding to the inquiry text and obtain the confirmation result for the compliance warning information.

[0229] The second generation unit 700 is used to generate an inquiry message corresponding to the inquiry text based on the confirmation result.

[0230] The second generation unit 700 is specifically used for: if the confirmation result indicates that the proposed transaction should continue, obtaining the dialogue context information corresponding to the inquiry text; inputting the structured transaction elements and dialogue context information into the large language model to obtain the inquiry message.

[0231] In summary, this application, by acquiring the inquiry text during the bond transaction inquiry process and using a recognition model to convert the natural language inquiry text into structured transaction elements, enables the system to directly read and understand transaction information existing in natural language text form during the inquiry stage. This overcomes the technical limitation of existing compliance inspection systems that can only recognize structured order information. Based on this, by acquiring compliance-related data such as position data, transaction record data, and counterparty data, compliance checks are performed on the structured transaction elements. This achieves compliance verification of the proposed transaction during the inquiry process, shifting the effective timing of compliance checks from the traditional "after the transaction is concluded, before the order is placed" to "during the inquiry process, before the intention is sent." When the compliance check results indicate that the proposed transaction does not comply with preset compliance rules, a compliance warning is promptly generated and sent to the terminal, allowing traders to be aware of potential compliance risks before formally reaching a transaction intention with the counterparty. This avoids ineffective early communication due to compliance issues at the source, significantly reducing ineffective communication and time costs.

[0232] Combination Figure 2 The auxiliary device, as shown, also includes:

[0233] The third acquisition unit is used to acquire the counterparty information corresponding to the inquiry message.

[0234] The determination unit is used to determine the instant messaging session corresponding to the inquiry message based on the counterparty information.

[0235] The information sending unit is used to send inquiry messages to the instant messaging session.

[0236] The update unit is used to update the conversation status of the instant messaging session to a waiting-for-response status after the inquiry message is sent.

[0237] Combination Figure 2 The auxiliary device, as shown, also includes:

[0238] The type determination unit is used to determine the bond type corresponding to the inquiry text based on the structured transaction elements if the message type corresponding to the inquiry text is an external inquiry type.

[0239] The trader identification unit is used to identify the target trader responsible for a specific bond type from a pre-defined trader assignment data based on the bond type.

[0240] The fourth acquisition unit is used to acquire corresponding bond market data and trading indicator data based on structured transaction elements.

[0241] The summary generation unit is used to generate structured inquiry summaries based on structured transaction elements, bond market data, and transaction indicator data.

[0242] The summary sending unit is used to send the structured inquiry summary to the terminal corresponding to the target trader and obtain the intention confirmation result for the structured inquiry summary.

[0243] The processing unit is used to process the instant messaging session corresponding to the inquiry text based on the intention confirmation result.

[0244] Another embodiment of this application provides an electronic device, such as... Figure 3 As shown, it includes: memory 301, processor 302 and bus 303.

[0245] The memory 301 is used to store the program.

[0246] The processor 302 is used to execute a program, which, when executed, is specifically used to implement a bond trading inquiry assistance method as provided in any of the above embodiments.

[0247] The electronic devices mentioned in this article can be servers, PCs, tablets, mobile phones, ECUs (Electronic Control Units), VCUs (Vehicle Control Units), MCUs (Micro Controller Units), HCUs (Hybrid Control Units), etc.

[0248] Another embodiment of this application provides a computer storage medium for storing a computer program, which, when executed, is used to implement a bond trading inquiry assistance method as provided in any of the above embodiments.

[0249] Computer storage media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0250] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0251] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for assisting in bond trading price inquiries, characterized in that, include: Obtain the inquiry text during the bond trading inquiry process; The inquiry text is input into the recognition model to obtain the structured transaction elements corresponding to the inquiry text; Obtain compliance-related data corresponding to the structured transaction elements; the compliance-related data includes at least position data, transaction record data, and counterparty data; Based on the aforementioned compliance-related data, a compliance check is performed on the structured transaction elements to obtain the compliance check results; If the compliance check result indicates that the proposed transaction corresponding to the structured transaction element does not comply with the preset compliance rules, then a compliance warning message corresponding to the proposed transaction is generated based on the compliance check result; the preset compliance rules are the compliance rules corresponding to the compliance-related data. The compliance warning information is sent to the terminal corresponding to the inquiry text, and a confirmation result for the compliance warning information is obtained; Based on the confirmation result, an inquiry message corresponding to the inquiry text is generated.

2. The method according to claim 1, characterized in that, The step of inputting the inquiry text into the recognition model to obtain the structured transaction elements corresponding to the inquiry text includes: The inquiry text is input into the recognition model, where the inquiry text is encoded into characters to obtain text representation data. Based on the text representation data, local feature extraction and bidirectional temporal feature extraction are performed in parallel to obtain local features and temporal features; The local features are aligned by time steps, and the aligned local features are concatenated with the temporal features to obtain the concatenated features; The spliced ​​features are then subjected to feature mapping to obtain sequence decoding features; Based on the sequence decoding features, the emission score of each candidate tag corresponding to the position of each character in the query text is determined, and the transition score between adjacent candidate tags is obtained; Based on the launch score and the transfer score, calculate the sequence score corresponding to each candidate tag sequence, and determine the candidate tag sequence with the highest sequence score as the tag sequence; The tag sequence is aggregated to obtain the structured transaction elements corresponding to the inquiry text.

3. The method according to claim 1, characterized in that, The compliance check on the structured transaction elements based on the compliance-related data, to obtain the compliance check results, includes: Based on the bond identifier in the structured transaction elements, the holding information corresponding to the bond identifier is determined from the holding data, and the holding information is compared with a preset holding ratio threshold to obtain a first comparison result; Target transaction records corresponding to the bond identifier within a preset time range are selected from the transaction record data, and the transaction direction in the structured transaction elements is compared with the transaction direction corresponding to the target transaction records to obtain a second comparison result; Credit information is determined from counterparty data, and the comparison result of the credit limit corresponding to the proposed transaction is determined based on the number of transactions in the structured transaction elements and the credit information. Due diligence information is determined from the counterparty data, and the due diligence information is matched with preset counterparty admission criteria to obtain a matching result; Based on the first comparison result, the second comparison result, the credit limit comparison result, and the matching result, a compliance check result is generated.

4. The method according to claim 1, characterized in that, The process of generating compliance warning information corresponding to the proposed transaction based on the compliance check results includes: Filter out target inspection results that do not conform to the preset compliance rules from the compliance inspection results; Determine the target preset compliance rule corresponding to the target inspection result and the target inspection data that triggers the target preset compliance rule; Based on the target's preset compliance rules and the target's inspection data, a compliance warning information corresponding to the proposed transaction is generated.

5. The method according to claim 1, characterized in that, The step of generating the inquiry message corresponding to the inquiry text based on the confirmation result includes: If the confirmation result indicates that the proposed transaction should continue, then obtain the dialogue context information corresponding to the inquiry text; The structured transaction elements and the dialogue context information are input into the large language model to obtain the inquiry message.

6. The method according to claim 1, characterized in that, Also includes: Obtain the counterparty information corresponding to the inquiry message; Based on the counterparty information, determine the instant messaging session corresponding to the inquiry message; Send the inquiry message to the instant messaging session; Once the inquiry message is sent, the conversation status of the instant messaging session will be updated to "waiting for reply".

7. The method according to claim 1, characterized in that, Also includes: If the message type corresponding to the inquiry text is an external inquiry type, then the bond type corresponding to the inquiry text is determined based on the structured transaction elements; Based on the bond type, the target trader responsible for the bond type is determined from the preset trader assignment data; Based on the structured trading elements, obtain the corresponding bond market data and trading indicator data; A structured inquiry summary is generated based on the structured transaction elements, the bond market data, and the transaction indicator data; The structured query summary is sent to the terminal corresponding to the target trader, and the intention confirmation result for the structured query summary is obtained; The instant messaging session corresponding to the inquiry text is processed based on the intention confirmation result.

8. A bond trading inquiry auxiliary device, characterized in that, include: The first acquisition unit is used to acquire the inquiry text during the bond transaction inquiry process; The input unit is used to input the inquiry text into the recognition model to obtain the structured transaction elements corresponding to the inquiry text; The second acquisition unit is used to acquire compliance-related data corresponding to the structured transaction elements; the compliance-related data includes at least position data, transaction record data, and counterparty data; The inspection unit is used to perform compliance checks on the structured transaction elements based on the compliance-related data, and obtain compliance check results; The first generation unit is configured to generate compliance warning information corresponding to the proposed transaction based on the compliance check result if the compliance check result indicates that the proposed transaction corresponding to the structured transaction element does not comply with the preset compliance rules; the preset compliance rules are the compliance rules corresponding to the compliance-related data. The sending unit is used to send the compliance warning information to the terminal corresponding to the inquiry text, and to obtain the confirmation result for the compliance warning information; The second generation unit is used to generate an inquiry message corresponding to the inquiry text based on the confirmation result.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed by a processor, performs the bond trading inquiry assistance method according to any one of claims 1-7.

10. An electronic device, characterized in that, include: Processor, memory, and bus; The processor and the memory are connected via the bus; The memory is used to store a program, and the processor is used to run the program, wherein the program is executed by the processor to perform the bond trading inquiry assistance method according to any one of claims 1-7.

Images