Session-based transaction processing method and device, computer device and storage medium

Abstract

The application discloses a conversation-based transaction processing method and device, computer equipment and storage medium, relates to the technical field of financial technology, and can improve overall processing efficiency and intelligent level. The method comprises the following steps: when detecting that a teller performs a login operation, creating a global context object, and starting a current customer session in the case that a start service instruction is received; obtaining customer related information and writing the customer related information into the global context object; in response to a selection operation for a current business transaction, creating a transaction instance, reading customer basic information from the global context object and filling the customer basic information; when receiving a transaction submission instruction, executing the business logic of the current business transaction, performing compliance verification in the execution process, and executing the current business transaction in the case of passing; and when detecting that the current business transaction is executed, storing print messages generated by executing the current business transaction in a print queue associated with a session identifier, so as to complete the transaction processing of this round.

Description

Technical Field

[0001] This application relates to the field of financial technology, and in particular to a session-based transaction processing method, apparatus, computer equipment, and storage medium. Background Technology

[0002] In the field of bank counter services, the traditional business processing model typically uses a single transaction as the basic unit of processing. This means that tellers initiate the corresponding transaction process one by one based on the documents or account information submitted by the customer at the counter, completing operations such as deposits, withdrawals, transfers, and account information changes. With the continuous diversification of banking services and the ongoing upgrading of risk control requirements, the counter system needs to interact with multiple back-end services, including online verification systems, customer information management systems, core accounting systems, debit card systems, and blacklist screening platforms, to obtain key data such as customer identity verification results, account status, card status, and risk levels. Because these back-end systems belong to different technology domains, their interface protocols, data formats, and response times vary significantly, forcing the counter system to be designed with a single transaction as the central focus for organizing data and control flows.

[0003] In the relevant technologies, in the current actual implementation of the counter system, the teller first receives the customer's identification document or customer number, then opens the target transaction interface, and sends a request to the online verification system through the internal query interface of the transaction to obtain the customer's detailed identity information; on this basis, requests are then sent to the customer information management, core, debit card and other systems in sequence to retrieve account and card status, gray and black list identifiers and other status data required for business processing; all returned information is summarized and displayed on the interface, and after the teller verifies it, it is submitted to trigger the transaction process. If an abnormal status is detected, an error window pops up requiring the teller to confirm. After the transaction is processed, the electronic voucher must be printed on the current transaction interface, and the next transaction can only be started after the printing operation is completed.

[0004] In the process of implementing the relevant technology, the applicant recognized that the relevant technology has at least the following technical problems: Information acquisition is embedded in the internal call chain after a transaction is initiated, causing backend interface calls to be concentrated at the moment of transaction submission. This increases the instantaneous load on the server and the risk of timeouts. Furthermore, compliance checks such as gray and black lists rely on status fields obtained only in the middle of the transaction, and the screening logic is coupled with the business logic code, which undermines the temporal independence of compliance checks. In addition, the transaction context is destroyed after the transaction is closed, which means that when the same customer makes multiple consecutive transactions, they need to swipe their card and make repeated queries. This wastes network and system resources and causes data consistency issues because the query results may differ. As a result, transaction processing efficiency is low and intelligence is poor. Summary of the Invention

[0005] In view of this, this application provides a session-based transaction processing method, apparatus, computer device, and storage medium, the main purpose of which is to solve the problems of low efficiency and poor intelligence in current transaction processing.

[0006] According to a first aspect of this application, a session-based transaction processing method is provided, the method comprising: When a teller is detected to be performing a login operation, a global context object is created. Upon receiving a start service instruction initiated by the teller, the current customer session is started, a session identifier is generated, and associated with the global context object. Multiple data interfaces are called sequentially to obtain customer-related information. The customer-related information is written into the global context object according to a preset data structure so that the global context object continuously stores and shares the customer-related information throughout the entire lifecycle of the current customer session. The customer-related information includes customer identity verification information, customer basic information, and multi-dimensional risk screening results. In response to the teller's selection operation for the current business transaction, a transaction instance corresponding to the current business transaction is created, and the transaction instance is called to read the customer's basic information from the global context object and populate it into the transaction interface; Upon receiving a transaction submission instruction initiated by the teller, the business logic of the current business transaction is executed. During the execution process, the customer identity verification information and the multi-dimensional risk screening results are read from the global context object for compliance verification. If the compliance verification is successful, the current business transaction is executed. Once the current business transaction is detected to be completed, the print message generated by the current business transaction is stored in the print queue associated with the session identifier to complete the transaction processing for this round.

[0007] According to a second aspect of this application, a session-based transaction processing apparatus is provided, the apparatus comprising: A creation module is used to create a global context object when a teller performs a login operation, and to start the current customer session, generate a session identifier and associate it with the global context object when a start service instruction is received from the teller. The writing module is used to sequentially call multiple data interfaces to obtain customer-related information, and write the customer-related information into the global context object according to a preset data structure, so that the global context object continuously stores and shares the customer-related information throughout the entire lifecycle of the current customer session. The customer-related information includes customer identity verification information, customer basic information, and multi-dimensional risk screening results. The reading module is used to respond to the teller's selection operation for the current business transaction, create a transaction instance corresponding to the current business transaction, call the transaction instance to read the customer's basic information from the global context object and populate it into the transaction interface; The inspection module is used to execute the business logic of the current business transaction when it receives the transaction submission instruction initiated by the teller, and read the customer identity verification information and the multi-dimensional risk screening results from the global context object during the execution process to perform compliance verification, and execute the current business transaction if the compliance verification is passed; The execution module is used to store the print message generated by the execution of the current business transaction into the print queue associated with the session identifier after detecting that the current business transaction has been completed, so as to complete the transaction processing of this round.

[0008] According to a third aspect of this application, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described in any of the first aspects above.

[0009] According to a fourth aspect of this application, a storage medium is provided that stores a computer program thereon, which, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0010] By employing the aforementioned technical solutions, this application provides a session-based transaction processing method, apparatus, computer device, and storage medium. This application constructs an association between a global context object and a session identifier, sequentially calling multiple data interfaces before transaction initiation to centrally complete multi-dimensional pre-acquisition of customer information. This decouples information query actions from the internal call chain of a single transaction, avoiding instantaneous load spikes and timeout risks caused by concentrated backend interface calls at the transaction submission moment. Simultaneously, since customer identity verification information and multi-dimensional risk screening results are written into the global context object during session initialization, the status fields upon which compliance verification depends are ready before transaction execution. This eliminates reliance on dynamic interface calls during the transaction, decoupling screening logic from business logic at the code level and ensuring the temporal independence of compliance checks. Furthermore, the global context object continuously stores and shares customer-related information throughout the entire session lifecycle. Transaction instances directly read pre-filled information from this global context object without repeated card swiping and queries in each transaction, reducing redundant consumption of network and system resources. Moreover, customer information read by each transaction within the same session originates from the same shared data, avoiding data inconsistencies due to different query times, thus improving overall processing efficiency and intelligence.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0012] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 A schematic diagram of a session-based transaction processing method provided in an embodiment of this application is shown. Figure 2 This illustration shows a timing logic diagram for pre-identifying customers according to an embodiment of this application; Figure 3 This illustration shows a data structure diagram of a global context object provided in an embodiment of this application; Figure 4 This paper illustrates a schematic diagram of the system architecture of a transaction processing system provided in an embodiment of this application. Figure 5 A schematic diagram of another session-based transaction processing method provided in an embodiment of this application is shown; Figure 6 A schematic diagram of the structure of a session-based transaction processing apparatus provided in an embodiment of this application is shown; Figure 7 A schematic diagram of the device structure of a computer device provided in an embodiment of this application is shown. Detailed Implementation

[0013] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0014] This application provides a session-based transaction processing method, such as... Figure 1 As shown, the method includes: S10: When a teller is detected to be performing a login operation, a global context object is created. When a start service instruction is received from the teller, the current customer session is started, a session identifier is generated and associated with the global context object.

[0015] This application embodiment can be applied to a transaction processing system. When a teller is detected performing a login operation on the counter system, the creation of a global context object is triggered. This global context object is an in-memory data container using a key-value store structure, used to uniformly store and manage customer data, risk status, and business context information throughout the entire lifecycle of the current customer session. After successful login, the global context object is first initialized, writing teller-related information such as teller number, name, and institution number. When the teller initiates a service start command by clicking the "Start Service" button on the interface, the transaction processing system starts the current customer session, generating a unique session identifier, such as a customer identification serial number (e.g., YYYYMMDD + 7-digit sequence number + system number). This session identifier is then associated and bound to the previously created global context object. Subsequently, the global context object serves as the data sharing hub for the session; all customer data generated during the session is associated with this global context object until the session ends.

[0016] In this way, through the above implementation process, the lifecycle of the global context object is clearly divided into three stages: creation upon login, effectiveness after session startup, and destruction upon session termination, thus providing basic support for subsequent data sharing and cross-transaction reuse.

[0017] For example, after teller A logs into the counter system in the business hall, the transaction processing system automatically creates a global context object and writes A's teller number and institution information into it; when the first customer comes to the counter, A clicks "Start Service", the transaction processing system starts the customer's session and generates a session number as a session identifier, associates the global context object with the number, and thereafter all the customer's transaction data is bound to the session identifier.

[0018] S20: Sequentially call multiple data interfaces to obtain customer-related information, and write the customer-related information into the global context object according to the preset data structure so that the global context object can continuously store and share customer-related information throughout the entire lifecycle of the current customer session.

[0019] In this embodiment, after the current customer session is initiated but before any specific business transaction is opened, the transaction processing system enters the customer pre-identification stage. During this stage, the transaction processing system sequentially calls multiple external data interfaces in a predetermined order to obtain customer-related information. In this embodiment, the customer-related information includes customer identity verification information, basic customer information, and multi-dimensional risk screening results. Specifically, it can call the network verification system interface to send a verification request containing document type and document number to the network verification system to obtain customer identity verification information; it can call the customer information management system (ECIF) interface to send a query request containing the customer number to the customer information management system to obtain basic customer information, including customer name, customer type, and contact information; and it can activate the risk screening module to sequentially perform checks on multiple preset risk dimensions through the external system interface gateway, such as blacklist matching, account control status query, and risk level assessment, thereby obtaining multi-dimensional risk screening results. After obtaining the above information, the transaction processing system writes the information into the corresponding partitions of the global context object according to a preset data structure. Since the global context object is associated with the session identifier when the session starts, the customer-related information written is continuously stored throughout the entire lifecycle of the current customer session, and can be shared and accessed by all business transaction instances within the session.

