Transaction data processing method and system based on unified transaction platform

Abstract

Embodiments of the present application provide a transaction data processing method and system based on a unified transaction platform. A business transaction request is received through a front-end interaction interface of the unified transaction platform, and identity verification is performed on the business transaction request. After the identity verification is passed, a target transaction workflow is generated based on business type information by calling a unified workflow engine. A preset permission adaptation analysis model is called to determine whether there is an uncovered authorized transaction permission. If there is an authorized transaction permission, a standardized permission application work order is generated through the permission adaptation analysis model, and the standardized permission application work order is intelligently routed to an approval node corresponding to a target business line. In the case where the approval result returned by the approval node is approval, a target business function module is loaded to perform a full-link transaction processing operation, and a transaction data processing result is generated. The method can improve the processing efficiency of transaction data processing in the bank system and reduce system resource waste.

Description

Technical Field

[0001] This application relates to the field of financial technology, and more specifically, to a method and system for processing transaction data based on a unified trading platform. Background Technology

[0002] With the rapid development of fintech and the deepening digital transformation of the banking industry, banks have developed and deployed various applications with different functions or business terminals to meet the diverse work needs of account managers in different business scenarios. In their initial stages, these applications primarily focused on specific business areas, meeting the business development needs of the corresponding departments to a certain extent. For example, some applications focused on loan development, some served retail marketing, and some targeted branch operations. However, with the continuous expansion of banking business, the ongoing changes in the market environment, and rapid technological iteration, the existing distributed architecture of these applications suffers from problems such as overlapping system functions, wasted system resources, and a chaotic user experience, resulting in low transaction data processing efficiency and high learning and operational costs for users.

[0003] Therefore, improving the processing efficiency of transaction data in the banking system and reducing the waste of system resources are urgent problems that need to be solved. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a transaction data processing method and system based on a unified transaction platform, so as to improve the processing efficiency of transaction data processing in the banking system and reduce the waste of system resources.

[0005] Firstly, this application provides a transaction data processing method based on a unified trading platform, comprising: The unified transaction platform receives business transaction requests through its front-end interactive interface. The business transaction requests include account manager identity information, customer identity information, and business type information. The business transaction request is verified based on the account manager's identity information and the customer's identity information. After the identity verification is successful, the unified workflow engine is invoked to generate a target transaction workflow based on the business type information. The target transaction workflow involves at least one business function module in at least one business line. The preset permission adaptation analysis model is invoked to perform multi-dimensional correlation and matching of the permission requirements of the target business function modules associated with the target transaction workflow, the static business processing permissions corresponding to the account manager's identity information, and the account manager's historical transaction behavior data to determine whether there are any uncovered pending authorization transaction permissions. If the pending transaction permissions exist, a standardized permission application work order is generated through the permission adaptation analysis model, and the standardized permission application work order is intelligently routed to the approval node corresponding to the target business line. The standardized permission application work order includes permission rationality reference information. If the approval result returned by the approval node is "approved", the validity period and applicable scenario restrictions of the pending transaction permission are temporarily bound to the account manager, and the target business function module is loaded to perform the full-link transaction processing operation to generate transaction data processing results.

[0006] Secondly, this application provides a transaction data processing system based on a unified trading platform. The transaction data processing system based on a unified trading platform includes a machine-readable storage medium and a processor. The machine-readable storage medium stores machine-executable instructions. When the processor executes the machine-executable instructions, the transaction data processing system based on a unified trading platform implements the aforementioned transaction data processing method based on a unified trading platform.

[0007] The transaction data processing method and system based on a unified transaction platform provided in this application receive business transaction requests containing information such as the identity of the account manager and customer, and the business type through the front-end interactive interface of the unified transaction platform. After identity verification, the system calls a unified workflow engine to generate a target transaction workflow involving multiple business line functional modules. A preset permission adaptation analysis model is invoked to match the permission requirements of the target business functional modules, the account manager's static permissions, and historical transaction behavior data from multiple dimensions to determine the transaction permissions to be authorized. If pending transaction permissions exist, a standardized permission application work order is generated and intelligently routed to the approval node. Upon approval, permissions are temporarily bound to the account manager, and the target business function module is loaded to perform full-link transaction processing operations and generate transaction data processing results. This addresses the problems of overlapping system functions, resource waste, and chaotic user experience in existing distributed architecture applications, resulting in low transaction data processing efficiency and high user learning and operation costs. This application utilizes a unified transaction platform to integrate business, accurately generates target transaction workflows through a unified workflow engine, avoids redundant function construction and resource waste, accurately matches permissions from multiple dimensions using a permission adaptation analysis model, reduces unnecessary permission application processes, intelligently routes approval nodes to improve approval efficiency, temporarily binds permissions and restricts usage time and scenarios, flexibly meets business needs while ensuring security, and performs full-link transaction processing operations to ensure transaction integrity and accuracy. This improves the processing efficiency of transaction data in the banking system, reduces system resource waste, optimizes user experience, and enhances operational management and service collaboration. Attached Figure Description

[0008] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0009] Figure 1 A flowchart illustrating a transaction data processing method based on a unified trading platform, provided as an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a transaction data processing system based on a unified trading platform, provided in an embodiment of this application.

[0010] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

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

[0012] Figure 1 This is a flowchart illustrating a transaction data processing method based on a unified trading platform, provided as an embodiment of this application. It should be understood that in other embodiments, the order of some steps in the transaction data processing method based on a unified trading platform in this embodiment can be shared according to actual needs, or some steps can be omitted or maintained. Figure 1 As shown, the method may include the following steps: Step S110: Receive business transaction requests through the front-end interactive interface of the unified transaction platform. The business transaction requests include account manager identity information, customer identity information, and business type information.

[0013] In this embodiment, the front-end interactive interface of the unified trading platform is an important window for users to interact with the system. It has user interface design and interactive functions to facilitate account managers in inputting and submitting business transaction requests. The front-end interactive interface has multiple input fields and selection boxes for entering account manager identity information, customer identity information, and selecting business type information, respectively.

[0014] For account manager identity information, this includes a unique employee ID number, login password, and mobile phone number. Customer identity information includes the customer's name, ID number, and contact information. Business type information is presented as an option list, covering various business types such as savings, wealth management, and credit.

[0015] After the account manager selects or enters the corresponding business type, the front-end interface can intelligently display additional information input fields related to the selected business type, making it easier for the account manager to further refine the business transaction request. If the information is complete and correctly formatted, the front-end interface can package the business transaction request and send it to the back-end server of the unified transaction platform for processing.

[0016] Step S120: Verify the identity of the business transaction request based on the account manager's identity information and the customer's identity information. After the identity verification is successful, call the unified workflow engine to generate the target transaction workflow based on the business type information. The target transaction workflow involves at least one business function module in at least one business line.

[0017] Step S121: Perform security authentication on the account manager's identity information. Collect the account manager's facial features using liveness detection technology, and compare the collected facial features with the pre-stored account manager identity baseline features using a face recognition algorithm to generate the account manager's identity authentication result. The account manager's identity authentication result includes identity matching parameters and a liveness detection pass flag.

[0018] During the secure authentication of the account manager's identity, the camera device associated with the unified trading platform's front-end interface is first activated. The account manager is prompted to maintain an appropriate distance and posture so that the camera can clearly capture their face. The liveness detection technology utilizes multiple methods, including motion recognition and light and shadow change analysis, to ensure that the captured facial features are from a real, living person.

[0019] Specifically, account managers can be instructed to perform actions in a specified sequence, such as blinking, opening their mouths, and nodding, while the camera continuously captures a sequence of facial images at each moment. During the capture process, dynamic changes in facial muscles and subtle differences in lighting can be analyzed in real time. For blinking, the frequency and amplitude of grayscale value changes in pixels around the eyelids can be analyzed. When a change in grayscale value within a certain time period is detected that conforms to the blinking pattern, the blinking action is considered valid. For opening the mouth, changes in the oral cavity contour can be monitored, and the completion of the mouth-opening action can be determined by calculating the rate of change of the perimeter and area of ​​the oral cavity region. For nodding, a head pose estimation algorithm can be used to determine whether the head pitch angle meets the characteristics of a nodding action based on the relative position changes of facial feature points in space.

[0020] After liveness detection is completed and the subjects are confirmed to be real, the acquired images undergo preprocessing, such as image grayscale conversion, histogram equalization, and image denoising, to improve image quality. Next, feature extraction algorithms (such as local binary pattern recognition, principal component analysis, and linear discriminant analysis) can be used to extract facial feature vectors from the preprocessed images.

[0021] The extracted facial feature vector is compared with a pre-stored baseline feature vector for customer manager identity. During the comparison, distance metrics algorithms such as Euclidean distance and cosine similarity can be used. Based on the comparison results, an identity matching parameter is calculated, reflecting the degree of similarity between the collected facial features and the pre-stored baseline features. Simultaneously, combined with the results of liveness detection, a customer manager identity authentication result containing the identity matching parameter and a liveness detection pass flag is generated.

[0022] Step S122: Based on the identity matching parameters in the account manager's identity authentication result, query the preset role permission mapping table, identify the role information corresponding to the account manager's identity information. The role information includes the business line affiliation, job level, and permission effective area. Based on the role information, load the functional interface layout and customer data view range that match the business transaction request.

[0023] In this step, the preset role-permission mapping table is a pre-built database table that stores the mapping relationship between different identity matching parameter ranges and corresponding role information. After obtaining the account manager's identity authentication result, the identity matching parameter is extracted from the result and then queried in the role-permission mapping table.

