Transaction session management method and device, medium and equipment

Abstract

The invention discloses a transaction session management method and device, a medium and equipment, and belongs to the technical field of financial security transactions. Comprising the steps of obtaining first session content of a transaction opponent terminal; according to a transaction opponent identifier and a transaction instruction identifier in the first session content, storing the first session content in a transaction session container corresponding to the transaction instruction identifier in an opponent session container corresponding to the transaction opponent identifier; the transaction instruction identifier of the first session content is used for identifying a transaction instruction for the first session content; and generating a second session content according to a plurality of session contents stored in a plurality of transaction session containers under the opponent session container corresponding to the transaction opponent identifier, and sending the second session content to the transaction opponent terminal.

Description

Technical Field

[0001] This application belongs to the field of financial securities trading technology, specifically relating to a trading session management method, device, medium, and equipment. Background Technology

[0002] Reverse repurchase agreements are an important short-term financing method in the financial market. In a reverse repurchase agreement, investors (lenders) lend funds to borrowers (receivers), using bonds as collateral. For example, when the stock market is highly volatile, some institutional investors choose to participate in reverse repurchase transactions to obtain stable short-term returns. They submit reverse repurchase orders through the stock exchange's trading system, lending idle funds to other market participants who need funds, and receiving the principal and interest upon maturity.

[0003] Currently, reverse repurchase agreement (RPA) trading systems primarily rely on manual operation, supplemented by basic automation tools such as simple chatbots or RPA workflow automation robots. This approach presents a significant technical problem: it cannot effectively distinguish between transactions between different counterparties or between different transactions under the same counterparty. In large investment management institutions, multiple counterparties typically participate in RPA trading simultaneously. These counterparties may manage different funding accounts or operate under different trading strategies. A single chatbot can only handle simple one-on-one questions and answers, failing to differentiate between multiple transactions from the same counterparty. It lacks multi-channel session management and session isolation mechanisms, resulting in mixed conversation content from different counterparties and transactions, making it highly prone to errors.

[0004] Therefore, there is an urgent need for a technical solution that can address the above problems in order to improve the efficiency, accuracy and security of multi-transaction session processing. Summary of the Invention

[0005] The purpose of this application is to provide a transaction session management method, apparatus, medium, and device that can address the aforementioned problems.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a transaction session management method, the method comprising: Obtain the first session content of the counterparty's terminal; Based on the counterparty identifier and transaction instruction identifier in the first session content, the first session content is stored in the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier; the transaction instruction identifier of the first session content is used to identify the transaction instruction to which the first session content is targeted. Based on the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, a second session content is generated and sent to the counterparty terminal.

[0007] Optionally, after sending the second session content to the counterparty terminal, the method further includes: Receive third session content sent by the counterparty's terminal; Based on the counterparty identifier in the third session content, the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier are determined as the context of the third session content. Based on the content of the third session and the context of the third session, the transaction instruction identifier of the third session is determined; the transaction instruction identifier of the third session is used to identify the transaction instruction targeted by the third session. Based on the counterparty identifier and transaction instruction identifier of the third session content, the third session content is stored in the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier.

[0008] Optionally, after storing the first session content into the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier, the method further includes: Based on the value of the transaction instructions corresponding to multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, freeze the current credit limit of the counterparty identifier; Based on the value of the current trading object of the counterparty identifier and the trading instruction identifier, a transaction-level risk control assessment is performed to obtain the transaction-level risk control assessment result of the trading instruction identifier; Based on the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, a second session content is generated, including: The second session content is generated based at least on the transaction-level risk control assessment result identified by the transaction instruction.

[0009] Optionally, after storing the first session content into the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier, the method further includes: The current credit limit of the counterparty identifier is determined based on the total value of the multiple transaction instructions corresponding to the multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier. Based on the current credit limit of the counterparty identifier, a counterparty-level risk control assessment is performed to obtain the counterparty-level risk control assessment result of the counterparty identifier; Based on the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, a second session content is generated, including: The second session content is generated based on the transaction-level risk control assessment result of the transaction instruction identifier and the counterparty-level risk control assessment result of the counterparty identifier.

[0010] Optionally, the transaction instruction identifier is associated with multiple counterparty terminals; the method further includes: Receive a confirmation message from a counterparty's terminal; Based on the counterparty identifier and transaction instruction identifier in the confirmed transaction message, the confirmed transaction message is stored in the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier; Based on the transaction instruction corresponding to the transaction session container storing the confirmed transaction message, the current credit limit of the counterparty identifier is deducted.

[0011] Optionally, the transaction instruction identifier is associated with multiple counterparty terminals; the method further includes: Receive a confirmation message from a counterparty's terminal; Based on the counterparty identifier and transaction instruction identifier in the confirmed transaction message, a transaction termination prompt message is sent to other counterparty terminals associated with the transaction instruction corresponding to the transaction instruction, excluding the counterparty terminal. Based on the value of the transaction instruction corresponding to the other counterparty identifier and the transaction instruction identifier, the current credit limit of the other counterparty identifier is released. The other counterparty identifier is the counterparty identifier of the other counterparty terminal.

[0012] Optionally, after obtaining the first session content of the counterparty's terminal, the method further includes: Based on the counterparty identifier in the first session content, determine whether there is a counterparty session container corresponding to the counterparty identifier; If no counterparty session container corresponding to the counterparty identifier exists, a counterparty session container for the counterparty terminal is created based on the counterparty identifier; and a transaction session container is created under the counterparty session container for the counterparty terminal based on the transaction instruction identifier. If a counterparty session container corresponding to the counterparty identifier exists, determine whether a transaction session container corresponding to the transaction instruction identifier exists. If no transaction session container corresponding to the transaction instruction identifier exists, create a transaction session container under the counterparty session container of the counterparty terminal according to the transaction instruction identifier. In cases involving multiple transaction instructions, each of the multiple transaction session containers under the counterparty session container corresponds one-to-one with the transaction instruction identifier of the multiple transaction instructions.

[0013] Secondly, embodiments of this application provide a transaction session management device, the device comprising: The first session content acquisition module is used to acquire the first session content of the counterparty's terminal. The first session content storage module is used to store the first session content into a transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier, based on the counterparty identifier and transaction instruction identifier in the first session content; the transaction instruction identifier of the first session content is used to identify the transaction instruction to which the first session content is targeted. The second session content generation module is used to generate second session content based on multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, and send the second session content to the counterparty terminal.