[0020] In this way, through the above implementation process, all backend interface calls are completed before the transaction is executed, avoiding duplicate queries and resource waste caused by interface calls being scattered within each transaction.

[0021] For example, during the customer pre-identification stage, the transaction processing system first calls the online verification interface to return "Identity verification passed", then calls the ECIF interface to return the basic information of customer "B", and finally performs 15-dimensional risk checks to generate a risk screening result list. All results are written to the global context object. When the customer subsequently conducts deposit and transfer transactions, the above information can be read directly from the global context object without having to swipe the card again or make repeated inquiries.

[0022] S30: In response to the teller's selection operation for the current business transaction, create a transaction instance corresponding to the current business transaction, call the transaction instance to read the customer's basic information from the global context object and populate it into the transaction interface.

[0023] In this embodiment, after the customer pre-identification stage is completed and the customer-related information has been written into the global context object, the teller can select the specific transaction type to be processed in the transaction interface, such as deposit, transfer, or account opening. In response to this selection, the transaction processing system creates a transaction instance corresponding to the current transaction. This transaction instance is an execution unit generated in memory by the transaction processor to carry the current transaction logic and data. During initialization, the transaction instance automatically reads basic customer information, such as customer number, ID number, customer name, and customer type, from the customer basic information partition of the global context object and automatically fills this information into the corresponding input fields of the transaction interface. The teller does not need to swipe the card again or manually enter customer identity information; they only need to supplement the information specific to this transaction, such as the deposit amount and the receiving account for the transfer.

[0024] In this way, through the above implementation process, it becomes possible to reuse customer information across transactions. Each transaction within the same session can directly obtain the pre-filled customer information from the global context object, thereby achieving the effect of one-time identification and multiple reuse.

[0025] For example, after the customer pre-identification is completed, the teller selects the "Deposit" transaction. The transaction processing system creates a deposit transaction instance, automatically reads the customer's name, ID number, and customer number from the global context object, and fills them into the deposit interface. After the deposit transaction is completed, the teller then selects the "Transfer" transaction. The transfer transaction instance created by the transaction processing system also reads the same information from the global context object and fills it into the transfer interface, without requiring the customer to provide identification again.

[0026] S40: Upon receiving a transaction submission instruction initiated by a teller, execute the business logic of the current business transaction. During the execution process, read customer identity verification information and multi-dimensional risk screening results from the global context object for compliance verification. If the compliance verification passes, execute the current business transaction.

[0027] In this embodiment, after the teller completes the specific transaction information on the transaction interface and confirms that it is correct, they will click the submit button to initiate a transaction submission instruction. After receiving the instruction, the transaction processing system will first read the customer identity verification information from the customer basic information partition of the global context object and read the multi-dimensional risk screening results from the risk status partition before executing the business logic. The transaction instance sequentially iterates through the status values ​​of each risk dimension in the multi-dimensional risk screening results according to a preset verification order, determining whether there are any blocking markers in effect. If a blocking marker for a certain risk dimension is in effect, the compliance verification is deemed to have failed. The transaction processing system generates a prompt message including the blocking reason corresponding to that risk dimension, such as "[This customer is blacklisted, business processing is restricted]", and returns to the transaction interface, terminating the execution of the current business transaction. If the blocking markers for all risk dimensions are not in effect, the compliance verification is deemed to have passed. The transaction instance then obtains the transaction-specific information supplemented by the teller, assembles this transaction-specific information with the customer's basic information read from the global context object into a transaction request message, calls the core business system interface through the external system interface gateway to send the transaction request, receives the transaction processing result returned by the core system, and completes the execution of the current business transaction.

[0028] In this way, through the above implementation process, all the status information required for compliance verification is ready in the global context object before the transaction is executed. The verification action does not need to wait for the dynamic interface call in the middle of the transaction, thus achieving the decoupling of compliance checks and business logic in terms of timing.

[0029] For example, after a teller submits a deposit transaction, the transaction instance first reads the risk screening results from the global context object. If it finds that the blocking flag for "blacklist matching" is active in the 15-dimensional check of the customer, a prompt will pop up saying "This customer is on the blacklist and cannot conduct business" and the transaction will be terminated. If the blocking flags for all risk dimensions of the customer are not active, the transaction instance reads the deposit amount from the interface, assembles the customer number and the amount into a message and sends it to the core system to complete the accounting.

[0030] S50: When the current business transaction is detected to be completed, the print message generated by the current business transaction is stored in the print queue associated with the session identifier to complete the transaction processing of this round.

[0031] In this embodiment, after the business logic of the current business transaction is completed and the core system returns the transaction processing result, the transaction processing system detects the completion status of the transaction and then calls the print method of the print utility class to generate a print message for the transaction. The print message includes data such as transaction details, customer information, amount, and voucher number. Further, the transaction processing system determines whether the print item corresponding to the print message supports the unified print mode. If it does, the print message is associated with the transaction code, transaction time, teller number, and session identifier of the current business transaction and stored in the print queue in the database. The print queue uses the session identifier as an index to store all messages to be printed generated during the session. The print queue can be a unifiedPrintXmlArr queue. Each print record stores the XML string of the print message and the GSWJ print template file name to ensure accurate restoration of the voucher format during subsequent printing. The transaction processing system does not immediately execute the print operation during business processing; instead, it adds the generated print tasks to the unified print queue, achieving asynchronous decoupling between the print tasks and the transaction execution process. When a print job is added to the print queue, the transaction processing system also verifies preset trigger conditions to ensure that the print job meets the unified printing access requirements. These conditions include: the current customer number matches the customer number recorded in the session context; the session status is "Business in Progress"; the customer type is either a personal or corporate customer; and the unified printing support flag for the print item is enabled. Only when all of these conditions are met is the print job allowed to be added to the unified print queue. For example, when a teller processes a deposit for a customer, after the transaction is completed, the system generates a print message for the deposit voucher. After verification confirms that the print item supports unified printing and the session status is normal, the print message, along with the transaction code, current time, and teller number, is stored in the `unifiedPrintXmlArr` queue. However, the printer does not immediately output the voucher but waits for a subsequent unified trigger opportunity.

[0032] Furthermore, in this embodiment, the delayed execution mechanism for print tasks stipulates that all print tasks stored in the unified print queue are delayed until the end of the current customer session. When the teller completes all the customer's business transactions and clicks the "End Service" button, the session manager receives the end service instruction and calls the unified print interface opening method, such as the HxOpenTradeOrPanel.asyncOpen5Trade() method, triggering the loading and display of the unified print interface. At this time, all print tasks in the queue enter the actual print execution process. In this way, through this implementation process, the print operation is no longer embedded in the transaction process as a synchronous blocking condition at the end of a single transaction, but is delayed until the session end stage for centralized triggering. A single transaction can end immediately after the core system returns the processing result and proceed to the next transaction without waiting for the printing device to complete the output. At the same time, multiple print tasks are executed uniformly in the same session end stage, which can reduce the number of times the teller repeatedly switches printing devices and waits for printing to complete between different transactions, making the overall transaction process more coherent and efficient, and improving the smoothness of counter business processing. For example, suppose a customer completes two transactions, a deposit and a transfer. The print messages for the two transactions are stored in the unifiedPrintXmlArr queue after each transaction is completed, but neither is actually printed. Only after the customer has completed all transactions and the teller clicks "End Service" will the system open the unified printing interface at once and print both vouchers together. The teller can complete multiple transactions continuously without waiting for the printer during the entire transaction process.

[0033] Optionally, in this embodiment, multiple data interfaces are sequentially invoked to obtain customer-related information, and the customer-related information is written into a global context object according to a preset data structure. This includes: invoking a data interface for interfacing with the online verification system, sending a verification request including document type and document number to the online verification system, and receiving the customer identity verification result returned by the online verification system based on the verification request; invoking a data interface for interfacing with the customer information management system, sending a query request including customer number to the customer information management system, and receiving the basic customer information returned by the customer information management system based on the query request; and invoking a risk screening module to sequentially perform checks on multiple preset risk dimensions and obtain the risk status obtained on each preset risk dimension. The system obtains multiple risk status values ​​and summarizes them into a multi-dimensional risk screening result. A global context object is constructed, in which the customer identity verification result is written as the first type of data into the customer basic information partition, the customer basic information is written as the second type of data into the customer basic information partition, and the multi-dimensional risk screening result is written as the third type of data into the risk status partition. The global context object maintains the customer basic information partition and the risk status partition in memory using a key-value pair storage structure. The global context object remains accessible to all business transaction instances within the current customer session throughout its entire lifecycle until it is destroyed when the current customer session ends.

[0034] In this embodiment, after the session is initiated but before any business transaction is opened, the transaction processing system enters the customer pre-identification stage. First, the transaction processing system calls the data interface used to interface with the online verification system, sending a verification request containing the document type and document number. The online verification system is an external verification platform used by the bank to verify the authenticity and validity of customer identity documents. Upon receiving the request, it returns the customer identity verification result, such as "Verification passed" or "Verification failed," along with the corresponding identity information. Next, the transaction processing system calls the data interface used to interface with the customer information management system, sending a query request containing the customer number. The customer information management system (ECIF) is a system used by the bank to uniformly store and manage basic customer information. Upon receiving the query request, it returns the basic customer information, such as customer name, customer type, contact information, and region code. Finally, the transaction processing system calls the risk screening module. The risk screening module calls the interfaces of each back-end risk system through the external system interface gateway and performs multiple preset risk dimensions checks in sequence, such as suspected customer identification, blacklist matching, and account management status query. After each risk dimension check is completed, the corresponding risk status value is obtained. After all dimensions are checked, the multiple risk status values ​​are summarized into a multi-dimensional risk screening result.