[0024] Suppose that the role permission mapping table contains multiple identity matching parameter ranges, each corresponding to different role information. For example, when the identity matching parameter is in range A, the corresponding role information is retail business line, junior account manager level, and the permission effective area is region X; when the identity matching parameter is in range B, the corresponding role information is corporate business line, intermediate account manager level, and the permission effective area is region Y.

[0025] Based on the retrieved role information, the system loads a functional interface layout that matches the business transaction request. Different business lines and job levels may have different functional modules and access permissions. For example, a junior account manager in the retail business line will primarily display retail-related modules, such as savings account opening and wealth management product recommendations, while some advanced functions will be hidden or have access restricted. Meanwhile, a mid-level account manager in the corporate business line will have a functional interface that includes modules for corporate account management and corporate loan approval.

[0026] Simultaneously, the scope of customer data views can be determined based on role information. Different permission-effective areas and job levels determine the range of customer data that account managers can view and manipulate. For example, a junior account manager working in Region X may only be able to view basic information and transaction records of some ordinary customers within that region; while a mid-level account manager working in Region Y can view detailed financial information and business transaction records of all corporate clients within that region. Based on these rules, customer data that meets the criteria can be filtered from the customer database and displayed on the functional interface.

[0027] Step S123: Perform identity verification processing on customer identity information, collect the image of the customer's ID card and the customer's real-time face image, obtain the text information of the customer's ID card through optical character recognition, and compare the features of the real-time face image of the customer with the face photo in the ID card image through face recognition technology to generate customer identity verification results. The customer identity verification results include ID card information consistency parameters and face comparison similarity parameters.

[0028] When verifying customer identity information, the account manager can first be prompted to use the image acquisition device connected to the front-end interactive interface, such as a high-resolution camera, to capture images of the customer's ID card and the customer's real-time facial image. For real-time facial image acquisition, the customer can also be asked to maintain an appropriate posture and expression to obtain a clear, frontal facial image.

[0029] After acquiring the document image, Optical Character Recognition (OCR) technology is used to process it. The OCR process includes image preprocessing, character segmentation, feature extraction, and character recognition. Image preprocessing involves operations such as grayscale conversion, binarization, and tilt correction to improve character clarity and recognizability. Character segmentation divides the text and numbers on the document into individual characters for subsequent recognition. Feature extraction extracts representative features from the segmented characters, such as stroke features and structural features. Character recognition compares the extracted feature information with a pre-trained character model to identify each character. Through OCR technology, the text information in the document image is converted into text information, which may include, for example, the customer's name, ID number, and date of birth.

[0030] Simultaneously, the collected real-time customer face images and ID document images undergo preprocessing using the same preprocessing methods employed during the facial feature extraction for customer managers. Then, facial recognition technology is used to extract feature vectors from the customer's real-time face images and ID document images, respectively. During feature extraction, deep learning algorithms (such as convolutional neural networks) are used to learn the essential features of faces through training on a large number of face images, thereby enabling the extraction of representative and discriminative feature vectors.

[0031] The extracted feature vector of the customer's real-time face image is compared with the feature vector of the face photo in the ID card image to calculate the face similarity parameter. This parameter reflects the degree of similarity between the customer's real-time face and the face in the ID card photo.

[0032] In addition, the document text information obtained through OCR technology is compared with the customer identity information entered by the account manager in the business transaction request. A string matching algorithm is used to check whether key information such as name and ID number are consistent, and a document information consistency parameter is calculated. Combining the facial similarity parameter and the document information consistency parameter, a customer identity verification result containing both parameters is generated.

[0033] Step S124: If both the account manager's identity authentication result and the customer's identity verification result are passed, the unified workflow engine is invoked based on the business type information to parse the transaction variety code and business scenario identifier in the business type information.

[0034] Once both the account manager's identity verification and the customer's identity verification results are successful, processing of business type information begins. Business type information typically exists in the form of codes and identifiers, containing key information such as transaction instrument codes and business scenario identifiers.

[0035] After receiving business type information, the unified workflow engine first parses it. During parsing, it extracts the transaction type code and business scenario identifier according to preset encoding rules and formats. For example, the transaction type code may use a certain combination of numbers or letters to represent different transaction types, such as 001 representing current deposits in savings business and 002 representing time deposits; the business scenario identifier may use a specific string to represent different business processing scenarios, such as scenario A representing online account opening business scenario and scenario B representing offline counter business scenario.

[0036] The unified workflow engine can perform a validity check on the extracted trading instrument codes and business scenario identifiers, comparing them with pre-defined trading instrument databases and business scenario databases to ensure that these codes and identifiers are valid and known. If an invalid code or identifier is found, an error message can be issued, requiring the account manager to re-enter or check the business type information.

[0037] Step S125: Based on the transaction product code and business scenario identifier, match and integrate the corresponding target business function modules in the target business line to generate the target transaction workflow. The target business line includes at least one of the following: retail business line, corporate business line, credit business line, and branch business line. The target business function modules are independently encapsulated from each other.

[0038] After parsing the trading instrument code and business scenario identifier, the system matches the corresponding target business function module in the target business line based on this information. Each business line has its own set of business function modules, which are designed according to different business needs and operational processes.

[0039] Taking the retail business line as an example, when the transaction product code is current deposit of savings business and the business scenario is identified as online account opening business scenario, functional modules related to online account opening of current deposit can be matched from the functional module set of the retail business line, such as customer information entry module, account opening module, risk assessment module, etc.

[0040] For corporate banking business lines, if the transaction product code is corporate loan business and the business scenario is offline approval business scenario, then functional modules such as corporate document review module, credit rating module, and loan amount approval module will be matched.

[0041] Each target business function module is independently encapsulated, meaning each module has its own independent inputs, outputs, and processing logic, and can run and be maintained independently. After matching the corresponding target business function modules, these modules can be integrated and combined according to a certain business process and logical sequence to generate the target transaction workflow.

[0042] For example, in the target transaction workflow for opening an online current deposit account, the account manager can first input the customer's basic information through the customer information input module, then generate the customer's bank account based on the input information through the account opening module, and finally assess the customer's risk tolerance through the risk assessment module.

[0043] Step S130: Call the preset permission adaptation analysis model to perform multi-dimensional correlation and matching of the permission requirements of the target business function modules associated with the target transaction workflow, the static business processing permissions corresponding to the account manager's identity information, and the account manager's historical transaction behavior data to determine whether there are any uncovered pending authorization transaction permissions.

[0044] Step S131: Parse the configuration files of each target business function module in the target transaction workflow to obtain business line attributes, transaction type restrictions, operation scope definitions and permission time constraints, and generate permission requirements. Business line attributes are used to identify the business line to which the function module belongs, transaction type restrictions are used to limit the types of transactions that can be executed, and operation scope definitions are used to divide customer group levels and transaction amount ranges.

[0045] In this step, each target business function module in the target transaction workflow has its corresponding configuration file. These configuration files store various attributes and parameters of the module in a specific format. The system extracts permission-related information by parsing the configuration files.

[0046] For business line attributes, the configuration file can clearly identify the business line to which the functional module belongs, such as the retail business line, corporate business line, etc. By reading the relevant fields in the configuration file, the system can accurately obtain the identification information of the business line.

[0047] Transaction type restrictions refer to the range of transaction types that this functional module is allowed to execute. The configuration file may list a series of transaction type codes or names, such as cash deposits, money transfers, and purchases of financial products. This information can be extracted to form a transaction type restriction list.

[0048] The operational scope definition is used to categorize customer groups and transaction amount ranges. The configuration file can classify customers into different groups based on their attributes, such as asset size and credit rating, and specify the corresponding transaction amount range for each group. For example, for ordinary customers, there might be a certain maximum transaction amount, while for high-net-worth customers, the maximum transaction amount is even higher. This customer group classification information and corresponding transaction amount range information are extracted from the configuration file.

[0049] Permission validity constraints refer to the time-related limitations on permissions for a given functional module. The configuration file can specify the effective and expiration times of permissions. By recording this time information, it is taken into account during subsequent permission matching. Extracted business line attributes, transaction type restrictions, operation scope definitions, and permission validity constraints are integrated to generate permission requirements.

[0050] Step S132: Query the account manager permission database, extract the default permission scope, cross-line transaction restrictions, special business authorization limits and permission effective regions corresponding to the account manager's identity information, and generate static business processing permissions. The default permission scope is pre-configured based on the account manager's role information. Cross-line transaction restrictions are used to control the cross-use of permissions between different business lines. Special business authorization limits are used to limit the processing limit of high-risk transactions.

[0051] The account manager permissions database stores the permission information for each account manager. When performing permission matching, the database can be queried based on the account manager's identity information.

[0052] The default permission scope is pre-configured based on the account manager's role information. Different roles are assigned different permission scopes upon joining the company. For example, a junior account manager in the retail banking line might have a default permission scope that only includes basic retail operations, such as opening savings accounts and selling simple financial products; while a senior account manager in the corporate banking line might have a default permission scope that includes more complex corporate banking operations, such as corporate account management and approving large loans. The default permission scope information corresponding to the account manager's role can be extracted from the database.

[0053] Cross-departmental transaction restrictions are used to control the cross-use of permissions between different business lines. In actual business operations, to ensure professionalism and standardization, restrictions are usually placed on the operations of account managers across different business lines. For example, it might be stipulated that account managers in the retail business line cannot perform large loan approval operations in corporate business. These cross-departmental transaction restriction rules are stored in the database and can be extracted for subsequent permission matching.