[0014] Thirdly, embodiments of this application provide a readable storage medium storing a program or instructions that, when executed by a processor, implement the steps of the transaction session management method as described in the first aspect.

[0015] Fourthly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0016] In this application embodiment, a transaction session management method, apparatus, medium, and device are provided, the method including: The technical solution of this application achieves accurate identification, isolation, and association of multiple transaction sessions. Specifically, by utilizing counterparty identifiers and transaction instruction identifiers, the content of each session is accurately stored in the corresponding transaction session container. This ensures that transaction sessions from different counterparty terminals for different transaction instructions are accurately distinguished and managed independently, effectively solving the core problem of session mixing in related technologies, avoiding information crosstalk and omissions. It not only improves the accuracy and efficiency of multi-transaction session processing but also provides two-layer upper and lower level container isolation, enhancing the security of each transaction session. It can be used for multi-dialogue management and risk control in financial transaction scenarios. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a transaction session management method provided in an embodiment of this application; Figure 2 This is a complete flowchart of a transaction session management method provided in one embodiment of this application; Figure 3 This is a schematic diagram of the framework of a transaction session management device provided in one embodiment of this application; Figure 4 A schematic diagram of the hardware structure of an electronic device to implement an embodiment of this application. Detailed Implementation

[0018] 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, 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.

[0019] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0020] In current financial trading scenarios, manual operation is the primary method, supplemented by basic automation tools such as simple chatbots or RPA process automation robots. However, these existing solutions have many limitations. For example, a single chatbot can only handle simple one-on-one questions and answers, cannot distinguish multiple transactions from the same counterparty, and lacks multi-channel conversation management and joint risk control capabilities. Rule-matching robots rely on fixed keyword matching, cannot understand human language habits such as "precedence ellipsis," resulting in unnatural dialogue, poor error tolerance, and susceptibility to interference from non-standard expressions. Stateless automated scripts can execute simple interface calls but cannot maintain complex conversation states, cannot correlate previous and subsequent conversation content, and cannot achieve cross-conversation state synchronization and risk control indicator updates. Furthermore, existing solutions lack effective conversation identification and isolation mechanisms, leading to a mixture of conversation information from different traders and different transactions, which is highly prone to errors. Intent recognition capabilities are weak; rule-based matching cannot accurately understand the trader's implicit intent in natural language, especially adjustments to a previous transaction, leading to interaction failures or the need for manual intervention. The fragmented risk control checks prevent the linkage and synchronous calculation of "transaction-level" risk control and "trader-level" joint risk control within a single automated process. The lack of a global status synchronization mechanism means that once a transaction is completed, other ongoing related inquiries cannot be automatically and promptly notified, leading to the ineffective use of resources (such as quotas) and potentially triggering excess risk.

[0021] Specifically, in the reverse repurchase transaction scenario, the lender will issue multiple trading instructions. Each trading instruction indicates the funds needed to repurchase the pledged securities of the borrower. Different trading instructions correspond to different amounts of funds. For the borrower, the corresponding pledged securities need to be pledged to the lender in order to obtain the funds corresponding to the trading instructions issued by the lender.

[0022] During a transaction, for the same transaction instruction (i.e., the same amount of funds) issued by the lender, the lender may simultaneously engage in transaction sessions with multiple borrowers; similarly, for multiple transaction instructions (i.e., multiple amounts of funds), the lender may engage in multiple transaction sessions with the same borrower. In this complex transaction scenario involving multiple counterparty terminals and multiple transaction instructions, it is not only necessary to distinguish between different counterparty terminals and different transaction instructions, but also to ensure that the context of the transaction content in each transaction session for each transaction is independent and accurately associated with the corresponding transaction instruction, avoiding crosstalk and omissions, so as to ensure that every transaction content can be correctly responded to and processed.

[0023] To address the aforementioned issues, this application provides a transaction session management method, apparatus, device, and medium. The following detailed description, in conjunction with the accompanying drawings, will illustrate the transaction session management method, apparatus, device, and medium provided by this application through specific embodiments and application scenarios.

[0024] Figure 1 This is a flowchart illustrating a transaction session management method provided in this application. Figure 2 This is a complete flowchart of a transaction session management method provided in one embodiment of this application. The transaction session management method of this application is applied to a repurchase inquiry robot, which is deployed on the terminal of the fund lender. The repurchase inquiry robot acts as an intermediary between the fund lender and multiple fund borrowers, and is used to receive the session content of multiple fund borrowers and provide accurate responses.

[0025] refer to Figure 1 This application provides a transaction session management method, which includes steps S11 to S13: Step S11: Obtain the first session content of the counterparty's terminal.

[0026] In this embodiment, the counterparty terminal refers to the trading terminal of the fund borrower. The repurchase inquiry robot receives the first session content sent by the fund borrower through the counterparty terminal. The first session content carries the trading instruction identifier and counterparty identifier of the trading instruction targeted by the fund borrower, as well as relevant information about the pledged securities; wherein, the trading instruction identifier is the identifier of one of the multiple trading instructions issued by the fund lender; the counterparty identifier refers to the identifier of the counterparty terminal (fund borrower).

[0027] Specifically, this application uses the scenario where the first trader terminal (as the fund lender) issues N trading instructions, and M counterparty terminals (fund borrowers, who need to pledge collateral to the fund borrower) conduct trading sessions with the repurchase inquiry robot based on these N trading instructions as an example.

[0028] The first trader terminal will issue N trading instructions (such as securities reverse repurchase instructions, each of which carries specific fund-related information, such as 50 million or 100 million). Taking the transaction of the m-th counterparty terminal among M trader terminals in response to N trading instructions as an example, the repurchase inquiry robot will receive N first session contents issued by the m-th counterparty terminal in response to the N trading instructions. Each first session contents is for a different trading instruction. For example, the n-th first session contents among the N first session contents issued by the m-th counterparty terminal is the first session contents issued for the n-th trading instruction. N and M are both integers greater than 1.

[0029] Similarly, the repurchase inquiry robot will also receive the first session content of the nth transaction instruction among the N transaction instructions issued by other counterparty terminals in the M counterparty terminals to the first trader terminal, and the other transaction instructions in the N transaction instructions will be processed in the same way.

[0030] This creates a complex trading scenario where a first trader terminal trades with multiple counterparty terminals, a first trader terminal trades with multiple counterparty terminals for each of multiple trading orders, and each counterparty terminal trades with the first trader terminal for multiple trading orders.