[0035] In this way, through the above implementation process, all backend interface calls are completed in the pre-identification stage before transaction execution, avoiding duplicate queries and wasted network resources caused by interface calls being scattered throughout each transaction. Simultaneously, risk screening results are generated before business processing, and the status fields upon which compliance checks rely are ready before transaction execution, eliminating the need to wait for dynamic interface calls during the transaction process. For example, after a teller initiates a session for a customer at the counter, the transaction processing system calls the online verification interface to verify the authenticity of the ID card and obtains a "verification passed" result. It then calls the ECIF interface to obtain the customer's registered name and contact information in the bank's system. Subsequently, the risk screening module is activated to sequentially complete multiple checks, such as blacklist matching. All results are obtained before the first transaction is opened.

[0036] After acquiring the aforementioned information, the transaction processing system constructs a global context object. This global context object is an in-memory data container that maintains multiple data partitions in memory using a key-value pair storage structure. These partitions include core areas such as customer basic information and risk status. Information is written in batches using specific public methods. The transaction processing system writes the customer identity verification result as the first type of data to the customer basic information partition of the global context object, writes the customer basic information as the second type of data to the same partition, and writes the multi-dimensional risk screening results as the third type of data to the risk status partition. The global context object continuously stores all of the above information in memory, maintaining accessibility to all business transaction instances within the current customer session throughout its entire lifecycle. Any transaction instance can directly read the pre-filled customer information and risk screening results from the global context object through a unified interface, without needing to re-query external systems. When the teller clicks the "End Service" button, the transaction processing system calls the data destruction method of the global context object to overwrite sensitive customer data and release memory, achieving secure data destruction and meeting compliance requirements.

[0037] In this way, through the above implementation process, the global context object acts as the data sharing hub across transactions, enabling each transaction within the same session to reuse the customer information obtained in the initial pre-identification stage. This eliminates the need for customers to repeatedly swipe their cards or for tellers to repeatedly enter information. Furthermore, the customer information read by each transaction within the same session originates from the same shared data, avoiding data inconsistencies caused by different query times. For example, when customer C opens an account at the counter, the transaction processing system writes the online verification results, the basic information returned by ECIF, and the 15-dimensional risk screening results into the global context object during the pre-identification stage. When customer C completes the account opening and continues to conduct deposit business, the transaction instance directly reads customer C's name and ID number from the global context object and automatically fills them into the deposit interface, eliminating the need for customer C to present their ID card again, and the teller also does not need to re-enter customer information.

[0038] In this embodiment, optionally, the risk screening module is invoked to sequentially perform checks on multiple preset risk dimensions and obtain risk status values ​​on each preset risk dimension, resulting in multiple risk status values. These multiple risk status values ​​are then aggregated into a multi-dimensional risk screening result. This includes: invoking the risk screening module so that it calls the interface of the customer information management system class through the first communication service component to perform checks related to customer information among the multiple preset risk dimensions. The checks related to customer information include: a suspected customer identification check by passing the document type and document number to the suspected customer query interface and receiving the returned "suspect" identifier; a customer risk level check by passing the customer number to the customer information query interface and extracting the risk level field value from the returned customer information data; a regional risk detection check by obtaining the customer region code from the global context object and passing the region code to the region risk check interface to receive the returned region risk level value; and a list matching check by passing the document number to the blacklist check interface and receiving the returned list matching type and list number. The query module enables the risk screening module to call the core system class interface through the second communication service component to perform checks related to account information across multiple preset risk dimensions. These account information-related checks include: inputting the account number to the account anomaly status query interface and receiving the returned account payment and collection control status; inputting the account number to the account freeze query interface and receiving the returned freeze status indicator; and inputting the account number to the credit limit query interface and receiving the returned cumulative remaining credit limit value for credit limit status checks. After each preset risk dimension check is completed, the risk status values ​​returned by each preset risk dimension check are collected uniformly using a result collection method. A structured alert information list containing the risk status values ​​of each preset risk dimension check is generated and pushed to the customer alert interface of the counter system for display. Each alert information item in the structured alert information list includes an alert title, alert text content, blocking indicator, and target transaction interface indicator. The risk status values ​​returned by each preset risk dimension check are integrated to obtain a multi-dimensional risk screening result.

[0039] In this embodiment, the transaction processing system includes a risk screening module. This module uses an external system interface gateway to uniformly call the interfaces of various back-end risk systems. The external system interface gateway is a unified entry point that encapsulates communication protocols with external systems, timeout control, and exception handling. The counter system interacts with multiple heterogeneous back-end systems through this gateway. Specifically, the transaction processing system calls the risk screening module, which then uses a first communication service component to call the interface of the customer information management system class to perform checks related to customer information across multiple preset risk dimensions. The first communication service component can be the TradeCommUtil.communication service, a dedicated component that encapsulates the communication logic with the customer information management system and is responsible for sending requests and receiving and parsing responses. Specific checks related to customer information include: Suspected customer identification checks, which involve querying suspected customer interfaces, such as HxApi.getS001303003543(), by inputting the document type and document number, and receiving a suspected customer flag. If the returned list of suspected customers is not zero, the flag is true, indicating that the customer has a suspected identity. Customer risk level checks, which involve querying customer information interfaces, such as QueryUtilECIF.getCustInfo(custNo), by inputting the customer number, extracting the risk level field value from the returned customer information data, parsing the warnLevelRisk field in the returned XML and mapping it to levels 1 to 5, with higher values ​​indicating greater risk; levels 4 and above trigger a high-risk alert. Regional risk checks, which involve obtaining the customer's regional code from the global context object and submitting it to a regional risk check interface, such as TradeCommUtil.communication(ServiceNames.CHECKRISKCOUNTRY, The `countryCode` interface takes this code as input and receives the returned regional risk level value, such as high, medium, or low. High risk triggers a service block, used to identify whether a customer is from a high-risk country or region. For list matching checks, in the case of ID number login, the blacklist check interface, such as `TradeCommUtil.communication(ServiceNames.BLACKLISTCHECK, "ID", idNo)`, takes the ID number as input and receives the returned list matching type (blacklist, graylist, or no match) and the corresponding list number, used to determine if the customer has been included in various risk lists. For account graylist checks, in the case of card number or account recognition, the graylist check interface, such as `TradeCommUtil.communication(ServiceNames.BLACKLISTCHECK, "ID", idNo)`, takes the ID number as input and receives the returned list matching type (blacklist, graylist, or no match) and the corresponding list number, used to determine if the customer has been included in various risk lists.The `GRAYLISTCHECK(String)` interface takes a card number or account number as input and receives the returned graylist matching results. For reconciliation status checks, specifically in corporate account scenarios, it calls reconciliation status query interfaces, such as `accountChecking(acctNo)`, takes an account number as input, and receives the returned reconciliation status, including reconciliation completed, not reconciled, or reconciliation abnormal. If reconciliation is not completed, a mandatory reconciliation reminder is pushed. For regulatory account checks, specifically in corporate account scenarios with account identification, it calls account information query interfaces, such as `AccountApi.queryAcctInfo(acctNo)`, to obtain the account's product category and product details. The subclass then calls the regulatory mark query interface based on the obtained information. For example, the `NewQueryUtils.queryProductFlg(AccTyp,ActCat)` interface receives the yes / no regulatory mark and regulatory agency code. CRS and due diligence status checks are also handled through client information query interfaces, such as `QueryUtilECIF.getCustInfo(custNo)`, which takes the client number as input and parses the returned CRS type (non-resident, resident, or unknown) and due diligence status fields (completed, pending, or not yet initiated) to identify the client's tax residency and due diligence completion status.

[0040] Simultaneously, the transaction processing system will invoke the risk screening module, which will then use the second communication service component to call the interface of the core system class to perform checks related to account information across multiple preset risk dimensions. The second communication service component can be a pre-packaged method from the `trade.communicationHost` family, a dedicated component that encapsulates the communication logic with the core accounting system. Specific account information-related checks include: account control checks, which involve sequentially querying account abnormality status interfaces, such as the getAccountAbnormality(acctNo) interface, passing in the account information to receive the returned account payment control status, such as "only receiving but not paying" or "neither receiving nor paying"; querying account freeze interfaces, such as the checkAcctIsFreeze(acctNo) interface, passing in the same account information to receive the returned freeze status identifier to determine whether the account is currently under judicial freeze or other freeze status; and querying the suspension of non-counter services interface, such as the SuspendFeiGuiMian.querySuspendFeiGuiMian(acctNo) interface, passing in the account information to check the suspension of non-counter services flag; and credit limit status checks, which, in the case of private accounts, involve querying credit limit interfaces, such as the quotaQuery(acctNo) interface, passing in the account information to receive the returned cumulative remaining credit limit value, such as the daily or annual cumulative remaining credit limit for borrowers, in yuan. If the credit limit is insufficient, a pre-warning is given to identify whether the available credit limit for second- and third-class accounts is sufficient.

[0041] In addition, the risk screening module can continue to perform checks on other preset dimensions, such as fraud and anti-money laundering blacklist checks. Specifically, it can call the existing data obtained during the aforementioned customer identification, such as sdm.CustomerInfo.isSwindler and sdm.CustomerInfo.isAntiMoney, and receive the returned list type, including anti-money laundering, telecom fraud, or no match, as well as the high, medium, or low risk level. Another example is customer status checks, which extract customer lifecycle status fields from existing data, such as the sdm.CustomerInfo.custLifeCycInd field, with values ​​including normal and inactive. The system can send reminders when a customer is inactive, such as during hibernation or account cancellation. For example, it can send reminders to one-time financial customers, based on whether they are one-time customers and transaction amounts such as 50,000 yuan or more. It can then access existing customer identification data, such as the `sdm.CustomerInfo.dispCustFlg` field, and receive a yes / no reminder flag. Another example is information integrity checks, which access existing customer identification data, such as `sdm.CustomerInfo.customerMissingInfo`, checking fields including contact information (phone number, email, etc.), occupation information, and address information, and receiving a list of missing fields. In all these checks, the customer information management system interface is called through the first communication service component `TradeCommUtil.communication`, and the core system interface is called through encapsulated methods of the second communication service component `trade.communicationHost`. All 15 dimension check requests are executed sequentially during the session pre-identification phase, with a timeout of 60 seconds for each interface. Failure to respond within the timeout period will generate an error message for the teller. In this way, through this implementation process, the risk screening module completes all the pre-set compliance checks before the transaction is executed, and the risk status fields are all ready before the business is processed. The compliance checks and business logic are effectively decoupled at both the code level and the timing level, which can avoid the operation rollback and process repetition caused by the compliance checks being executed in the middle of the transaction.