[0054] Special business authorization limits are processing caps set for high-risk transactions. Some special transactions, such as large-sum fund transfers and the sale of high-risk investment products, require additional authorization and control. The database can record each account manager's special business authorization limit information, such as the maximum limit for a single large-sum fund transfer.

[0055] The geographical scope of permissions refers to the geographical restrictions on an account manager's authority. For example, some account managers' permissions may only be valid in specific cities or regions. The geographical information of the effective scope of an account manager's permissions can be extracted from the database. The extracted information, including default permission range, cross-departmental transaction restrictions, special business authorization limits, and effective geographical scope, is then integrated to generate static business processing permissions.

[0056] Step S133: Obtain historical transaction behavior data of account managers within a preset time period. The historical transaction behavior data includes historical transaction records, cross-line operation frequency, compliance status of permission use, and customer complaint-related data. Historical transaction records include transaction timestamps, transaction amounts, transaction types, and transaction result status. Cross-line operation frequency is used to calculate the transaction proportion of different business lines. Compliance status of permission use is generated through the inspection results of the compliance audit system.

[0057] Historical transaction data for a client manager within a preset time period can be retrieved from the transaction data storage system. The preset time period can be set according to business needs, such as the most recent month or the most recent three months. The historical transaction records contain detailed information on all transactions conducted by the client manager within that time period. The transaction timestamp records the specific time each transaction occurred, the transaction amount records the amount of funds involved, the transaction type records the specific type of transaction (e.g., savings or wealth management), and the transaction status records whether the transaction was successful or rejected. These historical transaction records can be organized and stored according to a specific format.

[0058] Cross-business line operation frequency is used to statistically analyze the transaction proportions of account managers across different business lines. By analyzing historical transaction records, the number and amount of transactions a client manager makes in different business lines, such as retail and corporate banking, can be calculated, thus determining the transaction proportion for each business line. For example, if a client manager's transactions in the past month showed a 70% proportion of retail transactions and a 30% proportion of corporate transactions, this reflects the client manager's operational tendencies.

[0059] The compliance status of permission usage is generated based on the inspection results of the compliance audit system. This system periodically reviews the account managers' transaction behavior, checking for actions exceeding authorized limits and adherence to business process guidelines. For example, it checks whether account managers followed necessary approval procedures and operated within authorized limits when conducting certain transactions. If violations are found, the compliance audit system records the type and time of the violation and generates a corresponding violation report. Based on these compliance audit system results, the account managers' permission usage compliance can be quantified into an indicator for subsequent permission matching analysis.

[0060] Customer complaint-related data refers to customer complaint information associated with a specific account manager. This data can be obtained from the customer complaint management system, including the complaint time, content, and reason. Analyzing this data can reveal potential problems with the account manager's operations, such as poor service attitude or delayed processing. These issues may affect the account manager's access permissions and are therefore considered part of historical transaction behavior data. Integrating historical transaction records, cross-departmental operation frequency, access permission compliance, and customer complaint-related data creates a complete set of historical transaction behavior data for the account manager.

[0061] Step S134: Perform multi-dimensional correlation matching processing on the permission requirements and static business processing permission input permission adaptation analysis model to determine whether the static business processing permissions cover the permission requirements in three dimensions: business line attributes, transaction type restrictions, and operation scope definition. The multi-dimensional correlation matching processing includes: matching the business line attributes of the permission requirements with the default permission scope of the static business processing permissions in the first dimension; matching the transaction type restrictions of the permission requirements with the cross-line transaction restrictions of the static business processing permissions in the second dimension; and matching the operation scope definition of the permission requirements with the special business authorization quota of the static business processing permissions in the third dimension.

[0062] The permission adaptation analysis model is a pre-trained model used to handle permission matching problems. It can perform multi-dimensional correlation matching between input permission requirements and static business processing permissions.

[0063] In the first dimension matching, the business line attributes of the permission requirements are matched with the default permission scope of the static business processing permissions. For the business line attributes in the permission requirements, a certain identifier clarifies the business line to which the target business function module belongs. The default permission scope in the static business processing permissions is a set of operable business lines pre-configured based on the account manager role. During the matching process, the model compares the business line identifiers in the permission requirements with those in the default permission scope one by one. If the business line identifier in the permission requirements exists in the set of business lines in the default permission scope, it indicates a possibility of matching in this dimension of business line attributes; otherwise, the matching in this dimension fails. To more accurately assess the degree of matching, each business line identifier can be assigned a certain weight, for example, some core business lines have higher weights, and non-core business lines have lower weights. The degree of matching in the first dimension is quantified by calculating the sum of the weights of the matched business line identifiers.

[0064] The second dimension of matching involves matching the transaction type restrictions imposed by the permission requirements with the cross-departmental transaction restrictions of the static business processing permissions. The transaction type restrictions in the permission requirements clearly define the list of transaction types allowed to be executed by the target business function module, while the cross-departmental transaction restrictions specify the rules governing the types of transactions that account managers can perform across different business lines. The model can evaluate each transaction type in the list of transaction type restrictions based on the cross-departmental transaction restriction rules. If a transaction type falls within the allowed range, the match is successful; otherwise, the match fails. Similarly, different transaction types can be assigned different weights to reflect their importance and risk level. The matching performance of the second dimension is evaluated by summing the weights of the successfully matched transaction types.

[0065] The third dimension matching involves matching the defined operational scope of the authorization requirements with the special business authorization limits for static business processing permissions. The operational scope definition includes the customer group level and the transaction amount range, while the special business authorization limit specifies the upper limit for account managers to handle high-risk transactions. The model first compares whether the customer group level in the authorization requirements matches the customer group level applicable to the special business authorization limit. If they match, it further compares the transaction amount range with the upper limit of the special business authorization limit. If the upper limit of the transaction amount in the authorization requirements is less than or equal to the upper limit of the special business authorization limit, the matching is successful in the operational scope definition dimension; otherwise, the matching fails. During the matching process, different customer group levels and transaction amount ranges can also be weighted to comprehensively evaluate the matching effect of the third dimension.

[0066] Step S135: If there is a mismatch in any dimension, then combine the cross-line operation frequency and permission usage compliance in the historical transaction behavior data to determine whether the mismatch belongs to a temporary permission gap; When a mismatch is found in any of the three dimensions of business line attributes, transaction type restrictions, and operation scope definition, it is necessary to further determine whether these mismatches constitute temporary permission gaps. Specifically, this can be analyzed by combining cross-line operation frequency and permission usage compliance in historical transaction behavior data.

[0067] Cross-functional operation frequency reflects the account manager's operational tendencies and habits across different business lines. If a mismatch involves a lack of authority over a particular business line or transaction type, but the cross-functional operation frequency indicates that the account manager has a certain operational share in that business line or transaction type, it suggests that the account manager may have a need to expand related business. This mismatch may be due to temporary authority gaps caused by business development or temporary business needs.

[0068] The compliance status of permission usage reflects the account manager's past compliance with permission usage. If the account manager has consistently performed well in permission usage with no violations, then even if there is a mismatch now, it is more likely to be a temporary permission gap. For example, the account manager has strictly adhered to permission regulations in business operations for a period of time, but due to new business needs, they need to perform some operations beyond their current permission scope, resulting in a mismatch. This situation is likely temporary.

[0069] During the assessment process, different weighting parameters can be set for the frequency of cross-department operations and the compliance of permission usage. A comprehensive evaluation value is obtained by calculating the product of a quantitative indicator of cross-department operation frequency (such as the transaction ratio of different business lines) and its corresponding weight, and the product of a quantitative indicator of permission usage compliance (such as the reciprocal of the number of violations) and its corresponding weight. Based on a pre-set threshold, if the comprehensive evaluation value is greater than the threshold, the mismatch is determined to be a temporary permission gap; otherwise, it is not.

[0070] Step S136: If the mismatch is a temporary permission gap, then determine that the mismatch is a transaction permission to be authorized.

[0071] Once the above assessment determines that the mismatch is a temporary permission gap, it is classified as a pending authorization transaction permission. Pending authorization transaction permission means that the account manager currently does not have this permission, but based on business needs and historical behavior, it is necessary to temporarily grant them this permission.

[0072] Information regarding pending transaction permissions can be recorded and organized, including the business lines involved, transaction types, and scope of operation. This information will be used to generate standardized permission application work orders for submitting permission requests to relevant approval nodes.

[0073] Step S140: If there are pending authorization for transaction permissions, a standardized permission application work order is generated through the permission adaptation analysis model, and the standardized permission application work order is intelligently routed to the approval node corresponding to the target business line. The standardized permission application work order includes permission rationality reference information.

[0074] Once it is determined that there are pending authorizations for transactions, the permission adaptation analysis model can generate a standardized permission request ticket based on the relevant information of the pending authorizations. The standardized permission request ticket has a unified format and content requirements to ensure the standardized and accurate transmission of information.

[0075] The permission adaptation analysis model integrates detailed information about the transaction permissions to be authorized, such as business line attributes, transaction type restrictions, and operational scope definitions, into a standardized permission application form. Simultaneously, it can generate permission rationality reference information by combining historical transaction behavior data. For example, referencing the frequency of cross-departmental operations indicates that the account manager has certain operational experience and needs in the relevant business line or transaction type; referencing the compliance of permission usage shows that the account manager has a good history of permission usage and is trustworthy. Furthermore, it can incorporate customer complaint data; if customer complaints are few, this can also serve as a reference factor for permission rationality.