[0031] For example, suppose the first trader terminal issues two trading orders: Trading Order X (50 million) and Trading Order Y (100 million). Simultaneously, two counterparty terminals, Counterparty Terminal A (corresponding to external trading institution A) and Counterparty Terminal B (corresponding to external trading institution B), participate in the price inquiry. Each counterparty terminal issues a first session content for each trading order; that is, external trading institution A issues first session content AX (for trading order X) and second session content AY (for trading order Y), while external trading institution B issues first session content BX (for trading order X) and second session content BY (for trading order Y).

[0032] Step S12: Based on the counterparty identifier and transaction instruction identifier in the first session content, store the first session content into the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier; the transaction instruction identifier of the first session content is used to identify the transaction instruction to which the first session content is targeted.

[0033] In this embodiment, the first session content carries a counterparty identifier and a transaction instruction identifier. The counterparty identifier is used to indicate the counterparty terminal that sent the first session content, and the transaction instruction identifier is used to indicate the transaction instruction that the first session content is targeting.

[0034] For ease of management, this embodiment sets up a counterparty session container for each counterparty terminal. Under the counterparty session container, multiple trading session containers are created for the transactions corresponding to multiple trading instructions between the counterparty terminal and the first trader terminal. In this way, different counterparty terminals are distinguished by counterparty session containers, and multiple transactions between the first trader terminal and the same counterparty terminal (each transaction corresponds to a trading instruction) are distinguished by different trading session containers.

[0035] Specifically, continuing the example above, the counterparty session container of the m-th counterparty terminal contains N trading session containers. The n-th trading session container among the N trading session containers corresponds to the trading session container between the first trader terminal and the m-th trader terminal for the n-th trading instruction.

[0036] Since the m-th counterparty terminal will issue N first session contents based on N trading instructions, and these N first session contents will be displayed on the same trading page of the repurchase inquiry robot, after the repurchase inquiry robot receives the n-th first session content, it needs to identify which counterparty terminal issued the first session content for which trading instruction. Therefore, the repurchase inquiry robot can determine that the n-th first session content was issued by the m-th counterparty terminal for the n-th trading instruction based on the counterparty identifier of the m-th counterparty terminal and the trading instruction identifier of the n-th trading instruction contained in the n-th first session content. Then, the n-th first session content is accurately stored in the counterparty session container corresponding to the m-th counterparty terminal and the n-th trading session container corresponding to the n-th trading instruction.

[0037] Similarly, the repurchase inquiry robot will also store the (n+1)th first session content of the (n+1)th transaction instruction among the N transaction instructions issued by the m-th counterparty terminal in the (n+1)th first session content, according to the counterparty identifier of the m-th counterparty terminal and the transaction instruction identifier in the (n+1)th first session content, into the N transaction session containers contained under the counterparty session container of the m-th counterparty terminal. This corresponds to the transaction session container between the first trader terminal and the m-th trader terminal for the (n+1)th transaction instruction, i.e., the (n+1)th transaction session container. This achieves the isolation of the first session content of the same counterparty terminal for different transactions and the precise association of containers.

[0038] For example, suppose the first session content AX issued by external trading institution A is: "For trading instruction X, we pledge collateral 100001 and collateral 100002". Then we can identify the counterparty identifier of the counterparty terminal and the trading instruction identifier of trading instruction X corresponding to the first session content AX, and then store the first session content AX in the corresponding trading session container.

[0039] Step S13: Generate second session content based on the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, and send the second session content to the counterparty terminal.

[0040] In this embodiment, the repurchase inquiry robot needs to generate the second session content for the first session content of the counterparty terminal. This requires not only the context information of the transaction (corresponding to the transaction instruction) corresponding to the first session content (such as the change information of securities), but also the context information of other transactions (corresponding to other transaction instructions) of the counterparty terminal (such as joint risk control between multiple transactions).

[0041] Therefore, after determining which trading instruction between the counterparty terminal and the first trader terminal the first session content sent by the counterparty terminal is intended for, and storing the first session content in the corresponding trading session container, it is necessary to integrate and analyze the multiple session contents stored in the multiple trading session containers under the counterparty session container corresponding to the counterparty identifier of the counterparty terminal, in order to generate the second session content for replying to the counterparty terminal (such as using a large language model).

[0042] Through the technical solutions described in the above embodiments, the deployment and management of two-tiered upper and lower-level containers at the counterparty level and the transaction level achieves accurate identification, isolation, and association of multiple transaction sessions. Specifically, by utilizing the counterparty identifier of the counterparty terminal and the transaction instruction identifier of the transaction instruction, the content of each session is accurately stored in the corresponding transaction session container. This ensures that the session content of different counterparty terminals for different transaction instructions can be independently stored and accurately distinguished through the corresponding transaction session container. Especially for the management of multiple transaction sessions in business scenarios such as securities reverse repurchase agreements, this effectively solves the core problem of mixed transaction sessions in related technologies, avoids information crosstalk and omissions, and improves the accuracy and efficiency of transaction processing.

[0043] In conjunction with the technical solutions of the above embodiments, an embodiment of this application also provides another transaction session management method. In this method, after executing step S11 of "obtaining the first session content of the counterparty terminal", steps S21 to S23 are further included: Step S21: Determine whether there is a counterparty session container corresponding to the counterparty identifier based on the counterparty identifier in the first session content; In this embodiment, after receiving the first session message, it is first necessary to determine whether there is an existing counterparty session container that corresponds to the counterparty identifier carried in the first session message.

[0044] Step S22: If there is no counterparty session container corresponding to the counterparty identifier, create a counterparty session container for the counterparty terminal based on the counterparty identifier; and create a transaction session container under the counterparty session container of the counterparty terminal based on the transaction instruction identifier.

[0045] In this embodiment, reference Figure 2 To facilitate the management of transactions between the repurchase inquiry robot and multiple counterparty terminals, it is necessary to use the repurchase inquiry robot to call the two-layer context container management module to create a counterparty session container for each counterparty terminal. Then, based on the transaction instruction identifier, a corresponding transaction session container is created under the counterparty session container. One counterparty session container corresponds to one counterparty terminal (e.g., ...). Figure 2 The counterparty session container for counterparty terminal A is called counterparty session container A, and the counterparty session container for counterparty terminal B is called counterparty session container B. The counterparty session container serves as the top-level organizational structure, with each counterparty session container managing multiple transaction session containers created under it. Each counterparty session container further creates different transaction session containers for different transaction instructions to isolate the session content of different transactions. The session content of the same transaction is stored in one transaction session container, ensuring that different transaction sessions between different counterparty terminals are independent of each other, avoiding confusion and crosstalk.