[0042] After all pre-defined risk dimensions have been checked, the transaction processing system will collect the risk status values ​​returned by each risk dimension through a result collection method, such as the customerReminder() method, with input parameters including customer number and ID number, and output a structured alert information list returnList:object[]. Each alert information item in this list includes an alert title, alert text content, color code, and target transaction interface identifier. The alert title can be represented by the alertTitle field, for example, "Blacklist Matching Alert"; the alert text content can be represented by the alertContent field, for example, "This customer has been matched against the gray list, number XXX"; the color code can be represented by the alertColor field, with values ​​of yellow or blue, corresponding to alert or warning respectively; the target transaction interface identifier can be represented by the targetTrade field, which specifies which transaction interface the alert information should be displayed on. The transaction processing system uses push functions, such as `pushInfoToReturnList(alertList)`, to push a list of structured alerts to the "Customer Reminders" interface of the counter system for centralized display. Items marked in blue or yellow are displayed only as alerts and do not disrupt the business process. Items marked in yellow, intended as alerts, will trigger a pop-up window indicating the reason for the disruption and terminate the identification process if a business disruption condition is met. Finally, the transaction processing system integrates and summarizes the risk status values ​​returned from checks across various preset risk dimensions, obtaining a multi-dimensional risk screening result, which is then written to the risk status partition of the global context object for compliance verification during subsequent transaction execution. For example, after a teller initiates a session for customer Ding and completes the basic customer information query, the transaction processing system calls the risk screening module. First, it completes customer information-related checks such as suspected customer identification, customer risk level, and blacklist matching through the first communication service component. Then, it completes account information-related checks such as account control status and credit limit status through the second communication service component. After all 15 dimensions of checks are completed, the results are summarized into a multi-dimensional risk screening result and written to the global context object. When the teller subsequently submits a transfer transaction, the transaction processing system reads the screening result from the global context object. If the blocking flag of the blacklist matching dimension is in effect, the transaction is directly blocked and a "This customer is on the gray list" prompt is displayed. There is no need to query temporarily during the transaction process, thus realizing the timing of compliance checks on business logic.

[0043] In summary, in the embodiments of this application, the temporal logic for obtaining basic customer information and multi-dimensional risk screening results to pre-identify customers is as follows: Figure 2As shown, in response to the "Start Service" operation triggered by the teller on the teller interface, the session manager in the transaction processing system calls the pre-identification engine to initiate the pre-identification process, and simultaneously starts risk screening by calling the risk screening module. The pre-identification engine calls the unified query interface through the external system interface gateway to query the customer information management system in the external system for basic customer information. After receiving the basic customer information, the pre-identification engine writes it into the customer basic information partition of the global context object. Simultaneously, after starting, the risk screening module sequentially calls risk check interface 1, risk check interface 2, and risk check interface 3 to the external system to perform risk checks of different dimensions. The external system returns corresponding risk result data for each risk check request. The risk screening module collects all returned results to form a multi-dimensional risk screening result and writes it into the risk screening result partition of the global context object. After both the customer basic information and the multi-dimensional risk screening result are written into the global context object, the transaction processing system updates the customer reminder panel based on the multi-dimensional risk screening result in the global context object, centrally displaying the check status and reminder information for each risk dimension on the customer reminder interface.

[0044] Optionally, upon receiving a transaction submission instruction initiated by a teller, the business logic of the current business transaction is executed. During execution, customer identity verification information and multi-dimensional risk screening results are read from the global context object for compliance verification. If the compliance verification passes, the current business transaction is executed. This includes: responding to the transaction submission instruction, based on the transaction instance of the current business transaction, reading customer identity verification information from the customer basic information partition of the global context object, and reading multi-dimensional risk screening results from the risk status partition of the global context object; based on the transaction instance, sequentially traversing the blocking identifiers associated with each risk status value in the multi-dimensional risk screening results according to a preset verification order, and determining that the compliance verification has passed if it is determined that the blocking identifiers associated with each risk status value in the multi-dimensional risk screening results are not in an effective state; obtaining the transaction-specific information supplemented by the teller in the transaction interface based on the transaction instance, assembling the transaction-specific information and the customer basic information read from the global context object into a transaction request message; and sending the transaction request message to the core business system through the external system interface gateway, which executes the transaction and returns the transaction processing result.

[0045] In this embodiment, after the teller completes the specific transaction information on the transaction interface and clicks submit, the transaction processing system responds to the transaction submission instruction, and the transaction instance of the current business transaction enters the compliance verification stage. The transaction instance first reads the customer identity verification information from the customer basic information partition of the global context object, such as the "Verification Passed" or "Verification Failed" status returned by the online verification system, and reads the multi-dimensional risk screening results from the risk status partition of the global context object. The multi-dimensional risk screening results include the risk status values ​​returned by each preset risk dimension check, such as the list type and matching number returned by the "Blacklist Matching" dimension, and the payment control identifier returned by the "Account Control Status" dimension. Each risk status value in the multi-dimensional risk screening results is associated with a corresponding blocking identifier. The blocking identifier is used to indicate whether the risk dimension triggers the business blocking condition. For example, when the risk level corresponding to a certain risk dimension reaches a preset threshold, such as level 4 or above, the blocking identifier is set to an active state. When the risk level is below the threshold or the check result is no abnormality, the blocking identifier remains inactive. In this way, through this implementation process, all the status data required for compliance verification is already in the global context object before the transaction is submitted. The verification process does not need to trigger new backend interface calls, which can avoid load peaks and response delays caused by concentrated interface calls at the time of transaction submission.

[0046] Furthermore, the transaction instance will sequentially traverse the blocking identifiers associated with each risk status value in the multi-dimensional risk screening results according to a preset verification order. This preset verification order could be, for example, first checking customer information-related dimensions, such as blacklist matching and customer risk level, and then checking account information-related dimensions, such as account control status and credit limit status, to ensure that key risk dimensions are verified first. During the traversal, if the blocking identifier associated with the currently traversed risk status value is in an active state, the transaction instance determines that the compliance verification fails, generates a prompt message including the corresponding blocking reason for that risk dimension, such as "[This customer is blacklisted, business processing is restricted]" or "[This account is frozen, transactions cannot be processed]", and returns to the transaction interface, terminating the execution of the current business transaction. The teller can learn the blocking reason without waiting for dynamic queries during the transaction. Conversely, if the blocking identifiers associated with all risk status values ​​in the multi-dimensional risk screening results are not in an active state, the transaction instance determines that the compliance verification passes. In this way, through this implementation process, compliance checks no longer rely on dynamic interface calls in the middle of the transaction. Instead, they use the risk status data that has been obtained and solidified in the global context object during the pre-identification stage for verification. The screening logic and business logic are decoupled at the code level, and the temporal independence of compliance checks is effectively guaranteed, which can avoid operation rollback and process repetition caused by compliance delays.

[0047] After compliance verification is passed, the transaction instance obtains the transaction-specific information supplemented by the teller in the transaction interface. This transaction-specific information is unique data that distinguishes this transaction from other transactions, such as the deposit amount in a deposit transaction, the receiving account and transfer amount in a transfer transaction, and the account type in an account opening transaction. The transaction instance then assembles the aforementioned transaction-specific information with the basic customer information read from the global context object, such as customer number, customer name, and document type, into a transaction request message according to the message format required by the core business system. Subsequently, the transaction instance calls the core business system interface through the external system interface gateway. The external system interface gateway is a unified entry point that encapsulates the communication protocol with the core system, timeout control, and exception handling. Through this external system interface gateway, the transaction request message is sent to the core business system, which executes the corresponding accounting processing or business logic, such as completing deductions, bookkeeping, and account opening registration, and returns the transaction processing result, such as transaction success or failure and the corresponding return code and core transaction number. After receiving the return result, the transaction instance completes the execution of the current business transaction. In this way, through this implementation process, the data assembly and business logic processing during transaction execution are clearly separated from the pre-compliance verification in terms of timing. The execution path of the transaction process is more explicit, and the certainty and controllability of the overall transaction processing system are improved. For example, when customer E conducts a large-amount transfer at the counter, the teller enters the receiving account and transfer amount and clicks submit. The transaction instance first reads the blacklist matching result from the global context object, which is "missing" and the account control status is "normal" with all blocking flags ineffective. After the compliance verification is passed, the transaction instance assembles the transfer amount, receiving account, and customer E's number and payment account from the global context object into a transfer request message, sends it to the core system through the external system interface gateway to complete the transfer accounting, and receives the "transaction successful" return result.

[0048] Optionally, in this embodiment of the application, the method further includes: if it is determined that the blocking identifier associated with the specified risk status value in the multidimensional risk screening result is in an effective state, determining that the compliance verification fails, specifying the risk status value as any risk status value in the multidimensional risk screening result; determining the specified preset risk dimension corresponding to the specified risk status value, generating a prompt message including the blocking reason corresponding to the specified preset risk dimension, and returning the prompt message to the transaction interface to terminate the execution of the current business transaction.

[0049] In this embodiment, during the compliance verification process, the transaction instance sequentially traverses each risk status value and its associated blocking identifier in the multi-dimensional risk screening results according to a preset verification order. When any risk status value is encountered, if the blocking identifier is active—for example, if the risk level corresponding to a certain risk dimension reaches a preset threshold, or the matching type returned by the dimension check belongs to a specific type that triggers blocking—the transaction instance immediately determines that the compliance verification fails. This risk status value is the specified risk status value in the multi-dimensional risk screening results that triggers blocking. Thus, through this implementation process, compliance verification can be completed at the transaction submission stage using the risk status data already acquired and embedded in the global context object during the pre-identification stage, without triggering new backend interface calls. The verification result is obtained instantly, avoiding the latency and timing coupling problems caused by compliance checks relying on dynamic interface calls during the transaction phase.