[0076] After generating a standardized permission request work order, the work order can be intelligently routed to the corresponding approval node based on the target business line involved in the pending authorization transaction permission. Different business lines have different approval processes and approval nodes, and the work order can be accurately sent to the appropriate approvers according to pre-set rules and routing algorithms. For example, for pending authorization transaction permissions in the retail business line, the work order will be routed to the relevant person in charge of the retail business approval department; for pending authorization transaction permissions in the corporate business line, the work order will be routed to the corporate business approval team.

[0077] Step S150: If the approval result returned by the approval node is "approved", temporarily bind the usage time and applicable scenario restrictions of the pending transaction permission to the account manager, load the target business function module to perform the full-link transaction processing operation, and generate the transaction data processing result.

[0078] Once the approval node completes the approval of the standardized permission application work order and returns an approved result, it can temporarily bind pending transaction permissions to the account manager. During the binding process, the validity period and applicable scenario restrictions of the pending transaction permissions can be clearly defined.

[0079] The validity period refers to the timeframe within which an account manager can use the pending transaction permissions. A reasonable validity period can be set based on business needs and the nature of the permissions. For example, it could be valid for a certain period, during which the account manager can use the permissions normally for business operations; after this period, the permissions will automatically expire.

[0080] The applicable scenario restriction refers to the specific business scenario to which the transaction permission to be authorized applies. For example, the permission may only be applicable to online business scenarios, or only to a specific type of customer group. This usage time and applicable scenario restriction information can be associated with the account manager's identity information to ensure that the account manager uses the permission within the specified time and scenario.

[0081] After binding the pending transaction permissions, the target business function module can be loaded to begin executing the full-chain transaction processing operation. The full-chain transaction processing operation involves the collaborative work of multiple business links and function modules. For example, in the full-chain processing of a savings account opening business, it will sequentially go through the customer information entry module, account generation module, risk assessment module, fund deposit module, etc., with each module executed in sequence according to the predetermined business process and logical order.

[0082] Throughout the entire transaction processing process, information from each business step can be recorded in real time, including transaction time, transaction amount, and transaction status. Once all business steps are completed, transaction data processing results are generated. These results include transaction success status, detailed transaction information, and relevant business documents. The transaction data processing results can be fed back to account managers and clients, and the data can be stored and backed up for future retrieval and auditing.

[0083] Step S210: When a new business transaction request belonging to the same customer as the business transaction request is received, determine whether the business types of the new business transaction request and the business transaction request both belong to the target business type based on the new business type information included in the new business transaction request.

[0084] When the unified transaction platform receives a new business transaction request from the same customer as a previous business transaction request, it analyzes the new business type information in the new business transaction request. The target business type is a pre-defined set of business types, which may include specific business type categories such as savings, wealth management, and credit.

[0085] The system can compare new business type information with business type information from previous business transaction requests to determine if they both belong to one or more categories within the target business type. For example, if the target business types are set as savings and wealth management, and the new business type information shows a fixed deposit (belonging to savings), while the previous business transaction request indicated a wealth management product purchase (belonging to wealth management), then both of these business types belong to the target business type. In this process, the business type information can be standardized, uniformly classifying and matching business types with different descriptions but identical essence to ensure accurate determination of whether a business type belongs to the target business type.

[0086] Step S220: If so, and the time difference between the new business transaction request and the business transaction request is within the preset time window, then there is no need to verify the customer's identity information before executing the transaction operation corresponding to the new business transaction request.

[0087] If it is confirmed that both the new business transaction request and the existing business transaction request belong to the target business type, and the time difference between these two business transaction requests is within a preset time window, then the system considers the customer's identity to be relatively stable during this period, and no further identity verification is required. The preset time window is a time period set based on a comprehensive consideration of business security and convenience; for example, it may be set to several hours or a day.

[0088] In this scenario, the target business function module corresponding to the new business transaction request can be directly loaded, and the corresponding transaction operation can be executed. For example, if the new business transaction request is a customer's second purchase of a wealth management product within a day, and the identity verification for the first purchase has already been passed, then the second purchase of a wealth management product can be processed directly based on the customer's previously entered information, skipping the identity verification step and improving business processing efficiency.

[0089] Step S230: If no, or if the business types of the new business transaction request and the business transaction request both belong to the target business type and the time difference between the new business transaction request and the business transaction request is outside the preset time window, then the identity verification operation of the customer's identity information is triggered.

[0090] If the business types of the new business transaction request and the business transaction request do not both belong to the target business type, or if the business types both belong to the target business type but the time difference exceeds the preset time window, the identity verification operation of the customer's identity information can be triggered.

[0091] The identity verification process is the same as the process described in step S123 for verifying customer identity information. The system can re-capture the image of the customer's ID card and the customer's real-time facial image. Text information from the ID card is obtained through optical character recognition (OCR), and facial recognition technology is used to compare the features of the customer's real-time facial image with the facial photograph in the ID card image, generating a new customer identity verification result. Only when the new customer identity verification result is successful will the transaction operation corresponding to the new business transaction request be executed.

[0092] Step S310: When there is a need for counter collaboration in the end-to-end transaction processing operation, push the counter collaboration request to the terminal of the authorized counter personnel.

[0093] During the end-to-end transaction processing, there may be situations where the participation of authorized counter personnel is required, such as certain high-risk businesses or large transactions. In these cases, there is a need for counter collaboration. When the system detects such a need for counter collaboration, it will push a counter collaboration request to the terminal of the authorized counter personnel.

[0094] The counter collaboration request includes relevant transaction information, such as transaction type, transaction amount, and customer information, so that authorized counter personnel can understand the specific details of the transaction. The request can be sent to the message receiving module of the authorized counter personnel's terminal via an internal push notification mechanism. The authorized counter personnel's terminal can be a dedicated counter operation device or a mobile terminal with a specific application installed.

[0095] Step S320: Share the target interface to be collaboratively processed at the counter to the authorized personnel terminal and the front-end interactive interface. The target interface includes at least one of the following: transaction view, customer information, and business image data.

[0096] After pushing a counter collaboration request to the authorized personnel's terminal, the target interface to be processed by the counter collaboration can be shared. The target interface contains important information related to the transaction, such as the transaction view which can display the detailed process and status of the transaction, customer information including the customer's basic information, historical transaction records, etc., and business image data which may include photos of the documents submitted by the customer, contract documents, etc.

[0097] Network transmission technology can be used to synchronize the content of the target interface to the authorized personnel's terminal and the front-end interactive interface in real time. Authorized personnel and account managers can simultaneously view the information on the target interface on their respective terminals, facilitating collaborative processing and communication.

[0098] Step S330: In response to the verification result received from the authorized personnel terminal at the counter, indicating that the verification has been approved, continue to execute the full-chain transaction processing operation.

[0099] Once the authorized personnel at the counter have reviewed the information on the target interface on the terminal, if the review is successful, they will send a notification to the system indicating that the review has been approved. After receiving the review result, the system will continue to execute the entire transaction processing operation.

[0100] Based on the approved information, the transaction status and related business processes can be updated. For example, if a large fund transfer is approved, the fund transfer operation can proceed, transferring funds from the customer's account to the designated target account, and the transaction completion information can be recorded. Simultaneously, the approved information and transaction processing result can be fed back to the account manager and customer, informing them that the transaction has been successfully processed.

[0101] Step S410: Collect user behavior data in the entire transaction processing operation by embedding points in the front-end framework of the unified trading platform. The user behavior data includes at least one of the following: dwell time on function pages, triggering behavior of function controls, workflow breakpoints, and search behavior.

[0102] Multiple tracking points are pre-set in the front-end framework of the unified trading platform. These points are key locations for monitoring and collecting user behavior data. During the entire transaction processing operation, relevant user behavior data can be collected through these tracking points when users interact with the platform.

[0103] To determine the duration of time a user spends on a feature page, a timestamp can be recorded when the user enters and leaves each feature page. By calculating the difference between the two timestamps, the duration of the user's stay on that feature page can be obtained. For example, when a user enters a financial product introduction page, the system records the entry time; when the user leaves the page, it records the exit time. Subtracting the two times gives the duration of the user's stay on the financial product introduction page.

[0104] The triggering behavior of functional controls refers to the user's actions on various functional controls on the platform, such as clicking buttons or selecting dropdown lists. When a user triggers a functional control, the event tracking point records the control's identification information and the trigger time. It can also record the context information at the time of triggering, such as the current page and the user's operation steps.

[0105] A workflow breakpoint refers to the point in the end-to-end transaction processing workflow where a user stops operating or an anomaly occurs. The specific location of the workflow breakpoint and related business status information can be recorded. For example, in a savings account opening workflow, if a user stops operating while filling in customer information, the system can record the identifier of that step and some of the information entered by the user.

[0106] Search behavior refers to information related to users' use of the search function on the platform, including search keywords, search time, and search results. It can record user-entered search keywords and analyze the degree to which search results match user needs. This collected user behavior data will be organized and stored for subsequent analysis and processing.

[0107] Step S420: Obtain user suggestions from the user feedback channel.

[0108] The unified trading platform has set up multiple user feedback channels, such as online customer service, feedback forms, and complaint email addresses, through which users can provide suggestions to the platform. User suggestions can be collected periodically from these channels.