[0046] Step S23: If a counterparty session container corresponding to the counterparty identifier exists, determine if a transaction session container corresponding to the transaction instruction identifier exists. If no transaction session container corresponding to the transaction instruction identifier exists, create a transaction session container under the counterparty session container of the counterparty terminal according to the transaction instruction identifier. Wherein, if multiple transaction instructions are included, the multiple transaction session containers under the counterparty session container correspond one-to-one with the transaction instruction identifiers of the multiple transaction instructions.

[0047] For example, suppose the first trader terminal (e.g., trader Zhang San of the corresponding internal trading institution) issues two trading orders: trade order X (corresponding to 50 million) and trade order Y (corresponding to 100 million). The repurchase inquiry robot trades with two counterparty terminals (external trading institution A and external trading institution B). A counterparty session container will be created for each counterparty terminal. Counterparty terminal A (external trading institution A): Counterparty session container A; Counterparty terminal B (external trading institution B): Counterparty session container B; External trading institution A matches these two trading orders separately. This will create two trading session containers under the counterparty session container of external trading institution A: Transaction session container AX: corresponds to transaction instruction X, and is used to store the session content of counterparty terminal A in response to transaction instruction X; Transaction session container AY: corresponds to transaction instruction X, and is used to store the session content of counterparty terminal A in response to transaction instruction X; External trading institution B will match these two trading orders separately. This will create two trading session containers under the counterparty session container of external trading institution B: Transaction session container BX: corresponds to transaction instruction X, and is used to store the session content of the counterparty terminal B in response to transaction instruction X; Transaction session container BY: corresponds to transaction instruction X, and is used to store the session content of the counterparty terminal B in response to transaction instruction X.

[0048] In conjunction with the technical solutions of the above embodiments, considering that rule-based matching in related technologies cannot accurately understand the trader's implied intentions in natural language (especially in cases where adjustments are made to the collateral of a previous transaction), leading to interaction failures or the need for manual intervention, this application provides another transaction session management method in an embodiment. In this method, after executing step S13, "sending the second session content to the counterparty terminal," steps S31 to S34 are further included: Step S31: Receive the third session content sent by the counterparty terminal.

[0049] In this embodiment, a transaction session for a transaction instruction includes multiple rounds of dialogue, and the third session content refers to the other session content sent by the counterparty terminal after the first session content.

[0050] Step S32: Based on the counterparty identifier in the third session content, determine the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier as the context of the third session content.

[0051] In this embodiment, because the counterparty terminal may use ellipsis in some subsequent conversations during multi-turn dialogues in a transaction session, some conversation content may omit previously mentioned content. For example, new conversation content may not contain a transaction instruction identifier for a previously mentioned transaction instruction, or a previously mentioned transaction object. This type of conversation content is called third conversation content. Therefore, in this case, it is necessary to determine the counterparty conversation container corresponding to the counterparty terminal that issued the third conversation content based on the counterparty identifier in the third conversation content. Then, the multiple conversation contents stored in the multiple transaction conversation containers under the counterparty conversation container are used as the context of the third conversation content to facilitate subsequent determination of which transaction instruction the third conversation content is for.

[0052] Step S33: Determine the transaction instruction identifier of the third session content based on the third session content and the context of the third session content.

[0053] In this embodiment, the transaction instruction identifier of the third session content can be determined by combining the association between the third session content and the context of the third session content through a large language model. The transaction instruction identifier of the third session content is used to identify the transaction instruction targeted by the third session content.

[0054] Step S34: Based on the counterparty identifier and transaction instruction identifier of the third session content, store the third session content into the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier.

[0055] By combining the technical solutions of the above embodiments with the capabilities of large language models, the repurchase inquiry robot's ability to understand complex contexts and implicit intentions is improved, making the content of multiple conversations between a single transaction session more natural and intelligent.

[0056] In this embodiment, this step is referred to as step S12 and will not be repeated. After storing the third session content, a response to the third session content is generated and sent to the counterparty terminal, referring to step S13.

[0057] In conjunction with the technical solutions of the above embodiments, an embodiment of this application also provides another transaction session management method. In this method, after performing step S12, "storing the first session content into the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier", the method further includes steps S41 to S42: Step S41: Freeze the current credit limit of the counterparty identifier based on the value of the transaction instructions corresponding to the multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier.

[0058] In this embodiment, for each transaction session container, if the transaction session container is not terminated, the current credit limit of the corresponding counterparty terminal needs to be pre-allocated according to the value of the transaction instruction for that transaction session container, to avoid exceeding the credit limit due to multiple transactions occurring simultaneously. Here, the value of the transaction instruction refers to the amount of funds corresponding to that transaction instruction.

[0059] For example, suppose counterparty terminal A's current credit limit is 200 million, and the value of the transaction instruction corresponding to the nth transaction session container of counterparty terminal A is 150 million. The repurchase inquiry robot updates counterparty terminal A's current credit limit based on the transaction instruction value of 150 million. The updated current credit limit represents 50 million as the actual usable amount (200 million - 100 million = 50 million), of which 150 million is frozen funds. Therefore, when conducting a new transaction, counterparty-level risk control assessment is performed based on the current credit limit of 50 million. The frozen amount cannot be used for other transactions until it is released.

[0060] Step S42: Based on the value of the current trading object of the counterparty identifier and the trading instruction identifier, perform a transaction-level risk control assessment to obtain the transaction-level risk control assessment result of the trading instruction identifier.

[0061] In this embodiment, the transaction session container stores multiple session contents of the counterparty terminal for the transaction instruction corresponding to the transaction session container. Based on these session contents, the current transaction object (such as the latest pledged securities) of the counterparty terminal for the transaction instruction can be determined.

[0062] For example, the nth transaction session container will store multiple session contents issued by the mth counterparty terminal in response to the nth transaction instruction (that is, the multiple session contents issued in response to the nth transaction instruction include multiple historical session contents (as multiple session contents already stored in the transaction session container) and the first session content currently received).

[0063] Specifically, each interaction between the m-th counterparty terminal and the n-th transaction instruction can be understood as a first session, including but not limited to inquiries about collateral prices, changes in collateral, additions of collateral, and reductions in collateral. After storing the n-th first session content, the latest collateral contained in the n-th transaction session container can be determined based on all the first session content related to the n-th transaction instruction stored therein. The latest collateral represents the collateral currently held by the m-th counterparty terminal for the n-th transaction instruction, i.e., the current trading partner.