[0050] After a transaction instance determines a specified risk status value, it further determines the corresponding preset risk dimension. This preset risk dimension is the specific risk category corresponding to the risk status value generated during the pre-identification phase, such as a blacklist matching dimension, account control status dimension, or customer risk level dimension. Subsequently, the transaction instance generates a corresponding prompt message based on this preset risk dimension. This prompt message includes the blocking reason for that risk dimension, such as "[This customer is blacklisted, number XXX, business processing is restricted]", "[This account is frozen and cannot process transactions]", or "[This customer's risk level is level 4, triggering high-risk blocking]". The transaction instance will return this prompt message to the transaction interface for display. Tellers do not need to passively learn the reason for non-compliance through transaction error blocking; instead, they can clearly understand the specific blocking basis when the transaction is submitted. If a business blocking is triggered, the transaction processing system will simultaneously pop up a blocking pop-up window to clearly inform the teller of the blocking reason and terminate the execution of the current business transaction. The teller can then decide on subsequent handling strategies, such as guiding the customer to other channels or providing supplementary materials. In this way, through this implementation process, the compliance check results are output definitively before the transaction is executed. The screening logic and business logic are decoupled at the code level, and the reasons for the blockage can be accurately traced to specific risk dimensions and check items. Tellers do not need to wait for dynamic queries in the middle of the transaction to know the reasons for the blockage, thus improving the certainty and controllability of the overall transaction processing system.

[0051] For example, suppose a teller is processing a transfer for customer G. The transaction instance traversal risk screening results show that the blocking flag in the "Account Control Status" dimension is active. The teller determines that the specified preset risk dimension is an account control check, generates a prompt message "This account is under non-payment control status and cannot process transfer transactions," and returns to the transaction interface to pop up a blocking pop-up. The teller immediately informs the customer that the account is abnormal and suggests that they go to the opening bank to verify. The entire process does not require waiting for a real-time query response from the backend interface.

[0052] Optionally, in this embodiment, the method further includes: when receiving a service termination instruction initiated by a teller, reading all print messages associated with the session identifier, generating a print task list including all print messages, and displaying all print messages in the print interface in the order of transaction execution; sequentially retrieving the print data corresponding to each print message, and batch submitting the print data corresponding to all print messages to the printing device for batch printing operation; during the printing process of the printing device, continuously monitoring the status of each print message in the print task list, including pending, processing, completed, and failed status; for print messages with a failed status, generating a retry prompt pop-up window, and in response to the teller's confirmation operation on the retry prompt pop-up window, re-executing the printing operation for the print messages with a failed status.

[0053] In this embodiment, after completing all transactions for the current customer, the teller clicks the "End Service" button to initiate an end-of-service instruction. The session manager in the transaction processing system receives this instruction and enters the session termination phase. Specifically, the session manager first sends a batch printing instruction to the print queue manager in the transaction processing system. The print queue manager is a dedicated component responsible for managing the storage, scheduling, and execution of print tasks. Upon receiving this instruction, it triggers a database query operation. The print queue manager reads all print messages associated with the current session identifier from the database. These print messages are generated and stored in the database after each transaction is completed during the business processing phase. Each print message includes complete print data such as the corresponding transaction details, customer information, amount, and voucher number. The print queue manager generates a list of pending print tasks from all the read print messages and displays this list in a unified printing interface, such as a front-end interface built based on the UniPrint.vue component, sorted according to the transaction execution time. The teller can preview the summary information of all pending print vouchers for this session on this interface. In this way, the printing task is decoupled from the transaction execution process during the business processing phase. Tellers no longer need to wait for the printing device to finish printing after each transaction. The triggering point for the printing operation is delayed until the end of the session for unified execution. The centralized display of the printing task list allows tellers to have a comprehensive understanding of the printing tasks for the current session, avoiding process breaks and repetitive operations caused by scattered printing in the traditional model. For example, after a teller completes two transactions for a customer, namely a deposit and a transfer, and clicks "End Service," the transaction processing system reads the two printing messages for this customer's current session from the database and lists the deposit voucher and transfer voucher in transaction order on the unified printing interface for the teller to confirm.

[0054] The print queue manager retrieves the print data corresponding to each print message in the pending print task list from the database, including paper print data and electronic voucher print data. Paper print data is used for counter paper voucher output, while electronic voucher print data is used for electronic archiving or customer electronic receipts. The print queue manager uses batch print submission methods, such as `printData(allViewData, elecData)`, to batch submit all corresponding paper print data and electronic voucher print data to the printing device for batch printing. During the printing process, the print queue manager continuously monitors the status of each print message in the pending print task list. This status includes pending, processing, completed, and failed. Pending indicates the print task has entered the queue but has not yet started printing; processing indicates the printing device is executing the print output for that task; completed indicates the printing device has successfully completed the print output for that task; and failed indicates the task failed to print due to an exception, such as printer offline, configuration error, paper shortage, or device malfunction. The print queue manager uses atomic operation features, such as ES6 atomic operations, to ensure the safety of queue operations and avoid data race issues during concurrent multi-task processing. In this way, batch submission reduces the number of device switches between paper printing and electronic voucher printing. Real-time tracking of print task status allows the system to accurately monitor the printing progress of each voucher, providing reliable status information for handling anomalies. Simultaneously, printing operations are centralized and executed at the end of the session, eliminating the dependence of individual transactions on the printing device's response speed, allowing for a continuous and smooth transaction flow. For example, the print queue manager submits the print data for customer Xin's deposit and transfer vouchers to the printer at once. The transaction processing system tracks and displays the deposit voucher status as "Completed" and the transfer voucher status as "Processing" in real time, allowing tellers to clearly understand the current printing progress from the interface.

[0055] During the printing process, when the print queue manager detects that a print message has changed to "Failed," such as due to a temporary printer offline or running out of paper, the transaction processing system immediately generates a retry prompt pop-up and displays it on the teller's interface. This pop-up includes a reason for the failure, such as "Printer offline, please check device status" or "Out of paper, please replenish paper." After troubleshooting according to the prompts, the teller confirms the retry prompt by clicking the "Retry" button. In response to this confirmation, the print queue manager re-reads the print message corresponding to the failed status from the database and re-executes the printing operation for that message. Tellers can also manually cancel specific print jobs in the unified printing interface. For example, if a customer does not need a paper copy of a transaction, the canceled job will be removed from the pending print job list and will no longer participate in subsequent batch printing or retry processes. In this way, the exception handling mechanism ensures that temporary printer malfunctions do not block the entire session or cause data loss. Tellers can quickly initiate retries after troubleshooting, and task status tracking ensures that only failed tasks are retried, eliminating the need to reprint all vouchers. This effectively improves the system's fault tolerance and operational flexibility. For example, if the printer runs out of paper while a teller is printing customer Xin's transfer voucher, the transaction processing system marks the voucher as "failed" and displays a pop-up message: "Out of paper, please refill paper." After the teller refills the paper and clicks "Retry," the print queue manager rereads the transfer voucher's print message from the database and successfully completes the printing, while the already printed deposit vouchers remain unaffected.

[0056] Optionally, in this embodiment, the method further includes: initializing a data collector when the current customer session starts, and collecting and recording multi-dimensional data related to transactions throughout the entire lifecycle of the current customer session; during transaction processing, using the data collector to collect data on communication requests and responses between the counter system and external systems to obtain system header data, application header data, communication return data, business processing data, and transaction result data. The system header data includes at least a system serial number, request initiation timestamp, service system number, and requester network address; the application header data includes at least a transaction code, teller identification number, customer service serial number, and institution number; the communication return data includes at least a return code and core system serial number; the business processing data includes at least a financial transaction flag and business status code; and the transaction result data includes at least the transaction completion time and transaction data message. The data collector encapsulates the collected data into a log data object with a key-value pair storage structure according to preset field name mapping rules and data type conversion rules. When generating the log data object, the numeric fields in various types of data are converted to string types, and the date fields in various types of data are converted to string types. The method converts segments into date strings in a predetermined format and converts boolean fields in various types of data into predetermined character identifiers. Correspondingly, the method also includes: for communication operations generated in the current customer session, identifying the communication flag and core serial number field of the communication operation; when the communication flag is identified as active and the core serial number field is not empty, calling the first data writing method based on the data collector to write the communication record generated by the communication operation into the first database table; after detecting successful writing to the first database table, generating a pre-embedded data record containing the session identifier, customer number, and data collection timestamp, and calling the second data writing method based on the data collector to write the pre-embedded data record into the second database table; and after detecting the completion of the current business transaction, calling the third data writing method based on the data collector to batch write the transaction result data generated by the current business transaction into the third database table; and / or, during the execution of data collection and writing operations, continuously detecting whether a data access exception occurs based on the data collector, and generating an error log including error code, exception stack information, and data content when a data access exception is detected, and returning error data to the teller based on the exception callback method called by the data collector.