[0109] For online customer service channels, the chat logs between customer service representatives and users can be filtered and extracted, and user suggestions can be organized. For feedback forms, the content filled in by users can be directly obtained, and its format can be converted and preprocessed so that it can be recognized and processed by subsequent analysis modules. For complaint emails, received emails can be categorized and parsed to extract the suggestion information.

[0110] After obtaining user suggestions, these suggestions undergo initial cleaning and filtering to remove invalid, duplicate, and irrelevant information. For example, simple complaints without substantive advice are filtered out, and typos are corrected and wording is standardized to improve the quality and analyzability of the suggestions. The cleaned and filtered user suggestions are then stored in a dedicated database for further in-depth analysis and utilization.

[0111] Step S430: Input user behavior data and user suggestion information into the pre-built platform function optimization model to obtain the function optimization suggestions output by the platform function optimization model.

[0112] Step S431: Standardize the user behavior data by converting the dwell time of functional pages, the triggering behavior of functional controls, workflow breakpoints, and search behavior into a unified format of behavior feature sequences. The behavior feature sequences include timestamps, behavior type identifiers, associated functional module identifiers, and behavior duration.

[0113] Since user behavior data contains various types of information, such as the duration of stay on functional pages and the behavior triggered by functional controls, their formats and meanings are different. In order to facilitate model processing, they need to be standardized.

[0114] For the duration of stay on a functional page, the timestamps of entering and leaving the page can be recorded. The difference between these two timestamps can be used as the duration of the behavior. The page identifier can be used as the identifier of the associated functional module, and "stay on functional page" can be used as the behavior type identifier. This will construct a behavioral feature record that includes timestamps, behavior type identifiers, associated functional module identifiers, and duration of behavior.

[0115] For the triggering behavior of functional controls, when the user triggers the control, the timestamp of the trigger, the identifier of the functional module to which the control belongs, and the identifier of the behavior type of the control trigger are recorded. A rough duration of the behavior can be estimated based on the operation flow of the control, and this information is combined into a behavior feature record.

[0116] For workflow breakpoints, record the timestamp of the breakpoint occurrence, the functional module identifier of the workflow, and the behavior type identifier of the "workflow breakpoint". At the same time, estimate the duration of the behavior based on the business processes before and after the breakpoint to form corresponding behavior feature records.

[0117] For search behavior, record the timestamp of the search initiation, the identifier of the functional module associated with the search function, the behavior type identifier of "search behavior", and the duration of the behavior from the start of the search to obtaining the result or ending the search, and construct a behavior feature record.

[0118] The behavioral feature records generated from all these different types of user behavior are arranged in chronological order to form a behavioral feature sequence in a unified format.

[0119] Step S432: Perform text structuring processing on user suggestion information, extract suggestion type classification, functional module direction, problem description content, and expected optimization direction, and generate structured suggestion feature vector.

[0120] Specifically, suggestions can be categorized by type. Common suggestion categories include functional defect suggestions, process optimization suggestions, experience improvement suggestions, and new feature suggestions. Text mining and classification algorithms can be used to perform semantic analysis on user suggestions to determine the type of each suggestion. For example, if a user points out that a function is not working properly, then the suggestion belongs to the functional defect category; if a user suggests improving a business process, then it belongs to the process optimization category.

[0121] Next, identify the functional module the suggestion pertains to. By analyzing the relevant business operations and interface elements mentioned in the suggestion text, the specific functional module involved in the suggestion is identified. For example, if a user suggests improving the operation process of the financial product purchase page, then the functional module involved is the financial product purchase module. Then, extract the problem description. Parse the suggestion text to extract key information about the problem described by the user, such as the form of the problem and the conditions under which it occurs. For example, if a user describes "when performing a transfer operation, the page does not respond after entering the amount," this is represented as the problem description.

[0122] Finally, summarize the expected directions for optimization. Summarize the improvements users expect from their suggestions, such as increasing operational efficiency and enhancing interface user-friendliness.

[0123] The extracted suggestion type classification, functional module orientation, problem description content, and expected optimization direction are encoded to form a structured suggestion feature vector, which represents this information in the form of numbers or symbols, making it easier for the model to calculate and process.

[0124] Step S433: Input the behavioral feature sequence into the feature extraction module to mine behavioral patterns, identify high-frequency triggering behavioral sequences, abnormal workflow breakpoint distribution, and abnormal intervals of dwell time on functional pages, and generate a behavioral pattern feature set.

[0125] Specifically, when mining high-frequency triggering behavior sequences, a sliding window algorithm can be used to scan the behavior feature sequences. A window of appropriate size is defined, and the window is slid across the behavior feature sequence sequentially, counting the combinations of different behavior types within each window and their frequency of occurrence. Behavior type combinations that occur frequently are identified as high-frequency triggering behavior sequences.

[0126] To identify abnormal workflow breakpoint distribution, we can analyze the location and frequency of workflow breakpoints in the behavioral feature sequence. Then, by comparing the current workflow breakpoint distribution with a reference model of normal workflow breakpoint distribution pre-built based on historical data or business rules, we can identify these locations as abnormal workflow breakpoints.

[0127] When identifying abnormal intervals in dwell time on functional pages, first calculate the statistical characteristics of dwell time for each functional page, such as the mean and standard deviation. Based on these statistical characteristics, define a normal time interval range. For values ​​in the behavioral characteristic sequence where the dwell time on a functional page does not fall within this normal range, the interval containing that value is identified as an abnormal interval. For example, if the normal dwell time mean for a certain functional page is 10 minutes and the standard deviation is 2 minutes, then intervals with dwell times less than 6 minutes or greater than 14 minutes can be considered abnormal intervals.

[0128] The identified high-frequency triggering behavior sequences, abnormal workflow breakpoint distributions, and abnormal intervals of dwell time on function pages are organized and encoded to generate a set of behavior pattern features. The set of pattern features includes information such as behavior frequency features, behavior path features, and behavior time consumption features, providing a foundation for subsequent analysis.

[0129] Step S434: Input the structured suggestion feature vector into the semantic analysis module for sentiment analysis and topic extraction, identify the core demands and sentiments in user suggestions, and generate a set of suggestion topic features.

[0130] The semantic analysis module can use natural language processing techniques to analyze user suggestion information represented by structured suggestion feature vectors.

[0131] In sentiment analysis, text classification algorithms can be used to determine the sentiment of user suggestion text. For example, a pre-trained sentiment classification model can be used, trained on a large amount of text data with sentiment labels, to identify whether the text is positive, negative, or neutral. For instance, if a user suggestion expresses anticipation and appreciation for a new feature, the sentiment is positive; if a user complains about a feature having serious problems that affect the user experience, the sentiment is negative.

[0132] In terms of topic extraction, core appeals can be extracted from user suggestion texts through keyword extraction and topic modeling algorithms. The importance of each word in the suggestion text can be calculated using the Term Frequency-Inverse Document Frequency (TF-IDF) algorithm, selecting words with higher importance as keywords. Then, topic modeling algorithms such as Latent Dirichlet Distribution (LDA) are used to cluster the keywords into different topics, thereby identifying the core topic of the user suggestions.

[0133] The identified core demands and sentiment tendencies are encoded to generate a set of suggestion theme features. This set includes theme keyword features, sentiment polarity features, and suggestion urgency features. The suggestion urgency feature can be comprehensively judged based on sentiment tendency and the severity of the problem description. For example, suggestions with negative sentiment and problems that directly affect business operations have relatively high urgency.

[0134] Step S435: Perform feature association processing on the behavioral pattern feature set and the suggestion topic feature set, and establish a behavior-suggestion association matrix by calculating the co-occurrence frequency of behavioral features and suggestion features.

[0135] Specifically, when calculating the co-occurrence frequency of behavioral features and suggestion features, each behavioral feature in the behavioral pattern feature set and each suggestion feature in the suggestion topic feature set are traversed, and the number of times they appear simultaneously is counted. For example, the number of times a certain behavior type in a high-frequency triggered behavior sequence and a certain topic keyword in the suggestion topic feature set appear simultaneously in the behavioral data and suggestion information of the same user is counted.

[0136] Based on the calculated co-occurrence frequencies, a behavior-suggestion association matrix is ​​constructed. The rows of the suggestion association matrix represent behavioral features, and the columns represent suggestion features. Each element in the matrix represents the co-occurrence frequency of the corresponding behavioral and suggestion features. The suggestion association matrix provides a clear visual representation of the strength of the association between different behavioral patterns and suggestion topics, offering a basis for subsequent feature fusion.

[0137] Step S436: Input the behavior and suggestion association matrix into the feature fusion layer of the platform function optimization model, and dynamically adjust the fusion weights of behavior pattern features and suggestion topic features through the attention mechanism to generate a comprehensive optimized feature vector.

[0138] The feature fusion layer is a crucial part of the platform's functional optimization model, enabling the fusion of behavioral pattern features and suggested topic features. In this layer, an attention mechanism can be used to dynamically adjust the fusion weights.

[0139] The basic idea of ​​the attention mechanism is to assign different weights to different behavioral and suggestion features based on the correlation strength in the behavior-suggestion association matrix. Specifically, the behavior-suggestion association matrix is ​​first normalized, converting the elements into a range of weight values. Then, the contribution of each behavioral and suggestion feature to the final optimization decision is calculated based on these weight values.

[0140] For each combination of behavioral and suggestion features, an attention score is mapped to it using a non-linear mapping function. This attention score represents the importance of the combination in the feature fusion process. The attention scores are then normalized to obtain the weights for each combination.