[0064] For example, suppose the nth transaction session container stores multiple first session contents indicating that pledged securities 100001 and 100002 are pledged. These are used as the context of the nth first session content. The nth first session content indicates that pledged securities 100002 is changed to pledged securities 100003. Then, based on the context and the nth first session content, the latest pledged securities contained in the nth transaction session container can be determined to be: pledged securities 100001 and pledged securities 100003, which are the current transaction objects.

[0065] Once the current trading counterparty is identified, a transaction-level risk control assessment can be performed on its value to obtain the transaction-level risk control assessment result of the current trading counterparty for the corresponding transaction instruction identifier of the counterparty terminal. The transaction-level risk control assessment result is used to represent the value of the current trading counterparty calculated according to the discount rate and the compliance of the current trading counterparty.

[0066] Specifically, after obtaining the current trading object (such as the latest pledged securities) contained in the nth trading session container, the repurchase inquiry robot accesses the internal investment management system of the institution where the first trader terminal (fund lender) is located, precisely associates the investment account corresponding to the counterparty terminal that issued the first session content, and automatically invokes the compliance rules of the corresponding investment account for verification. For example, according to the information (discount rate and compliance) of each trading object stored, the compliance of each trading object is determined, and the value of each trading object in the current trading objects contained in the nth trading session container is calculated. Then, based on the value and compliance of the current trading objects contained in the nth trading session container, the trading-level risk control evaluation result of the first session content of the nth is determined.

[0067] Step S13 "Generate the second session content according to the multiple session contents stored in the multiple trading session containers under the counterparty session container corresponding to the counterparty identifier" includes: Step S13-1-1, generate the second session content at least according to the trading-level risk control evaluation result of the trading instruction identifier.

[0068] In this embodiment, after obtaining the trading-level risk control evaluation result, the second session content is generated based on this trading-level risk control evaluation result. For example, the value and compliance of the current trading object are sent to the counterparty terminal as the quotation result. Among them, when both "the value of the current trading object calculated according to the discount rate needs to satisfy being greater than the value of the funds corresponding to the trading instruction" and "the current trading object is compliant" are satisfied, it can be determined that the trading-level risk control evaluation result of the current trading object is qualified, and the counterparty terminal is informed that the current trading object is qualified by sending the second session content. Otherwise, it is unqualified, and the counterparty terminal needs to be prompted by sending the second session content to replace the trading object.

[0069] Through the technical solutions of the above embodiments, the current trading object in the trading session container can be accurately determined, and the trading-level risk control evaluation is carried out accordingly. At the same time, by comprehensively considering all the current transactions of the counterparty terminal, it is evaluated whether the current credit limit of the counterparty terminal is qualified, realizing the joint risk control at the trading level and the trader level, not only improving the accuracy of the risk assessment of a single transaction, but also enhancing the security and reliability of multiple transactions of the counterparty.

[0070] Combined with the technical solutions of the above embodiments, an embodiment of the present application further provides another trading session management method. In this method, after "store the first session content into the trading session container corresponding to the trading instruction identifier under the counterparty session container corresponding to the counterparty identifier" in step S12, it further includes steps S51 to step S52: Step S51: Determine the current credit limit of the counterparty identifier based on the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier.

[0071] In this embodiment, the current transaction object in each transaction session container is determined based on the multiple session contents stored in each of the multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier. The corresponding transaction-level risk control assessment result is determined based on each current transaction object. Then, the current credit limit of the counterparty terminal is determined based on the corresponding transaction-level risk control assessment result determined based on each current transaction object in the multiple transaction session containers under the counterparty session container.

[0072] Specifically, after obtaining the transaction-level risk control assessment result of the nth first session content, it is also necessary to determine the counterparty-level risk control assessment of the N first session contents within the N transaction session containers under the counterparty session container of the mth counterparty terminal. That is, to assess the value and compliance of the current transaction object in each of the N transaction session containers, and, assuming that the current transaction object in each transaction session container is compliant, calculate the total value of the N transaction instructions corresponding to the N transaction session containers. Then, based on the total credit limit of the counterparty terminal, obtain the current credit limit of the mth counterparty terminal. The current credit limit represents the current remaining credit limit of the mth counterparty terminal, which is a value that changes dynamically with the transaction completion.

[0073] For example, suppose the total credit limit of the m-th counterparty terminal is 200 million, and the trading instructions include trading instruction X (corresponding to 50 million) and trading instruction Y (corresponding to 100 million). The m-th counterparty terminal has two trading session containers. The trading instructions and the current trading objects (collateral) contained in these trading session containers are as follows: Transaction Session Container 1: For transaction instruction X, pledged securities 100004, valued at 60 million, with a discount rate of 90%, the usable value of the pledged securities is 60 million * 90% = 54 million > 50 million, meaning that the transaction-level risk control assessment result of Transaction Session Container 1 is qualified. Transaction Session Container 2: For transaction instruction Y, pledged securities 100002, valued at 200 million, with a discount rate of 90%, have an available value of 200 million * 90% = 180 million > 100 million, meaning that the transaction-level risk control assessment result of Transaction Session Container 2 is qualified.

[0074] Therefore, the total value of the two transaction instructions corresponding to the two transaction session containers is 150 million, while the total credit limit of the m-th counterparty terminal is 200 million. Therefore, the current credit limit is 200 million - 150 million = 50 million.

[0075] Step S52: Based on the current credit limit of the counterparty identifier, perform counterparty-level risk control assessment to obtain the counterparty-level risk control assessment result of the counterparty identifier.

[0076] In this embodiment, if the current credit limit is less than 0, it means that the peer-level risk control assessment result is unqualified; if the current credit limit is not less than 0, it means that the peer-level risk control assessment result is qualified.

[0077] Step S13, "Generate second session content based on multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier," includes: Step S13-2-1: Generate the second session content based on the transaction-level risk control assessment result of the transaction instruction identifier and the counterparty-level risk control assessment result of the counterparty identifier.

[0078] In this embodiment, the second session content is generated based on the transaction-level risk control assessment result of the transaction instruction identifier and the counterparty-level risk control assessment result of the counterparty identifier.

[0079] For example, when the transaction-level risk assessment result indicates that the current trading object for transaction instruction X is qualified and the value of the current trading object after discounting at a 90% discount rate is 100 million * 90% = 90 million, the counterparty-level risk assessment result indicates that the current credit limit is 50 million.