[0057] In this embodiment, the transaction processing system initializes the data collector upon the start of the current customer session. The data collector is a standardized component used to collect and record multi-dimensional transaction-related data throughout the entire process. It adopts an event-driven model and intercepts key node data using AOP (Aspect-Oriented Programming) technology, continuously operating throughout the entire lifecycle of the current customer session. During business transaction processing, the data collector collects data on every communication request and response between the counter system and external systems such as the online verification system, customer information management system, and core business system. The collected data includes system header data, application header data, communication return data, business processing data, and transaction result data. Specifically, the system header data includes an auto-incrementing system serial number SYS_FLON_NO, a request initiation timestamp REQE_TM accurate to milliseconds, a service system number SERV_SYS_NO, and the requester's network address CHANNELIP. The application header data includes the transaction code TRADECODE, teller ID TELLERID, customer service serial number ServerFlow, and institution number BRANCHNUM. The communication return data includes the return code RETCODE, which identifies the transaction processing result status, and the core system serial number CORESEQNO. Business processing data includes the financial transaction flag ISFINANCIAL, the business status code BIZSTAT, the payment account screening status PYRBIZ, and the receiving account screening status PYEBIZ. The financial transaction flag ISFINANCIAL has a value of 0 indicating a non-financial transaction and 1 indicating a financial transaction. The business status code BIZSTAT includes statuses such as terminated, processing, and successful posting. The payment account screening status PYRBIZ and the receiving account screening status PYEBIZ have values ​​of 0 indicating a blacklist, 1 indicating a graylist, and 2 indicating neither a blacklist nor a graylist, respectively. Transaction result data includes the transaction completion time ENDTIME, the voucher number VCHNO, and the transaction data message TRADEDATA. In this way, through this implementation process, data collection covers the complete data link from the communication layer to the business layer, and all transaction-related status changes, interface round-trip data, and exception return codes are recorded in a standardized manner. For example, when a teller processes a transfer transaction of 50,000 yuan for customer Ren, the data collector automatically collects all the data for that transaction, including the system serial number, initiation timestamp, transaction code, teller number, return code, core serial number, financial transaction flag, business status, and transaction completion time.

[0058] The data collector encapsulates the collected data into a key-value pair storage structure, i.e., a Map, according to preset field name mapping rules and data type conversion rules.<String, String> The log data objects are structured as follows. When generating log data objects, the transaction processing system performs a unified type conversion. Specifically, numeric fields in various data types are converted to string types, for example, amount [100.50] is converted to the string [100.50]; date fields in various data types are converted to date strings in a predefined format, such as YYYYMMDD; and boolean fields in various data types are converted to predefined character identifiers, for example, boolean value true is converted to [Y], and false is converted to [N]. All log data field names follow a preset specification. For example, [SERV_SYS_NO] represents the service system number, [REQE_DT] represents the request date in YYYYMMDD format, and [REQE_TM] represents the request time in HHMMSSmmm format, accurate to milliseconds. Through this process, the collected data forms standardized log data with a unified structure, standardized fields, and consistent types, providing a unified data foundation for subsequent data analysis, transaction reconstruction, and decision support. For example, the data collector encapsulates the above transfer transaction data into a Map structure of {"JOURNALID":"2026072100000168097","TRANCODE":"710010","TELLERID":"T0001","BIZSTAT":"1","ISFINANCIAL":"1","ENDTIME":"20260721"}, with field names and value formats conforming to preset specifications.

[0059] The data collector performs data writing operations according to a hierarchical reporting strategy. For communication operations generated in the current client session, the transaction processing system identifies the communication flag and core serial number field of the communication operation. The communication flag is represented by the MainCmmSymb field, which identifies whether the communication is a main communication that needs to be recorded; the core serial number field is represented by the CORESEQNO field. When the communication flag is identified as active, for example, with a value of [Y], and the core serial number field is not empty, the data collector calls the first data writing method, such as the LogicletUtil.invoke(logmasterInCommunication) method, to write the communication record generated by the current communication operation to the first database table. The first database table can be the AB_PUB_TRANSDTL table, which is the communication serial number table, used to record the details of each communication with external systems. After successfully writing to the first database table, the transaction processing system generates a pre-embedded data record of type

AB_PUB_DATATRACKING

AB_PUB_DATATRACKING

[0060] During data acquisition and writing operations, the data collector continuously monitors for data access exceptions, such as SQLException (database connection exception) or IOException (input / output exception). Upon detecting a data access exception, the transaction processing system uses a try-catch-finally block to catch the exception, generating an error log containing the error code, exception stack trace, and data content. This log records the specific location and context of the error. The system then calls an exception callback method (e.g., `callback.handleException()`) to return the error data to the caller, ensuring that even if an exception occurs during data acquisition, it will not disrupt the normal execution of the core transaction process. This implementation isolates data acquisition from core business logic at the exception handling level. Failures in the data acquisition phase will not affect the normal completion of business transactions, while the complete error log provides maintenance personnel with traceable evidence for troubleshooting, effectively ensuring the system's reliability and maintainability. For example, if the database connection suddenly times out during the data collection process of a transaction, the data collector will catch the SQLException and record an error log containing the error code, stack information and collected data. It will then call the callback method to return the error data "Data collection failed" to the teller's interface. However, the transfer transaction itself has already been recorded, and the core business is not affected.

[0061] In practical applications, since this embodiment involves a large amount of data of different types, the global context object in this embodiment can be represented by GlobalContextObject. GlobalContextObject uses a tree structure for data organization, and the specific data structure can be as follows: Figure 3As shown, the global context object serves as the root node of the data structure. Its first-level child nodes include two core sections: UserInfo (basic session information) and CustomerInfo (basic customer information). The UserInfo section records the user string "userName", the role string "role", the user level string "userLevel", and the customer identification serial number. This serial number is a string composed of the year, month, day, a seven-digit sequential number, and a system number. It also records the teller's permission string "tellerAbility", the teller's job number string "userPostNum", and the teller's job name string "userPostName". Furthermore, it can record the teller's teller ID, name, and affiliated institution number, as well as the session start timestamp accurate to the second. The UserInfo section of the basic session information is further linked to the taskInfo object, which contains core fields: transaction number (busFlwNo), transaction code (tradeCode), transaction name (tradeName), user name (usrNam), teller number (txTlr), and authorization result description (athRslDes). Specifically, the transaction number (busFlwNo) is a string used to uniquely identify the transaction record; the transaction code (tradeCode) is a string identifying the specific transaction type; the transaction name (tradeName) is a string recording the transaction's business name description; the user name (usrNam) is a string recording the user's name that performed the task; the teller number (txTlr) is a string identifying the teller's ID number that processed the transaction; and the authorization result description (athRslDes) is a string used to record the status information or descriptive content of the transaction authorization process.

[0062] The CustomerInfo section of the customer basic information includes the following strings: customerId (customer ID), customerName (customer Name), document type (idType), document number (idNumber), customer type (customerType), risk level (riskLevel), boolean value indicating whether it is an agent (isAgent), and document identification timestamp (identificationTime). The customerId string is an 18-digit number; the customerType string is 1 for private customers and 2 for corporate customers. The CustomerInfo section further associates with the RiskAlert object as a second-level child node, used to store multi-dimensional risk screening results. Specific fields include: Anti-money laundering self-check result (CheckFXQself), fraudster marker (isSwindler), anti-money laundering marker (isAntiMoney), blacklist marker (isBlackList), expired document marker (ctfExpired), underage marker (isUnderAge), one-time customer marker (dispCustFlg), and customer information integrity warning (cstlnfolntactWarn).

[0063] Building upon the core data structures described above, the global context object further extends to store the print task queue. This queue stores a task identifier in a universally unique identifier format, a transaction serial number string, an integer value for the voucher type, an integer value for the number of copies to be printed, priority levels one through five, and an index string pointing to the print messages stored in the database, as well as historical business processing information.

[0064] In summary, the system architecture of the transaction processing system in this embodiment is as follows: Figure 4As shown, the transaction processing system architecture is divided into a business logic layer, an external system layer, and a front-end interaction layer. The business logic layer includes a session manager, while core service components integrate a data collector, a risk screening module, a pre-identification engine, a business transaction processor, and a print queue manager. The data collector collects system headers, application headers, business status, and transaction results throughout the process and reports them to the big data analysis platform in the external system layer. The risk screening module performs multi-dimensional risk checks and generates risk screening results. The pre-identification engine calls external systems to complete customer identity verification and information retrieval. The business transaction processor handles specific counter business transactions and interfaces with the print queue manager and the external system interface gateway in the business logic layer. Specifically, the print queue manager manages the storage, delayed execution, and batch printing of transaction print messages, while the external system interface gateway uniformly encapsulates communication calls with external systems. The global context object, as an in-memory data structure in the business logic layer, stores customer data, risk status, and business context information during the session, allowing all components to share and access it.

[0065] The external system layer includes multiple heterogeneous back-end systems that interface with the counter system, including a network verification system, a customer information management system, printing equipment, a blacklist system, and a big data analysis platform.

[0066] The front-end interaction layer is used to provide teller operation interface, customer reminder panel and unified printing interface on the front end, and to display the print task list at the end of the session and allow tellers to perform batch printing operations.

[0067] The logical process of the technical solution in this application embodiment is summarized as follows: Figure 5 As shown, after detecting a teller's login, the global context object is initialized. After the teller triggers the start service command, the customer pre-identification stage begins. This stage simultaneously performs basic information queries and risk screening using a parallel execution method. After both operations are completed in parallel, the results of the basic information query and risk screening are written to the global context object. Then, the business processing loop begins. After the teller selects a specific business transaction, the pre-stored customer information is automatically read from the global context object and populated into the transaction interface. The teller completes the transaction by adding specific transaction information. After the transaction is completed, the print jobs generated by this transaction are queued and stored. At this point, it is determined whether to continue to the next transaction or end the service. If to continue to the next transaction, the process returns to the selected transaction step and repeats the above process; if to end the service, the business processing loop is exited. After the service ends, a unified batch printing is triggered, executing all print jobs associated with this session. Data reporting then collects and persistently stores the entire session's data. Finally, customer data is destroyed and session resources are released, ending the process.

[0068] The method provided in this application constructs an association between a global context object and a session identifier. Before a transaction starts, it sequentially calls multiple data interfaces to centrally complete the multi-dimensional pre-acquisition of customer information. This decouples the information query action from the internal call chain of a single transaction, avoiding the instantaneous load peaks and timeout risks caused by the concentration of backend interface calls at the transaction submission moment. Simultaneously, since customer identity verification information and multi-dimensional risk screening results are written into the global context object during the session initialization phase, the status fields upon which compliance verification depends are ready before transaction execution. This eliminates the reliance on dynamic interface calls during the transaction, decoupling the screening logic from the business logic at the code level and ensuring the temporal independence of compliance checks. Furthermore, the global context object continuously stores and shares customer-related information throughout the entire session lifecycle. Transaction instances directly read pre-filled information from this global context object without repeated card swiping and queries in each transaction, reducing redundant consumption of network and system resources. Moreover, the customer information read by each transaction within the same session originates from the same shared data, avoiding data inconsistencies caused by different query times, thus improving overall processing efficiency and intelligence.