[0141] These weights are used to weight and fuse the behavioral pattern feature set and the suggestion topic feature set. The weighted features are then concatenated to generate a comprehensive optimized feature vector. This comprehensive optimized feature vector integrates information from user behavior and suggestions, and more comprehensively reflects the direction of platform function optimization.

[0142] Step S437: The comprehensive optimization feature vector is processed in parallel through the multi-task learning layer of the platform function optimization model to predict the optimization priority of functional modules, workflow path adjustment schemes, and improvement directions of user interaction, and generate a preliminary set of optimization suggestions.

[0143] The multi-task learning layer of the platform function optimization model uses multiple sub-models to process and comprehensively optimize feature vectors in parallel in order to achieve different prediction tasks.

[0144] For predicting the optimization priority of functional modules, a classification sub-model can be used. The classification sub-model takes the comprehensive optimization feature vector as input, performs feature transformation and classification through a series of neural network layers, and outputs an optimization priority score for each functional module. A higher score indicates a greater urgency for optimization of the functional module.

[0145] For predicting workflow path adjustment schemes, a sequence prediction sub-model can be used. This sub-model learns to integrate behavioral path features and user suggestion information from the optimized feature vector, predicting adjustment schemes that can improve workflow efficiency and user experience. For example, it can predict which steps in a business process can be merged and which steps need to be rearranged.

[0146] To predict areas for improvement in user interaction, regression sub-models can be used. These models analyze and integrate information such as behavioral time consumption and sentiment polarity features from the feature vectors to predict specific areas for improvement in the user interface and workflow, such as enhancing the interface's visual appeal and simplifying operation steps.

[0147] The outputs of these three prediction tasks are compiled to generate a preliminary set of optimization suggestions. This set includes information such as the priority ranking of functional module optimizations, specific plans for adjusting workflow paths, and general directions for improving user interaction.

[0148] Step S438: Perform conflict detection and priority ranking on the preliminary set of optimization suggestions, eliminate functional conflicts between different suggestions, and determine the optimization priority sequence based on the urgency characteristics and the scope of influence of the suggestions.

[0149] Specifically, during conflict detection, the content of each suggestion in the initial optimization suggestion set can be analyzed. Conflicting suggestion pairs can be identified through business rules and logical judgments. For conflicting suggestions, adjustments can be made based on their importance and feasibility. For example, if improving security is a core business requirement, some operational efficiency can be sacrificed to prioritize suggestions that improve security.

[0150] Regarding priority ranking, it can be determined based on the urgency feature in the suggestion topic feature set and the scope of behavioral influence in the behavioral pattern feature set. Suggestions with higher urgency and a larger scope of behavioral influence can be assigned higher optimization priority. Specifically, a comprehensive evaluation function can be established, taking the suggestion urgency and scope of behavioral influence as input parameters, calculating a comprehensive score for each suggestion, and ranking the suggestions according to the scores to form an optimization priority sequence.

[0151] Step S439: Generate functional optimization suggestions based on the optimization priority sequence, including suggestions for adjusting functional modules, optimizing workflow paths, improving user interaction design, and developing new features.

[0152] Based on the optimization priority sequence, the suggestions in the preliminary optimization suggestion set are integrated and refined according to priority to generate the final functional optimization suggestions.

[0153] For suggestions on functional module adjustments, the specific adjustments required for each functional module should be further clarified according to the optimization priority of the functional modules, such as adding, deleting or modifying certain functional sub-modules, and adjusting the permission configuration of functional modules.

[0154] For workflow path optimization suggestions, based on the predicted results of the workflow path adjustment plan, describe in detail the adjustment methods for each workflow step, including merging, splitting, and reordering steps, to ensure that the workflow is more efficient and smoother.

[0155] For suggestions on improving user interaction design, based on the predicted direction of user interaction improvement, specific interface design improvement solutions are proposed, such as adjusting the interface layout, optimizing the design of interactive controls, and adding prompts, in order to improve the user's operating experience.

[0156] For suggestions on new feature development, based on user needs and business development direction, propose requirements specifications and development plans for the new features, including the main functionalities and integration methods with existing systems. Integrate these suggestions to form a comprehensive and detailed feature optimization proposal, providing strong guidance for the functional improvement of the unified trading platform.

[0157] Step S510: Receive the download notification of the offline update package pushed by the application update server. The download notification includes the update package version identifier, update content summary, and download address information.

[0158] The unified trading platform and the application update server can maintain a connection. The application update server can periodically check the platform's update status and push download notifications to the unified trading platform when new offline update packages are available for download.

[0159] The update package version identifier in the download notification is a string or number used to uniquely identify the update package, allowing you to determine which historical version of the platform the update package is updating. The update summary briefly describes the main updates included in the update package, such as feature improvements, bug fixes, and performance optimizations, giving the platform a general understanding of the update. The download link is a link to the application update server where the update package is stored; you can download the update package from the server using this link.

[0160] Upon receiving a download notification, the unified trading platform can check its legitimacy and completeness. This includes verifying that the sender is a legitimate application update server and that the information in the notification is complete and without omissions. If the notification passes verification, the platform will store the relevant information in its local database for subsequent processing.

[0161] Step S520: Download the offline update package from the application update server to the preset local cache directory according to the download address information.

[0162] After confirming that the download notification is legitimate and valid, the unified trading platform can download the offline update package from the application update server based on the download address information.

[0163] Specifically, the platform can call a network request interface to send a download request to the download address. During the download process, the download progress can be monitored in real time, and feedback can be sent to the user or system administrator to keep them informed of the download status.

[0164] Optionally, to ensure download stability and speed, multi-threaded download technology can be used. The update package is divided into multiple data blocks, each thread is responsible for downloading one data block, multiple threads download simultaneously, and finally the downloaded data blocks are merged into a complete update package.

[0165] Downloaded update packages are stored in a pre-defined local cache directory. This local cache directory is a specific area pre-allocated within the platform's storage system for temporarily storing downloaded update packages. During storage, a unique identifier can be added to each update package for easier management and retrieval later. Information such as the update package's download time and status can also be recorded.

[0166] Step S530: After the offline update package passes the integrity verification, parse the offline update package to obtain the module identifier, module version number, and module file set of the functional module to be updated, and generate a module update list.

[0167] To ensure that downloaded offline update packages are not corrupted or tampered with, integrity verification can be performed using hash algorithms (such as MD5, SHA-256, etc.). When the application update server generates the update package, it can calculate the hash value of the update package and include it in the download notification or store it in the server's database. After the unified trading platform completes the download, it can recalculate the hash value of the update package and compare it with the hash value provided by the server. If the two hash values ​​are the same, it means that the integrity of the update package is guaranteed; if they are different, it means that the update package may have been corrupted during the download process and needs to be downloaded again.

[0168] After the offline update package passes integrity verification, the unified trading platform parses it. The offline update package can be stored in a compressed format, and the unified trading platform can decompress it using a suitable decompression algorithm. The decompressed file contains relevant information about the functional modules to be updated.

[0169] By parsing the metadata file in the update package, the module identifier, module version number, and module file set of the functional modules to be updated are extracted. The module identifier is a string or number used to uniquely identify the functional module, allowing the platform to determine which functional module needs updating. The module version number indicates the version information of the functional module after the update, and can be compared with the current version number of the same functional module on the platform to determine whether an update is necessary. The module file set is a collection of all files required to update the functional module, including code files, configuration files, etc.

[0170] The extracted module identifiers, module version numbers, and module file sets are organized to generate a module update list. This list details the update information for each module to be updated, providing clear guidance for subsequent update operations.

[0171] Step S540: Based on the module update list, suspend the currently running modules associated with the unified trading platform and release the system resources occupied by the currently running modules.

[0172] After receiving the updated module list, the unified trading platform can pause the associated currently running modules based on the information in the list. Specifically, it can use the system's process management mechanism to find the running module processes that correspond to the module identifiers in the list. For each matching process, a pause command is sent, requiring the process to stop its current operation and enter a paused state.

[0173] While pausing a module's process, you can release the system resources it occupies. These system resources may include memory, CPU time, and network connections. For memory resources, the operating system's memory management mechanism can be used to release the memory space occupied by the module and return it to the system memory pool for other processes to use. For CPU time, you can stop allocating CPU time slices to the module, preventing it from consuming CPU resources. For network connections, you can close the network connections associated with the module, releasing network bandwidth resources.

[0174] To ensure the smooth execution of pause and resource release operations, a series of status checks and error handling can be performed. For example, after sending a pause command, the status of the module process can be checked periodically to confirm whether it has successfully entered the paused state. If the module process fails to pause successfully within a certain time, the pause command will be resent, or other measures, such as forcibly terminating the process, will be taken. When releasing system resources, it can be checked whether the resources have been released correctly to avoid resource leaks. If an abnormal resource release is detected, error information can be logged, and a resource reclamation operation can be attempted.

[0175] Step S550: Load the module file set to replace or add to the storage path of the functional module to be updated, update the module dependency configuration file of the functional module to be updated, and obtain the updated functional module.

[0176] Specifically, based on the storage paths of the functional modules to be updated recorded in the module update list, files from the module file collection can be loaded into the corresponding storage locations. For files that need to be replaced, the original files can be backed up first, and then the new files can overwrite the original files. During the overwrite process, the integrity and correctness of the files will be ensured, and the format and content of the files will be checked to ensure they meet the requirements. For files that need to be added, they can be directly copied to the specified storage path.