[0080] The generated second session content is as follows: The transaction-level risk control assessment result is qualified, the current transaction object for transaction instruction X is qualified, and the value of the current transaction object is 0.9 billion. The counterparty-level risk control assessment result is qualified, and the current credit limit is 0.5 billion.

[0081] The technical solution described above enables data aggregation and real-time computation across multiple independent session containers. During counterparty-level risk control assessment, it can aggregate data from all relevant transaction session containers of the counterparty terminal in real time and calculate two risk control indicators: transaction-level risk control assessment and counterparty-level risk control assessment. This ensures that the risk control assessment of a single transaction, as well as the total transaction risk of a single counterparty terminal, remains within a controllable range, thereby improving transaction security and compliance.

[0082] In conjunction with the technical solutions of the above embodiments, an embodiment of this application also provides another transaction session management method, in which the transaction instruction identifier is associated with multiple counterparty terminals; the method further includes steps S61 to S63: Step S61: Receive a confirmation message from a counterparty terminal.

[0083] In this embodiment, the counterparty terminal can determine whether to complete the transaction based on the value of the current trading object in the transaction-level risk control assessment result according to the second session message sent by the repurchase inquiry robot. If the transaction is confirmed, the repurchase inquiry robot will receive a confirmation message sent by the counterparty terminal.

[0084] Step S62: Based on the counterparty identifier and transaction instruction identifier in the confirmed transaction message, store the confirmed transaction message in the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier.

[0085] In this embodiment, when the repurchase inquiry robot receives a confirmation transaction message, it determines which counterparty terminal issued the confirmation transaction message for which transaction instruction based on the counterparty identifier and transaction instruction identifier in the confirmation transaction message. Then, it stores the confirmation transaction message in the corresponding transaction session container. This step can be referred to step S12.

[0086] Step S63: Based on the transaction instruction corresponding to the transaction session container storing the confirmed transaction message, deduct the current credit limit of the counterparty identifier.

[0087] In this embodiment, after identifying which transaction instruction the confirmation message refers to, the frozen funds in the current credit limit are deducted according to the value of the funds corresponding to that transaction instruction. The frozen funds refer to the amount of funds in a transaction instruction that is being traded but has not yet been executed. The frozen funds will only be deducted according to the value of the funds corresponding to the transaction instruction when the transaction instruction is actually executed.

[0088] For example, suppose the total credit limit of the counterparty terminal is 200 million. The value of the transaction instruction X corresponding to the currently ongoing transaction session container 1 is 30 million, the value of the transaction instruction Y corresponding to the currently ongoing transaction session container 2 is 20 million, and the value of the completed transaction instruction Z is 50 million. Then, the current credit limit is 200 million - 50 million = 150 million, but 30 million + 20 million = 50 million of the 170 million will be frozen as funds.

[0089] In conjunction with the technical solutions of the above embodiments, an embodiment of this application also provides another transaction session management method, in which the transaction instruction identifier is associated with multiple counterparty terminals; the method further includes steps S71 to S73: Step S71: Receive a confirmation message from a counterparty terminal.

[0090] In this embodiment, this step refers to step S51.

[0091] Step S72: Based on the counterparty identifier and transaction instruction identifier in the confirmed transaction message, send a transaction termination prompt message to other counterparty terminals associated with the transaction instruction corresponding to the transaction instruction, excluding the counterparty terminal.

[0092] In this embodiment, based on the counterparty identifier and transaction instruction identifier carried in the transaction confirmation message, it is determined which counterparty terminal sent the transaction confirmation message for which transaction instruction.

[0093] Step S73: Based on the value of the transaction instruction corresponding to the other counterparty identifier and the transaction instruction identifier, release the current credit limit of the other counterparty identifier, where the other counterparty identifier is the counterparty identifier of the other counterparty terminal.

[0094] In this embodiment, after determining which counterparty terminal issued the confirmation message for which transaction instruction, the frozen funds limit for other counterparty terminals is released according to the value of the transaction instruction.

[0095] For example, if trading instruction X (corresponding to funds of 50 million) and trading instruction Y (corresponding to funds of 100 million) are currently being inquired about by counterparty terminal A and counterparty terminal B at the same time, then each of counterparty terminal A and counterparty terminal B has two frozen funds in their current credit limit, corresponding to trading instruction X and trading instruction Y respectively.

[0096] At this moment, the repurchase inquiry robot received a confirmation message. Based on the counterparty identifier and transaction instruction identifier carried in the confirmation message, the robot identified that the confirmation message was sent by counterparty terminal A in response to transaction instruction X. Therefore, transaction instruction X was executed with counterparty terminal A, and the 50 million yuan corresponding to transaction instruction X was deducted from the 50 million yuan frozen limit in counterparty terminal A's current credit line. Then, since counterparty terminal B was also inquiring about transaction instruction X, the repurchase inquiry robot sent a termination message to counterparty terminal B, such as: "Your inquiry transaction instruction has been executed with other external trading institutions, and this transaction is automatically terminated." The 50 million yuan corresponding to transaction instruction X was released from the 50 million yuan frozen limit in counterparty terminal B's current credit line. This ensures the timeliness and accuracy of each transaction and avoids the problem of duplicate transactions where one transaction instruction is executed with multiple counterparty terminals.

[0097] It should be noted that as the status of each trading session container changes (such as the transaction being completed or terminated), it will notify other trading session containers under the same trading instruction in real time via broadcast.

[0098] By employing the technical solutions described in the above embodiments, this approach avoids the risk of the credit limit not being automatically and promptly synchronized with other ongoing related inquiries on the counterparty's terminal after a transaction order is executed or terminated. This could lead to the credit limit being invalidally used after the transaction is terminated, or the risk of the credit limit not being deducted even though the transaction has been completed.

[0099] The problems that this application can solve through the technical solutions of the above embodiments are as follows: Addressing pain point 1: Complex rules and frequent coupon matching; In traditional reverse repurchase agreements, traders need to manually handle complex risk assessments such as discount rate calculations and compliance checks. These calculations typically involve multiple variables and rules, and frequent changes in the collateral pool require traders to constantly update and recalculate. This manual approach is not only time-consuming and labor-intensive but also prone to human error, leading to multiple rounds of communication and transaction delays. To address this issue, this application can automatically access the internal investment management system via a robot to instantly complete complex discount rate calculations and compliance checks without manual copying and pasting, significantly reducing the need for multiple rounds of communication caused by complex rules and changes in the collateral pool.