[0069] Furthermore, as Figure 1 To specifically implement the method, this application provides a session-based transaction processing apparatus, such as... Figure 6 As shown, the device includes: a creation module 601, a writing module 602, a reading module 603, a checking module 604, and an execution module 605.

[0070] The creation module 601 is used to create a global context object when a teller performs a login operation, and to start the current customer session, generate a session identifier and associate it with the global context object when a start service instruction initiated by the teller is received. The writing module 602 is used to sequentially call multiple data interfaces to obtain customer-related information, and write the customer-related information into the global context object according to a preset data structure, so that the global context object continuously stores and shares the customer-related information throughout the entire lifecycle of the current customer session. The customer-related information includes customer identity verification information, customer basic information, and multi-dimensional risk screening results. The reading module 603 is used to respond to the teller's selection operation for the current business transaction, create a transaction instance corresponding to the current business transaction, call the transaction instance to read the customer's basic information from the global context object and populate it into the transaction interface; The inspection module 604 is used to execute the business logic of the current business transaction when it receives the transaction submission instruction initiated by the teller, and read the customer identity verification information and the multi-dimensional risk screening results from the global context object during the execution process to perform compliance verification, and execute the current business transaction if the compliance verification is passed; The execution module 605 is used to store the print message generated by the execution of the current business transaction into the print queue associated with the session identifier after detecting that the current business transaction has been completed, so as to complete the transaction processing of this round.

[0071] In a specific application scenario, the writing module 602 is used to call a data interface for interfacing with the online verification system, send a verification request including document type and document number to the online verification system, and receive the customer identity verification result returned by the online verification system based on the verification request; call a data interface for interfacing with the customer information management system, send a query request including customer number to the customer information management system, and receive the customer basic information returned by the customer information management system based on the query request; call a risk screening module to sequentially perform checks on multiple preset risk dimensions, obtain risk status values ​​obtained on each preset risk dimension, obtain multiple risk status values, and summarize the multiple risk status values ​​into a single value. The multi-dimensional risk screening results are described; the global context object is constructed, and the customer identity verification results are written as the first type of data into the customer basic information partition of the global context object, the customer basic information is written as the second type of data into the customer basic information partition, and the multi-dimensional risk screening results are written as the third type of data into the risk status partition of the global context object. The global context object maintains the customer basic information partition and the risk status partition in memory using a key-value pair storage structure, and the global context object remains accessible to all business transaction instances within the current customer session throughout the entire lifecycle of the current customer session until it is uniformly destroyed when the current customer session ends.

[0072] In a specific application scenario, the writing module 602 is used to call the risk screening module, so that the risk screening module calls the interface of the customer information management system class through the first communication service component to perform checks related to the customer information among the multiple preset risk dimensions. These checks include: a suspected customer identification check by passing the document type and document number to the suspected customer query interface and receiving the returned "suspect" identifier; a customer risk level check by passing the customer number to the customer information query interface and extracting the risk level field value from the returned customer information data; a regional risk check by obtaining the customer region code from the global context object and passing the region code to the region risk check interface to receive the returned region risk level value; and a list matching check by passing the document number to the blacklist check interface and receiving the returned list matching type and list number. The risk screening module is also called, so that the risk screening module calls the interface of the core system class through the second communication service component to perform the multiple preset risk dimensions checks. The checks related to the account information in the pre-defined risk dimensions include: account management checks (passing the account to the account anomaly status query interface and receiving the returned account payment and collection control status, passing the account to the account freeze query interface and receiving the returned freeze status identifier), and credit limit status checks (passing the account to the credit limit query interface and receiving the returned cumulative remaining credit limit value). After each pre-defined risk dimension check is completed, the risk status values ​​returned by each pre-defined risk dimension check are collected uniformly using a result collection method, generating a structured reminder information list including the risk status values ​​of each pre-defined risk dimension check. The structured reminder information list is pushed to the customer reminder interface of the counter system for display. Each reminder information item in the structured reminder information list includes a reminder title, reminder text content, blocking identifier, and target transaction interface identifier. The risk status values ​​returned by each pre-defined risk dimension check are integrated to obtain the multi-dimensional risk screening result.

[0073] In a specific application scenario, the inspection module 604, in response to the transaction submission instruction, reads the customer identity verification information from the customer basic information partition of the global context object and the multi-dimensional risk screening result from the risk status partition of the global context object, based on the transaction instance of the current business transaction; based on the transaction instance, it sequentially traverses the blocking identifiers associated with each risk status value in the multi-dimensional risk screening result according to a preset verification order, and determines that the compliance verification is passed if it is determined that the blocking identifiers associated with each risk status value in the multi-dimensional risk screening result are not in an effective state; based on the transaction instance, it obtains the transaction-specific information supplemented by the teller in the transaction interface, assembles the transaction-specific information and the customer basic information read from the global context object into a transaction request message; and sends the transaction request message to the core business system through the external system interface gateway, which executes and returns the transaction processing result.

[0074] In specific application scenarios, the inspection module 604 is further configured to determine that compliance verification fails when the blocking identifier associated with the specified risk status value in the multidimensional risk screening result is in an effective state. The specified risk status value is any risk status value in the multidimensional risk screening result. The module also determines the specified preset risk dimension corresponding to the specified risk status value, generates a prompt message including the blocking reason corresponding to the specified preset risk dimension, and returns the prompt message to the transaction interface to terminate the execution of the current business transaction.

[0075] In specific application scenarios, the device further includes: The printing module is used to, upon receiving a service termination instruction initiated by the teller, read all print messages associated with the session identifier, generate a list of printable tasks including all print messages, and display all print messages in the print interface in order of transaction execution; sequentially retrieve the print data corresponding to each print message, and submit the print data corresponding to all print messages in batches to the printing device for batch printing operation; during the printing process of the printing device, continuously monitor the status of each print message in the list of printable tasks, including pending, processing, completed, and failed; for print messages with a failed status, generate a retry prompt pop-up, and in response to the teller's confirmation of the retry prompt pop-up, re-execute the printing operation for the print messages with a failed status.

[0076] In specific application scenarios, the device further includes: The data acquisition module is used to initialize the data collector when the current customer session starts, and to collect and record multi-dimensional transaction-related data throughout the entire lifecycle of the current customer session. During transaction processing, the data collector is used to collect data on communication requests and responses between the counter system and external systems, obtaining system header data, application header data, communication return data, business processing data, and transaction result data. The system header data includes at least the system serial number, request initiation timestamp, service system number, and requester network address. The application header data includes at least the transaction code, teller identification number, and customer service record. The communication return data includes at least a return code and a core system serial number; the business processing data includes at least a financial transaction flag and a business status code; and the transaction result data includes at least the transaction completion time and the transaction data message. The data collector encapsulates the collected data into log data objects with a key-value pair storage structure according to preset field name mapping rules and data type conversion rules. When generating the log data objects, numeric fields in various types of data are converted to string types, date fields in various types of data are converted to date strings in a predetermined format, and boolean fields in various types of data are converted to predetermined character identifiers. Accordingly, the data acquisition module is further configured to: identify the communication flag and core serial number field of the communication operation generated in the current customer session; when the communication flag is identified as active and the core serial number field is not empty, write the communication record generated by the communication operation into a first database table by calling a first data writing method based on the data collector; after detecting successful writing to the first database table, generate a pre-embedded data record containing the session identifier, customer number, and data acquisition timestamp, and write the pre-embedded data record into a second database table by calling a second data writing method based on the data collector; and after detecting that the current business transaction has been completed, write the transaction result data generated by the current business transaction into a third database table in batches by calling a third data writing method based on the data collector; and / or, during the execution of data acquisition and writing operations, continuously detect whether a data access exception occurs based on the data collector, and if the data access exception is detected, generate an error log including error code, exception stack information, and data content, and return error data to the teller by calling an exception callback method based on the data collector.

[0077] The apparatus provided in this application establishes an association between a global context object and a session identifier. Before a transaction is initiated, it sequentially calls multiple data interfaces to centrally pre-acquire multi-dimensional customer information. This decouples the information query action from the internal call chain of a single transaction, avoiding instantaneous load spikes and timeout risks caused by concentrated backend interface calls at the transaction submission moment. Simultaneously, since customer identity verification information and multi-dimensional risk screening results are written into the global context object during the session initialization phase, the status fields upon which compliance verification depends are ready before transaction execution. This eliminates the need for compliance checks to rely on dynamic interface calls during the transaction, decoupling the screening logic from the business logic at the code level and ensuring the temporal independence of compliance checks. Furthermore, the global context object continuously stores and shares customer-related information throughout the entire session lifecycle. Transaction instances directly read pre-filled information from this global context object without repeated card swiping and queries in each transaction, reducing redundant consumption of network and system resources. Moreover, the customer information read by each transaction within the same session originates from the same shared data, avoiding data inconsistencies caused by different query times, thus improving overall processing efficiency and intelligence.

[0078] It should be noted that other corresponding descriptions of the functional units involved in the session-based transaction processing apparatus provided in this application embodiment can be found by referring to... Figures 1 to 5 The corresponding description in [the document] will not be repeated here.

[0079] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0080] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0081] The above embodiments and the technical features in the embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0082] The embodiments described above are merely examples of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these modifications and improvements all fall within the protection scope of this application.

[0083] In an exemplary embodiment, see Figure 7 The system also provides an electronic device comprising a bus 701, a processor 702, a memory 703, and a communication interface 704. It may also include an input / output interface 705 and a display device 706. The various functional units can communicate with each other via the bus. The memory 703 stores a computer program, which, from bottom to top, includes a kernel 7034 that directly manages the hardware, middleware 7033 that provides general services for applications, an application programming interface 7032 that defines calling specifications, and an application 7031 that implements specific business logic. The processor 702 is used to read from the memory 703 via the bus 701 and execute the program stored in the memory, performing the session-based transaction processing method described in the above embodiments.