[0177] After replacing or adding files, you can update the module dependency configuration file for the module to be updated. The module dependency configuration file records the dependencies between this module and other modules, including information such as the names and version numbers of the dependent modules. When updating the configuration file, you can modify the relevant content based on the information in the module file set. For example, if a new module introduces a new dependent module, you can add the corresponding dependency in the configuration file; if the version of a dependent module changes, you can update the corresponding version number in the configuration file.

[0178] Through the above operations, the updated functional module is finally obtained. The updated functional module includes new functions and improvements, and its dependencies have also been updated correctly.

[0179] Step S560: Restart the updated functional module and generate a module startup status report. If the module startup status report indicates normal operation, delete the offline update package in the local cache directory and record the update log.

[0180] After updating the functional modules, they need to be restarted to ensure proper operation. This restart can be achieved through the system's process management mechanism; specifically, a startup command can be sent to the process of the updated functional module to restart its execution.

[0181] During the restart process, the module's startup status can be monitored in real time. For example, it can check whether the module can successfully load the required resources, establish the necessary network connections, and process business requests normally. Simultaneously, it can record various information during the module startup process, such as startup time, loaded resource information, and error messages.

[0182] Based on the monitored information, a module startup status report is generated. The report includes detailed information about the module startup process, such as whether the startup was successful, any problems encountered during startup, and their resolution. The report can be stored in text or log format for easy viewing and analysis later.

[0183] If the module startup status report indicates normal operation, the functional module update was successful. At this point, the offline update package can be deleted from the local cache directory. Deleting the offline update package frees up local storage space, preventing excessive disk space consumption. Simultaneously, an update log can be recorded, containing information such as the update time, the name of the updated functional module, and a summary of the updated content. The update log can be used for subsequent auditing and tracking, facilitating an understanding of the platform's update history and maintenance status.

[0184] If the module startup status report indicates an anomaly, appropriate measures can be taken based on the type and severity of the anomaly. For minor anomalies, such as a configuration file failing to load, you can try reloading the configuration file or performing some simple repair operations. For severe anomalies, such as a module failing to start or a system crash, it may be necessary to roll back to the state before the update, restoring the original functional modules and configuration files. During the anomaly handling process, detailed anomaly information and handling procedures will be recorded for subsequent analysis and improvement.

[0185] The method provided in this application involves receiving a business transaction request containing information about the account manager and customer identities and business types through the front-end interactive interface of a unified transaction platform. After verifying the identity, the method invokes a unified workflow engine to generate a target transaction workflow involving multiple business line functional modules. A preset permission adaptation analysis model is then invoked to match the permission requirements of the target business functional modules, the account manager's static permissions, and historical transaction behavior data from multiple dimensions to determine the transaction permissions to be authorized. If pending transaction permissions exist, a standardized permission application work order is generated and intelligently routed to the approval node. Upon approval, permissions are temporarily bound to the account manager, and the target business function module is loaded to perform full-link transaction processing operations and generate transaction data processing results. This addresses the problems of overlapping system functions, resource waste, and chaotic user experience in existing distributed architecture applications, resulting in low transaction data processing efficiency and high user learning and operation costs. This application utilizes a unified transaction platform to integrate business, accurately generates target transaction workflows through a unified workflow engine, avoids redundant function construction and resource waste, accurately matches permissions from multiple dimensions using a permission adaptation analysis model, reduces unnecessary permission application processes, intelligently routes approval nodes to improve approval efficiency, temporarily binds permissions and restricts usage time and scenarios, flexibly meets business needs while ensuring security, and performs full-link transaction processing operations to ensure transaction integrity and accuracy. This improves the processing efficiency of transaction data in the banking system, reduces system resource waste, optimizes user experience, and enhances operational management and service collaboration.

[0186] Figure 2 This is a schematic diagram of the structure of a transaction data processing system 100 based on a unified trading platform, provided as an embodiment of this application. Figure 2 As shown, the processor 120 can be used on the transaction data processing system 100 based on a unified trading platform and to perform the functions in this invention.

[0187] The transaction data processing system 100 based on a unified trading platform can be a general-purpose server or a special-purpose server; both can be used to implement the transaction data processing method based on a unified trading platform of the present invention. Although only one server is shown in this invention, for convenience, the functions described in this invention can be implemented in a distributed manner on multiple similar platforms to balance the processing load.

[0188] For example, a unified trading platform-based trading data processing system 100 may include a network port 110 connected to a network, one or more processors 120 for executing program instructions, a communication bus 130, and various forms of storage media 140, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the unified trading platform-based trading data processing system 100 may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The method of the present invention can be implemented according to these program instructions. The unified trading platform-based trading data processing system 100 also includes an input / output (I / O) interface 150 between the computer and other input / output devices.

[0189] For ease of explanation, only one processor is described in the transaction data processing system 100 based on a unified trading platform. However, it should be noted that the transaction data processing system 100 based on a unified trading platform in this invention may also include multiple processors. Therefore, the steps executed by one processor described in this invention may also be executed jointly or individually by multiple processors. For example, if the processor of the transaction data processing system 100 based on a unified trading platform executes steps A and B, it should be understood that steps A and B may also be executed jointly by two different processors or individually by one processor. For example, the first processor executes step A, the second processor executes step B, or the first processor and the second processor jointly execute steps A and B.

[0190] The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any inventive effort.

[0191] Finally, it should be noted that the above-disclosed embodiments are merely preferred embodiments of the present invention and are only used to illustrate the technical solutions of the present invention, not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for processing transaction data based on a unified trading platform, characterized in that, include: The business transaction request is received through the front-end interactive interface of the unified transaction platform. The business transaction request includes account manager identity information, customer identity information, and business type information. The business transaction request is verified based on the account manager's identity information and the customer's identity information. After the identity verification is successful, the unified workflow engine is invoked to generate a target transaction workflow based on the business type information. The target transaction workflow involves at least one business function module in at least one business line. The preset permission adaptation analysis model is invoked to perform multi-dimensional correlation and matching of the permission requirements of the target business function modules associated with the target transaction workflow, the static business processing permissions corresponding to the account manager's identity information, and the account manager's historical transaction behavior data to determine whether there are any uncovered pending authorization transaction permissions. If the pending transaction permissions exist, a standardized permission application work order is generated through the permission adaptation analysis model, and the standardized permission application work order is intelligently routed to the approval node corresponding to the target business line. The standardized permission application work order includes permission rationality reference information. If the approval result returned by the approval node is "approved", the validity period and applicable scenario restrictions of the pending transaction permission are temporarily bound to the account manager, and the target business function module is loaded to perform the full-link transaction processing operation to generate transaction data processing results.

2. The transaction data processing method based on a unified trading platform according to claim 1, characterized in that, The step of verifying the identity of the business transaction request based on the account manager's identity information and the customer's identity information, and then, after the identity verification is successful, invoking the unified workflow engine to generate a target transaction workflow based on the business type information, includes: The account manager's identity information is subjected to security authentication processing. The facial features of the account manager are collected through liveness detection technology, and the collected facial features are compared with the pre-stored account manager identity benchmark features in combination with a face recognition algorithm to generate an account manager identity authentication result. The account manager identity authentication result includes an identity matching degree parameter and a liveness detection pass identifier. Based on the identity matching parameters in the customer manager's identity authentication result, a preset role permission mapping table is queried to identify the role information corresponding to the customer manager's identity information. The role information includes business line affiliation, job level and permission effective area. Based on the role information, a functional interface layout and customer data view range that match the business transaction request are loaded. The customer identity information is processed for identity verification. The process involves collecting an image of the customer's ID card and a real-time facial image of the customer. The text information of the customer's ID card is obtained through optical character recognition. The real-time facial image of the customer is compared with the facial photo in the ID card image using facial recognition technology to generate a customer identity verification result. The customer identity verification result includes a document information consistency parameter and a facial comparison similarity parameter. If both the account manager's identity authentication result and the customer's identity verification result are passed, the unified workflow engine is invoked based on the business type information to parse the transaction variety code and business scenario identifier in the business type information. Based on the transaction variety code and business scenario identifier, the corresponding target business function modules in the target business line are matched and integrated to generate the target transaction workflow. The target business line includes at least one of the following: retail business line, corporate business line, credit business line, and branch business line. The target business function modules are independently encapsulated from each other.