[0100] Addressing pain point 2: Different compliance requirements for multiple accounts; In securities reverse repurchase transactions, different investment accounts often have different compliance requirements. Traders need to manually link the investment account corresponding to each trading order and verify it according to the relevant compliance rules. This process is not only cumbersome but also prone to errors, especially when dealing with multiple accounts and multiple orders. To solve this problem, this application can use a robot to accurately link the investment accounts corresponding to different trading orders and automatically call the corresponding account's compliance rules for verification, ensuring the accuracy of the check.

[0101] Addressing pain point 3: High efficiency requirements for price inquiries before market close; Before the close of trading, traders typically face intense pressure to complete a large number of inquiries and trades within a short period. Traditional manual inquiry methods are slow and struggle to meet these high-efficiency demands. To address this issue, this application utilizes a robot to simultaneously initiate and process inquiries from a massive number of trading institutions, achieving a response speed far exceeding that of manual methods and effectively managing the concentrated trading pressure before the market closes.

[0102] Addressing pain point 4: Errors are prone to occur when managing multi-channel conversations; In multi-channel natural language dialogues, traders need to manage conversations involving multiple traders conducting multiple transactions simultaneously. This complex transaction conversation management is prone to crosstalk and omissions, affecting the accuracy and efficiency of transactions. To address this issue, this application utilizes a two-layered hierarchical container—a "counterpartner conversation container" and a "transaction conversation container"—along with the application of a large language model to recognize the intent of the conversation content sent by the counterparty terminal. This allows the robot to accurately distinguish between different counterparty terminals and different transactions, avoiding crosstalk and omissions, and ensuring that every transaction conversation is correctly responded to and processed.

[0103] Figure 3 This is a schematic diagram of the framework of a transaction session management device according to an embodiment of this application, with reference to... Figure 3 The device includes: First Session Content Acquisition Module 11 is used to acquire the first session content of the counterparty's terminal; The first session content storage module 12 is used to store the first session content into a transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier, based on the counterparty identifier and transaction instruction identifier in the first session content; the transaction instruction identifier of the first session content is used to identify the transaction instruction to which the first session content is targeted. The second session content generation module 13 is used to generate second session content based on multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, and send the second session content to the counterparty terminal.

[0104] Optionally, the device further includes: The third session content acquisition module is used to receive the third session content sent by the counterparty terminal after sending the second session content to the counterparty terminal. The context determination module is used to determine the context of the third session content as the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier in the third session content. The transaction instruction identifier determination module is used to determine the transaction instruction identifier of the third session content based on the third session content and the context of the third session content; the transaction instruction identifier of the third session content is used to identify the transaction instruction to which the third session content is targeted. The third session content storage module is used to store the third session content into a transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier, based on the counterparty identifier and the transaction instruction identifier of the third session content.

[0105] Optionally, the device further includes: The credit limit freezing module is used to freeze the current credit limit of the counterparty identifier after storing the first session content into the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier, based on the value of the transaction instruction corresponding to the multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier. The transaction-level risk control assessment module is used to perform transaction-level risk control assessment based on the value of the current trading object of the counterparty identifier and the transaction instruction identifier, and obtain the transaction-level risk control assessment result of the transaction instruction identifier; The second session content generation module 13 includes: The first generation unit is used to generate second session content based at least on the transaction-level risk control assessment result identified by the transaction instruction.

[0106] Optionally, the device further includes: The determining module is used to determine the current credit limit of the counterparty identifier based on the total value of the multiple transaction instructions corresponding to the multiple transaction sessions under the counterparty session container corresponding to the counterparty identifier after storing the first session content into the transaction session container corresponding to the counterparty identifier and the transaction instruction identifier. The counterparty-level risk control assessment module is used to perform counterparty-level risk control assessment based on the current credit limit of the counterparty identifier, and obtain the counterparty-level risk control assessment result of the counterparty identifier; The second session content generation module 13 includes: The second generation unit generates the second session content based on the transaction-level risk control assessment result of the transaction instruction identifier and the counterparty-level risk control assessment result of the counterparty identifier.

[0107] Optionally, the transaction instruction identifier is associated with multiple counterparty terminals; the device further includes: The first receiving module is used to receive a confirmation message of a transaction sent by a counterparty's terminal; The first storage module is used to store the confirmed transaction message into a transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier, based on the counterparty identifier and the transaction instruction identifier in the confirmed transaction message; The deduction module is used to deduct the current credit limit of the counterparty identifier based on the transaction instruction corresponding to the transaction session container storing the confirmed transaction message.

[0108] Optionally, the transaction instruction identifier is associated with multiple counterparty terminals; the device further includes: The second receiving module is used to receive a confirmation message sent by a counterparty terminal; The second storage module is used to send a transaction termination prompt message to other counterparty terminals (excluding the counterparty terminal) associated with the transaction instruction corresponding to the transaction instruction in the transaction confirmation message, based on the counterparty identifier and the transaction instruction identifier in the transaction confirmation message. The release module is used to release the current credit limit of the other counterparty identifier based on the other counterparty identifier and the value of the transaction instruction corresponding to the transaction instruction identifier, wherein the other counterparty identifier is the counterparty identifier of the other counterparty terminal.

[0109] Optionally, the device further includes: The first judgment module is used to determine, after obtaining the first session content of the counterparty terminal, whether there is a counterparty session container corresponding to the counterparty identifier in the first session content. The first creation module is configured to create a counterparty session container for the counterparty terminal based on the counterparty identifier when there is no counterparty session container corresponding to the counterparty identifier; and to create a transaction session container under the counterparty session container of the counterparty terminal based on the transaction instruction identifier. The second creation module is used to determine whether there is a transaction session container corresponding to the transaction instruction identifier if there is a counterparty session container corresponding to the counterparty identifier; and to create a transaction session container under the counterparty session container of the counterparty terminal according to the transaction instruction identifier if there is no transaction session container corresponding to the transaction instruction identifier. In cases involving multiple transaction instructions, each of the multiple transaction session containers under the counterparty session container corresponds one-to-one with the transaction instruction identifier of the multiple transaction instructions.

[0110] It should be noted that the transaction session management method provided in this application embodiment can be executed by a transaction session management device, or a control module within the transaction session management device for executing the transaction session management method. This application embodiment uses the execution of a loading transaction session management method by a transaction session management device as an example to illustrate the transaction session management method provided in this application embodiment.