[0084] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the session-based transaction processing method.

[0085] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented in hardware or by using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) and includes several instructions to cause a computer device (such as a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0086] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing this application.

[0087] Those skilled in the art will understand that the modules in the apparatus of the implementation scenario can be distributed within the apparatus of the implementation scenario as described, or they can be located in one or more apparatuses different from this implementation scenario, with corresponding changes. The modules of the above-described implementation scenario can be combined into one module, or they can be further divided into multiple sub-modules.

[0088] The serial numbers in this application are for descriptive purposes only and do not represent the superiority or inferiority of the implementation scenario.

[0089] The above disclosures are only a few specific implementation scenarios of this application. However, this application is not limited to these. Any variations that can be conceived by those skilled in the art should fall within the protection scope of this application.

Claims

1. A session-based transaction processing method, characterized in that, include: When a teller is detected to be performing a login operation, a global context object is created. Upon receiving a start service instruction initiated by the teller, the current customer session is started, a session identifier is generated, and associated with the global context object. Multiple data interfaces are called sequentially to obtain customer-related information. The customer-related information is written into the global context object according to a preset data structure so that the global context object continuously stores and shares the customer-related information throughout the entire lifecycle of the current customer session. The customer-related information includes customer identity verification information, customer basic information, and multi-dimensional risk screening results. In response to the teller's selection operation for the current business transaction, a transaction instance corresponding to the current business transaction is created, and the transaction instance is called to read the customer's basic information from the global context object and populate it into the transaction interface; Upon receiving a transaction submission instruction initiated by the teller, the business logic of the current business transaction is executed. During the execution process, the customer identity verification information and the multi-dimensional risk screening results are read from the global context object for compliance verification. If the compliance verification is successful, the current business transaction is executed. Once the current business transaction is detected to be completed, the print message generated by the current business transaction is stored in the print queue associated with the session identifier to complete the transaction processing for this round.

2. The method according to claim 1, characterized in that, The process of sequentially calling multiple data interfaces to obtain customer-related information and writing the customer-related information into the global context object according to a preset data structure includes: Call the data interface used to interface with the online verification system, send a verification request including document type and document number to the online verification system, and receive the customer identity verification result returned by the online verification system with reference to the verification request; Call the data interface used to interface with the customer information management system, send a query request including the customer number to the customer information management system, and receive the customer basic information returned by the customer information management system with reference to the query request; The risk screening module is invoked to sequentially perform checks on multiple preset risk dimensions and obtain the risk status value obtained on each preset risk dimension, resulting in multiple risk status values. The multiple risk status values ​​are then summarized into the multidimensional risk screening result. The global context object is constructed, and the customer identity verification result is written as the first type of data into the customer basic information partition of the global context object. The customer basic information is written as the second type of data into the customer basic information partition, and the multi-dimensional risk screening result is written as the third type of data into the risk status partition of the global context object. The global context object maintains the customer basic information partition and the risk status partition in memory using a key-value pair storage structure. The global context object remains accessible to all business transaction instances within the current customer session throughout its entire lifecycle, until it is uniformly destroyed when the current customer session ends.

3. The method according to claim 2, characterized in that, The risk screening module sequentially performs checks on multiple preset risk dimensions and obtains risk status values ​​on each preset risk dimension, resulting in multiple risk status values. These multiple risk status values ​​are then summarized into the multidimensional risk screening result, including: The risk screening module is invoked so that it calls the interface of the customer information management system class through the first communication service component to perform checks related to the customer information among the multiple preset risk dimensions. The checks related to the customer information include: a suspected customer identification check by passing the document type and document number to the suspected customer query interface and receiving the returned whether it is a suspected identifier; a customer risk level check by passing the customer number to the customer information query interface and extracting the risk level field value from the returned customer information data; a regional risk check by obtaining the customer region code from the global context object and passing the region code to the regional risk check interface to receive the returned regional risk level value; and a list matching check by passing the document number to the blacklist check interface and receiving the returned list matching type and list number. The risk screening module is invoked so that it calls the interface of the core system class through the second communication service component to perform the checks related to the account information among the multiple preset risk dimensions. The checks related to the account information include account management checks that pass the account to the account abnormal status query interface and receive the returned account payment and receipt control status, and account management checks that pass the account to the account freeze query interface and receive the returned freeze status identifier, and limit status checks that pass the account to the limit query interface and receive the returned cumulative remaining limit value. After the checks of each of the preset risk dimensions are completed, the risk status values ​​returned by the checks of each preset risk dimension are collected in a unified manner through the result collection method. A structured reminder information list including the risk status values ​​of the checks of each preset risk dimension is generated. The structured reminder information list is pushed to the customer reminder interface of the counter system for display. Each reminder information item in the structured reminder information list includes a reminder title, reminder text content, blocking icon and target transaction interface icon. The risk status values ​​returned from the checks of each of the preset risk dimensions are integrated to obtain the multidimensional risk screening result.

4. The method according to claim 1, characterized in that, Upon receiving a transaction submission instruction initiated by the teller, the process of executing the business logic of the current business transaction, and during execution, reading the customer identity verification information and the multi-dimensional risk screening results from the global context object for compliance verification, and executing the current business transaction if the compliance verification passes, includes: In response to the transaction submission instruction, based on the transaction instance of the current business transaction, the customer identity verification information is read from the customer basic information partition of the global context object, and the multi-dimensional risk screening result is read from the risk status partition of the global context object; Based on the transaction instance, the blocking identifiers associated with each risk status value in the multi-dimensional risk screening result are sequentially traversed according to the preset verification order. If it is determined that the blocking identifiers associated with each of the risk status values ​​in the multi-dimensional risk screening result are not in an effective state, the compliance verification is determined to be successful. Based on the transaction instance, obtain the transaction-specific information supplemented by the teller in the transaction interface, and assemble the transaction-specific information with the customer basic information read from the global context object into a transaction request message; The transaction request message is sent to the core business system by calling the core business system interface through the external system interface gateway. The core business system then executes the request and returns the transaction processing result.

5. The method according to claim 4, characterized in that, The method further includes: If it is determined that the blocking identifier associated with the specified risk status value in the multidimensional risk screening result is in an effective state, the compliance verification is determined to fail, and the specified risk status value is any risk status value in the multidimensional risk screening result; Determine the specified preset risk dimension corresponding to the specified risk status value, generate a prompt message including the blocking reason corresponding to the specified preset risk dimension, and return the prompt message to the transaction interface to terminate the execution of the current business transaction.

6. The method according to claim 1, characterized in that, The method further includes: When the teller initiates a service termination instruction, all print messages associated with the session identifier are read, a print task list including all print messages is generated, and all print messages included in the print task list are displayed in the print interface in the order of transaction execution. The printing data corresponding to each of the printed messages is retrieved sequentially, and the printing data corresponding to all the printed messages is submitted to the printing device in batches to perform batch printing operations. During the printing process of the printing device, the status of each print message in the list of printable tasks is continuously monitored, and the status includes pending, processing, completed, and failed. For a print message with a failed status, a retry prompt pop-up is generated, and in response to the teller's confirmation of the retry prompt pop-up, the printing operation for the print message with a failed status is re-executed.

7. The method according to claim 1, characterized in that, The method further includes: When the current customer session starts, the data collector is initialized, and throughout the entire lifecycle of the current customer session, the data collector collects and records multi-dimensional data related to transactions. During the transaction processing, the data collector is used to collect data on communication requests and responses between the counter system and external systems, obtaining system header data, application header data, communication return data, business processing data, and transaction result data. The system header data includes at least the system serial number, request initiation timestamp, service system number, and requester network address. The application header data includes at least the transaction code, teller identification number, customer service serial number, and institution number. The communication return data includes at least the return code and core system serial number. The business processing data includes at least the financial transaction flag and business status code. The transaction result data includes at least the transaction completion time and transaction data message. The data collector encapsulates the collected data into log data objects with a key-value pair storage structure according to preset field name mapping rules and data type conversion rules. When generating the log data objects, the numeric fields in the data are converted into string types, the date fields in the data are converted into date strings in a predetermined format, and the boolean fields in the data are converted into predetermined character identifiers. Accordingly, the method further includes: For communication operations generated in the current customer session, the communication flag and core serial number field of the communication operation are identified. When the communication flag is found to be active and the core serial number field is not empty, the communication record generated by the communication operation is written to the first database table by calling the first data writing method based on the data collector. After successfully writing to the first database table, a pre-embedded data record containing the session identifier, customer number, and data collection timestamp is generated. The pre-embedded data record is written to the second database table by calling the second data writing method based on the data collector. And after the current business transaction is detected to be completed, the transaction result data generated by the current business transaction is written to the third database table in batches by calling the third data writing method based on the data collector; and / or, During the data collection and writing process, the data collector continuously detects whether a data access exception occurs. If the data access exception is detected, an error log including error code, exception stack information and data content is generated. The exception callback method is called based on the data collector to return the error data to the teller.

8. A session-based transaction processing apparatus, characterized in that, include: A creation module is used to create a global context object when a teller performs a login operation, and to start the current customer session, generate a session identifier and associate it with the global context object when a start service instruction is received from the teller. The writing module is used to sequentially call multiple data interfaces to obtain customer-related information, and write the customer-related information into the global context object according to a preset data structure, so that the global context object continuously stores and shares the customer-related information throughout the entire lifecycle of the current customer session. The customer-related information includes customer identity verification information, customer basic information, and multi-dimensional risk screening results. The reading module is used to respond to the teller's selection operation for the current business transaction, create a transaction instance corresponding to the current business transaction, call the transaction instance to read the customer's basic information from the global context object and populate it into the transaction interface; The inspection module is used to execute the business logic of the current business transaction when it receives the transaction submission instruction initiated by the teller, and read the customer identity verification information and the multi-dimensional risk screening results from the global context object during the execution process to perform compliance verification, and execute the current business transaction if the compliance verification is passed; The execution module is used to store the print message generated by the execution of the current business transaction into the print queue associated with the session identifier after detecting that the current business transaction has been completed, so as to complete the transaction processing of this round.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images