3. The transaction data processing method based on a unified trading platform according to claim 1, characterized in that, The invocation of the preset permission adaptation analysis model performs multi-dimensional correlation and matching of the permission requirements of the target business function modules associated with the target transaction workflow, the static business processing permissions corresponding to the account manager's identity information, and the account manager's historical transaction behavior data to determine whether there are any uncovered pending authorization transaction permissions, including: The configuration files of each target business function module in the target transaction workflow are parsed to obtain business line attributes, transaction type restrictions, operation scope definitions and permission time constraints, and the permission requirements are generated. The business line attributes are used to identify the business line to which the function module belongs, the transaction type restrictions are used to limit the types of transactions that can be executed, and the operation scope definitions are used to divide customer group levels and transaction amount ranges. The system queries the customer manager permission database to extract the default permission scope, cross-line transaction restrictions, special business authorization limits, and permission effective regions corresponding to the customer manager's identity information. It then generates the static business processing permissions. The default permission scope is pre-configured based on the customer manager's role information. The cross-line transaction restrictions are used to control the cross-use of permissions between different business lines. The special business authorization limits are used to limit the processing upper limit of high-risk transactions. Acquire historical transaction behavior data of the account manager within a preset time period. The historical transaction behavior data includes historical transaction records, cross-line operation frequency, compliance status of permission use, and customer complaint-related data. The historical transaction records include transaction timestamps, transaction amounts, transaction types, and transaction result status. The cross-line operation frequency is used to statistically analyze the transaction proportion of different business lines. The compliance status of permission use is generated through the inspection results of the compliance audit system. The permission requirements and the static business processing permissions are input into the permission adaptation analysis model for multi-dimensional association matching processing to determine whether the static business processing permissions cover the permission requirements in three dimensions: business line attributes, transaction type restrictions, and operation scope definition. The multi-dimensional association matching processing includes: matching the business line attributes of the permission requirements with the default permission scope of the static business processing permissions in the first dimension; matching the transaction type restrictions of the permission requirements with the cross-business line transaction restrictions of the static business processing permissions in the second dimension; and matching the operation scope definition of the permission requirements with the special business authorization quota of the static business processing permissions in the third dimension. If any mismatch exists in any dimension, then, by combining the cross-line operation frequency and the compliance status of permission use in the historical transaction behavior data, it is determined whether the mismatch belongs to a temporary permission gap. If the mismatch does not belong to the temporary permission gap, then the mismatch is determined to be the transaction permission to be authorized.

4. The transaction data processing method based on a unified trading platform according to claim 3, characterized in that, The step involves inputting the permission requirements and the static business processing permissions into the permission adaptation analysis model for multi-dimensional correlation and matching processing. This determines whether the static business processing permissions cover the permission requirements in three dimensions: business line attributes, transaction type restrictions, and operation scope definition. This includes: The permission requirements are structured and parsed to extract the business line identifier code from the business line attributes, the transaction variety list from the transaction type restrictions, the customer group classification and transaction amount range from the operation scope definition. The business line identifier code is used to uniquely identify the business line affiliation. The transaction variety list contains the transaction type identifiers that the target business function module is allowed to execute. The customer group classification is divided into different service levels according to customer attribute characteristics. The transaction amount range limits the upper and lower limits of the amount of a single transaction. The static business processing permissions are converted into a permission matrix. The default permission range is converted into a mapping table containing the line identifier code and the corresponding business function module. The cross-line transaction restriction is converted into a set of permission mutual exclusion rules between different business lines. The special business authorization limit is converted into a mapping table between customer group classification and transaction amount range. A three-dimensional permission matrix containing line dimension, transaction type dimension and operation scope dimension is generated. The bar identifier code in the permission requirements is matched with the bar dimension in the three-dimensional permission matrix in the first dimension. The mapping relationship table is checked to see if there is a business function module record corresponding to the bar identifier code. If there is a record, the business bar attribute dimension is marked as matched successfully. If there is no record, the business bar attribute dimension is marked as not matched successfully. The list of trading instruments in the permission requirements is matched with the trading type dimension in the three-dimensional permission matrix in the second dimension. Based on the permission mutual exclusion rule set, it is determined whether the trading type in the list of trading instruments has a permission conflict with the business line corresponding to the account manager's identity information. If there is no conflict, the trading type restriction dimension is marked as successful. If there is a conflict, the trading type restriction dimension is marked as unsuccessful. The customer group classification and transaction amount range in the permission requirements are matched with the operation range dimension in the three-dimensional permission matrix in the third dimension. The transaction amount upper limit under the same customer group classification in the corresponding relationship table is compared with the transaction amount range upper limit in the permission requirements. If the upper limit in the corresponding relationship table is greater than or equal to the upper limit in the permission requirements, the operation range definition dimension is marked as successfully matched. If it is less than, the operation range definition dimension is marked as unsuccessfully matched. The matching results of the business line attribute dimension, the transaction type restriction dimension, and the operation scope definition dimension are summarized. If all three dimensions match, it is determined that the static business processing permission fully covers the permission requirements. If at least one dimension fails to match, it is determined that the static business processing permission does not fully cover the permission requirements.

5. The transaction data processing method based on a unified trading platform according to claim 1, characterized in that, The method further includes: When a new business transaction request belonging to the same customer as the business transaction request is received, the new business transaction request is used to determine whether the business types of the new business transaction request and the business transaction request both belong to the target business type, based on the new business type information included in the new business transaction request. If so, and the time difference between the new business transaction request and the business transaction request is within a preset time window, then there is no need to verify the customer's identity information to execute the transaction operation corresponding to the new business transaction request; If not, or if the business types of the new business transaction request and the business transaction request both belong to the target business type and the time difference between the new business transaction request and the business transaction request is outside the preset time window, then an identity verification operation on the customer's identity information is triggered.

6. The transaction data processing method based on a unified trading platform according to claim 1, characterized in that, The method further includes: When there is a need for counter collaboration in the entire transaction processing operation, a counter collaboration request is pushed to the terminal of the authorized counter personnel. The target interface to be collaboratively processed at the counter is shared to the terminal of the authorized counter personnel and the front-end interactive interface. The target interface includes at least one of the following: transaction view, customer information, and business image data. In response to the verification result received from the authorized personnel terminal at the counter, indicating that the verification has been approved, the end-to-end transaction processing operation continues.

7. The transaction data processing method based on a unified trading platform according to claim 1, characterized in that, The method further includes: By embedding data points in the front-end framework of the unified trading platform, user behavior data is collected during the entire transaction processing operation. The user behavior data includes at least one of the following: dwell time on function pages, triggering behavior of function controls, workflow breakpoints, and search behavior. Obtain user suggestions from user feedback channels; The user behavior data and the user suggestion information are input into a pre-built platform function optimization model to obtain the function optimization suggestions output by the platform function optimization model. Based on the aforementioned functional optimization suggestions, at least one of the following should be adjusted in the unified trading platform: business function modules, transaction workflow paths, front-end function layout, and user interaction design, to generate the adjusted unified trading platform.

8. The transaction data processing method based on a unified trading platform according to claim 7, characterized in that, The step of inputting the user behavior data and the user suggestion information into a pre-built platform function optimization model to obtain the function optimization suggestions output by the platform function optimization model includes: The user behavior data is standardized by converting the dwell time of the function page, the triggering behavior of the function control, the workflow breakpoint, and the search behavior into a unified format behavior feature sequence. The behavior feature sequence includes timestamp, behavior type identifier, associated function module identifier, and behavior duration. The user suggestion information is processed by text structuring to extract suggestion type classification, functional module direction, problem description content, and expected optimization direction, and a structured suggestion feature vector is generated. The suggestion type classification includes functional defect category, process optimization category, experience improvement category, and new function suggestion category. The behavioral feature sequence is input into the feature extraction module to mine behavioral patterns, identify high-frequency triggering behavioral sequences, abnormal workflow breakpoint distribution and abnormal intervals of functional page dwell time, and generate a behavioral pattern feature set, which includes behavioral frequency features, behavioral path features and behavioral time consumption features. The structured suggestion feature vector is input into the semantic analysis module for sentiment analysis and topic extraction, identifying the core demands and sentiment in user suggestions, and generating a suggestion topic feature set, which includes topic keyword features, sentiment polarity features, and suggestion urgency features. The behavioral pattern feature set and the suggestion topic feature set are subjected to feature association processing. By calculating the co-occurrence frequency of behavioral features and suggestion features, a behavior-suggestion association matrix is ​​established. The behavior-suggestion association matrix is ​​used to represent the association strength between different behavioral patterns and suggestion topics. The behavior-suggestion association matrix is ​​input into the feature fusion layer of the platform function optimization model. The fusion weights of the behavior pattern features and suggestion topic features are dynamically adjusted through an attention mechanism to generate a comprehensive optimized feature vector. The comprehensive optimization feature vector is processed in parallel through the multi-task learning layer of the platform function optimization model to predict the optimization priority of functional modules, workflow path adjustment schemes, and improvement directions of user interaction, and generate a preliminary set of optimization suggestions. The preliminary set of optimization suggestions is subjected to conflict detection and priority ranking to eliminate functional conflicts between different suggestions, and the optimization priority sequence is determined based on the urgency characteristics and behavioral impact range of the suggestions. Based on the optimization priority sequence, generate functional optimization suggestions that include suggestions for adjusting functional modules, optimizing workflow paths, improving user interaction design, and developing new features.

9. The transaction data processing method based on a unified trading platform according to claim 1, characterized in that, The method further includes: Receive an offline update package download notification pushed by the application update server. The download notification includes the update package version identifier, update content summary, and download address information. Download the offline update package from the application update server to a preset local cache directory according to the download address information; After the offline update package passes the integrity verification, the offline update package is parsed to obtain the module identifier, module version number, and module file set of the functional module to be updated, and a module update list is generated. Based on the module update list, the currently running modules associated with the unified trading platform are paused and the system resources occupied by the currently running modules are released; Load the module file set to replace or add to the storage path of the functional module to be updated, update the module dependency configuration file of the functional module to be updated, and obtain the updated functional module; Restart the updated functional module and generate a module startup status report. If the module startup status report indicates normal operation, delete the offline update package in the local cache directory and record the update log.

10. A transaction data processing system based on a unified trading platform, characterized in that, The method includes a processor and a computer-readable storage medium storing machine-executable instructions, which, when executed by a computer, implement the transaction data processing method based on a unified trading platform as described in any one of claims 1-9.

Images