[0111] The transaction session management device in this application embodiment can be a device, or it can be a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. This application embodiment does not impose specific limitations.

[0112] The transaction session management device in this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system used.

[0113] The transaction session management device provided in this application embodiment can achieve... Figures 1 to 2 The various processes implemented by the transaction session management device in the method embodiment will not be described again here to avoid repetition.

[0114] Optionally, Figure 4 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. This application also provides an electronic device; it should be noted that the electronic device in this application includes the mobile electronic device and non-mobile electronic device described above.

[0115] The electronic device includes, but is not limited to, components such as: radio frequency unit, network module, audio output unit, input unit, sensor, display unit, user input unit, interface unit, memory, and processor.

[0116] Those skilled in the art will understand that electronic devices may also include power supplies (such as batteries) that supply power to various components. The power supply may be connected to the processor logic through a power management system, thereby enabling functions such as managing charging, discharging, and power consumption through the power management system. Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than shown, or combine certain components, or have different component arrangements, which will not be elaborated here. As an example, such as Figure 4As shown, the electronic device 600 includes a memory 610 and a processor 620. The memory 610 and the processor 620 are connected via a bus for communication. The memory 610 stores a computer program that can run on the processor 620 to implement the steps in the transaction session management method disclosed in the above embodiments of this application.

[0117] As the apparatus is basically similar to the method embodiment, it is described in a relatively simple way. For relevant details, please refer to the description of the method embodiment.

[0118] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0119] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects.

[0120] Furthermore, this application embodiment also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described transaction session management method embodiment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0121] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0122] This application also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described transaction session management method embodiments and achieve the same technical effect. To avoid repetition, it will not be described again here.

[0123] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0124] It should be noted that, in this document, 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 limitations, 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 that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0125] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0126] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A transaction session management method, characterized in that, The method includes: Obtain the first session content of the counterparty's terminal; Based on the counterparty identifier and transaction instruction identifier in the first session content, the first session content is stored in the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier; the transaction instruction identifier of the first session content is used to identify the transaction instruction to which the first session content is targeted. Based on the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, a second session content is generated and sent to the counterparty terminal.

2. The transaction session management method according to claim 1, characterized in that, After sending the second session content to the counterparty terminal, the process also includes: Receive third session content sent by the counterparty's terminal; Based on the counterparty identifier in the third session content, the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier are determined as the context of the third session content. Based on the content of the third session and the context of the third session, the transaction instruction identifier of the third session is determined; the transaction instruction identifier of the third session is used to identify the transaction instruction targeted by the third session. Based on the counterparty identifier and transaction instruction identifier of the third session content, the third session content is stored in the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier.

3. The transaction session management method according to claim 1, characterized in that, After storing the first session content into the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier, the method further includes: Based on the value of the transaction instructions corresponding to multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, freeze the current credit limit of the counterparty identifier; Based on the value of the current trading object of the counterparty identifier and the trading instruction identifier, a transaction-level risk control assessment is performed to obtain the transaction-level risk control assessment result of the trading instruction identifier; Based on the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, a second session content is generated, including: The second session content is generated based at least on the transaction-level risk control assessment result identified by the transaction instruction.

4. The transaction session management method according to claim 3, characterized in that, After storing the first session content into the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier, the method further includes: The current credit limit of the counterparty identifier is determined based on the total value of the multiple transaction instructions corresponding to the multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier. Based on the current credit limit of the counterparty identifier, a counterparty-level risk control assessment is performed to obtain the counterparty-level risk control assessment result of the counterparty identifier; Based on the multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, a second session content is generated, including: The second session content is generated based on the transaction-level risk control assessment result of the transaction instruction identifier and the counterparty-level risk control assessment result of the counterparty identifier.

5. The transaction session management method according to claim 1, characterized in that, The transaction instruction identifier is associated with multiple counterparty terminals; the method further includes: Receive a confirmation message from a counterparty's terminal; Based on the counterparty identifier and transaction instruction identifier in the confirmed transaction message, the confirmed transaction message is stored in the transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier; Based on the transaction instruction corresponding to the transaction session container storing the confirmed transaction message, the current credit limit of the counterparty identifier is deducted.

6. The transaction session management method according to claim 1, characterized in that, The transaction instruction identifier is associated with multiple counterparty terminals; the method further includes: Receive a confirmation message from a counterparty's terminal; Based on the counterparty identifier and transaction instruction identifier in the confirmed transaction message, a transaction termination prompt message is sent to other counterparty terminals associated with the transaction instruction corresponding to the transaction instruction, excluding the counterparty terminal. Based on the value of the transaction instruction corresponding to the other counterparty identifier and the transaction instruction identifier, the current credit limit of the other counterparty identifier is released. The other counterparty identifier is the counterparty identifier of the other counterparty terminal.

7. The transaction session management method according to any one of claims 1-6, characterized in that, After obtaining the first session content of the counterparty's terminal, it also includes: Based on the counterparty identifier in the first session content, determine whether there is a counterparty session container corresponding to the counterparty identifier; If no counterparty session container corresponding to the counterparty identifier exists, a counterparty session container for the counterparty terminal is created based on the counterparty identifier; and a transaction session container is created under the counterparty session container for the counterparty terminal based on the transaction instruction identifier. If a counterparty session container corresponding to the counterparty identifier exists, determine whether a transaction session container corresponding to the transaction instruction identifier exists. If no transaction session container corresponding to the transaction instruction identifier exists, create a transaction session container under the counterparty session container of the counterparty terminal according to the transaction instruction identifier. In cases involving multiple transaction instructions, each of the multiple transaction session containers under the counterparty session container corresponds one-to-one with the transaction instruction identifier of the multiple transaction instructions.

8. A transaction session management device, characterized in that, The device includes: The first session content acquisition module is used to acquire the first session content of the counterparty's terminal. The first session content storage module is used to store the first session content into a transaction session container corresponding to the transaction instruction identifier under the counterparty session container corresponding to the counterparty identifier, based on the counterparty identifier and transaction instruction identifier in the first session content; the transaction instruction identifier of the first session content is used to identify the transaction instruction to which the first session content is targeted. The second session content generation module is used to generate second session content based on multiple session contents stored in multiple transaction session containers under the counterparty session container corresponding to the counterparty identifier, and send the second session content to the counterparty terminal.

9. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the transaction session management method as described in any one of claims 1-7.

10. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the transaction session management method as described in any one of claims 1-7.

Images