Transaction processing method and transaction system

Abstract

The embodiment of the invention provides a transaction processing method applied to a transaction system, and the method comprises the steps: obtaining the transaction data of a target transaction in response to the detection of the initiation operation of an operator on the target transaction, determining a plurality of historical transactions, and obtaining the transaction data of the plurality of historical transactions, and based on the transaction data of the target transaction and the transaction data of the plurality of historical transactions, identifying whether the target transaction has an error risk and obtaining an identification result, and further determining a target approval strategy applicable to the target transaction based on the identification result, and executing the approval process of the target transaction based on the target approval strategy. Wherein the transaction types of the plurality of historical transactions and the target transaction are the same.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of Internet, and particularly relates to a transaction processing method and a transaction system. BACKGROUND

[0002] Through a transaction system, a transaction subject (for example, a company, an enterprise, etc.) can perform various transactions. The transactions performed by the transaction subject are usually complex and diverse, and the transaction scale is large and the transaction frequency is high. When a transaction problem occurs, the transaction subject often suffers financial losses, and therefore the transaction subject has very high requirements for transaction security. The transaction subject usually arranges an auditor to approve the transaction in order to improve the transaction security. However, the approval process of the transaction is usually pre-set and fixed. Such a processing method cannot adapt to complex and diverse transaction scenarios, and often cannot balance between efficiency and security.

[0003] The content in the background section is only information known to the inventors before the present disclosure, and does not mean that the above information has been in the public domain before the present disclosure, or that it can be prior art of the present disclosure. SUMMARY

[0004] The present specification provides a transaction processing method and a transaction system. In the transaction processing method, the transaction system can identify whether a target transaction has an error risk, and adaptively determine a target approval strategy applicable to the target transaction according to the identification result, so as to improve the security of the target transaction while ensuring the efficiency of the transaction.

[0005] In a first aspect, the present specification provides a transaction processing method applied to a transaction system, the method comprising: in response to detecting an initiation operation of an operator on a target transaction, obtaining transaction data of the target transaction; determining a plurality of historical transactions and obtaining transaction data of the plurality of historical transactions, wherein the plurality of historical transactions are of the same transaction type as the target transaction; identifying whether the target transaction has an error risk based on the transaction data of the target transaction and the transaction data of the plurality of historical transactions, and obtaining an identification result; and determining a target approval strategy applicable to the target transaction based on the identification result, and performing an approval process of the target transaction based on the target approval strategy.

[0006] In some embodiments, the determining a plurality of historical transactions comprises: determining a target transaction type to which the target transaction belongs; obtaining a historical transaction set generated by the transaction system within a target historical period, the end time of the target historical period being the initiation time of the target transaction; and obtaining a plurality of historical transactions belonging to the target transaction type from the historical transaction set based on the target transaction type.

[0007] In some embodiments, the transaction system hosts a plurality of transaction subjects, and the historical transaction set includes a plurality of historical transaction subsets generated by the plurality of transaction subjects, and the obtaining, based on the target transaction type, the plurality of historical transactions belonging to the target transaction type from the historical transaction set includes: determining a first subject generating the target transaction, and obtaining at least one first historical transaction belonging to the target transaction type in the historical transaction subset corresponding to the first subject; determining at least one second subject, and obtaining at least one second historical transaction belonging to the target transaction type in the historical transaction subset corresponding to each of the at least one second subject respectively, each of the at least one second subject satisfying a preset subject similarity condition with the first subject; and taking the at least one first historical transaction and the at least one second historical transaction as the plurality of historical transactions.

[0008] In some embodiments, the subject similarity condition includes at least one of the following: same geographical area, same subject type, same business scope, or same level in the transaction system.

[0009] In some embodiments, the identifying, based on the transaction data of the target transaction and the transaction data of the plurality of historical transactions, whether the target transaction has an error risk includes: determining a plurality of feature dimensions based on the target transaction type to which the target transaction belongs, the plurality of feature dimensions being related to operations involved in an initiation process of a transaction of the target transaction type; determining an error probability of the target transaction from the plurality of feature dimensions based on the transaction data of the target transaction and the transaction data of the plurality of historical transactions; and determining whether the target transaction has an error risk based on the error probability corresponding to each of the plurality of feature dimensions.

[0010] In some embodiments, for any target feature dimension in the plurality of feature dimensions, the error probability corresponding to the target feature dimension is determined by: determining current feature information corresponding to the target feature dimension based on the transaction data of the target transaction; determining historical feature information corresponding to the target feature dimension based on the transaction data of the plurality of historical transactions; and determining the error probability corresponding to the target feature dimension based on a difference between the current feature information and the historical feature information.

[0011] In some embodiments, the plurality of historical transactions comprises at least one first historical transaction and at least one second historical transaction, a transaction subject initiating the first historical transaction is the same as a transaction subject initiating the target transaction, and a transaction subject initiating the second historical transaction is different from the transaction subject initiating the target transaction; the historical feature information comprises first historical feature information and second historical feature information, the first historical feature information is obtained based on transaction data of the at least one first historical transaction, and the second historical feature information is obtained based on transaction data of the at least one second historical transaction.

[0012] In some embodiments, the determining of the error probability corresponding to the target feature dimension based on the difference between the current feature information and the historical feature information comprises: determining a first error probability corresponding to the target feature dimension based on the difference between the current feature information and the first historical feature information; determining a second error probability corresponding to the target feature dimension based on the difference between the current feature information and the second historical feature information; and performing weighted average on the first error probability and the second error probability according to corresponding weight coefficients to obtain the error probability corresponding to the target feature dimension.

[0013] In some embodiments, the determining of whether the target transaction has an error risk based on the error probability corresponding to each of the plurality of feature dimensions comprises: if the error probability corresponding to at least one of the plurality of feature dimensions is greater than a preset threshold, determining that the target transaction has an error risk; or if the error probability corresponding to each of the plurality of feature dimensions is less than or equal to the preset threshold, determining that the target transaction does not have an error risk.

[0014] In some embodiments, the determining of the target approval strategy applicable to the target transaction based on the identification result comprises: obtaining an original approval strategy corresponding to the target transaction; and in a case where the identification result indicates that the target transaction has an error risk, adjusting the original approval strategy to obtain the target approval strategy, the approval strength of the target approval strategy being greater than the approval strength of the original approval strategy.

[0015] In some embodiments, the manner of adjusting the original approval strategy comprises one or more of the following: increasing the number of approval nodes in the original approval strategy, wherein different approval nodes correspond to different auditors; adjusting a first approval node in the original approval strategy to a second approval node, the second approval node corresponding to an auditor of a higher level than an auditor corresponding to the first approval node; or adding risk prompt information to an approval node in the original approval strategy.

[0016] In some embodiments, the method further includes: determining the original approval policy as the target approval policy in a case where the identification result characterizes that the target transaction does not have error risk.

[0017] In some embodiments, the performing the approval procedure of the target transaction based on the target approval policy includes: in a case where the target approval policy includes at least one approval node, sending an approval task to an auditor corresponding to the at least one approval node according to an approval order of the at least one approval node, the approval task instructing the auditor to perform auditing on the target transaction.

[0018] In some embodiments, for any one target approval node in the target approval policy, in a case where the target approval node includes risk prompt information, the risk prompt information is included in an approval task sent to an auditor corresponding to the target approval node.

[0019] In some embodiments, after the performing the approval procedure of the target transaction based on the target approval policy, the method further includes: performing a transaction procedure of the target transaction in a case where an approval result corresponding to the approval procedure characterizes that the approval is passed.

[0020] In a second aspect, the specification also provides a transaction system, which includes: at least one storage medium including at least one instruction set for processing a target transaction; and at least one processor in communication connection with the at least one storage medium, wherein, when the system is running, the at least one processor reads the at least one instruction set and performs the transaction processing method according to the indication of the at least one instruction set.

[0021] Other functions of the transaction processing method and the transaction system provided by the specification will be partially listed in the following description. The creative aspects of the transaction processing method and the transaction system provided by the specification can be fully explained by practicing or using the methods, devices and combinations described in the following detailed examples. BRIEF DESCRIPTION OF DRAWINGS

[0022] In order to more clearly illustrate the technical solutions in the embodiments of the specification, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the specification, and for those skilled in the art, other drawings can also be obtained without creative labor based on these drawings.

[0023] Figure 1 An application scenario of a transaction system provided according to an embodiment of the specification is shown;

[0024] Figure 2 FIG. 1 shows a hardware structure diagram of a system according to an embodiment of the present specification;

[0025] Figure 3 FIG. 2 shows a flowchart of a transaction processing method according to an embodiment of the present specification;

[0026] Figure 4 FIG. 3 shows a schematic diagram of an interaction interface of a terminal according to an embodiment of the present specification;

[0027] Figure 5 FIG. 4 shows a process schematic diagram of obtaining a plurality of historical transactions belonging to a target transaction type according to an embodiment of the present specification;

[0028] Figure 6 FIG. 5 shows a process schematic diagram of identifying whether a target transaction exists a risk of error according to an embodiment of the present specification; and

[0029] Figure 7 FIG. 6 shows a schematic diagram of a way of adjusting an original approval strategy according to an embodiment of the present specification. DETAILED DESCRIPTION

[0030] The following description provides specific applications and requirements of the present specification, which is intended to enable a person skilled in the art to manufacture and use the content of the present specification. Various modifications to the disclosed embodiments are apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of the present specification. Therefore, the present specification is not limited to the embodiments shown, but is consistent with the widest scope of the claims.

[0031] The terms used herein are only for the purpose of describing specific example embodiments, and are not limiting. For example, unless the context clearly indicates otherwise, as used herein, the singular forms "a", "an", and "the" can also include the plural forms. When used in the present specification, the terms "comprise", "include" and / or "contain" mean that the associated whole, step, operation, element and / or component exists, but do not exclude the presence of one or more other features, whole, step, operation, element, component and / or group or additional features, whole, step, operation, element, component and / or group can be added in the system / method.

[0032] These and other features, and characteristics of the present specification, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings. The current description will be better understood with reference to the drawings in which:

[0033] The flowcharts used in this specification show the operations of system implementations according to some embodiments of this specification. It should be clearly understood that the operations of the flowcharts can not be implemented in sequence. Instead, the operations can be implemented in reverse order or simultaneously. In addition, one or more other operations can be added to the flowcharts. One or more operations can be removed from the flowcharts.

[0034] Before the specific embodiments of the present specification are described, the application scenarios to which the technical solutions provided by the present specification are applicable are introduced.

[0035] Through the transaction system, the transaction subject (for example, a company, an enterprise, and the like) can carry out various transactions. The transactions carried out by the transaction subject are usually complex and diverse, and the transaction scale is large and the transaction frequency is high. When the transaction occurs, the transaction subject often suffers financial losses, so the transaction subject has very high requirements for transaction security. The transaction subject usually arranges auditors to approve the transaction to improve the security of the transaction. Approval refers to a process of checking the compliance and security of the submitted transaction.

[0036] However, in the prior art, the approval process of the transaction is usually pre-set and fixed. This processing method cannot adapt to complex and diverse transaction scenarios. In addition, the approval process is usually manually executed by the auditor throughout the process, and the approval process is cumbersome, so that the approval cost is very high, and it is often difficult to balance between efficiency and security.

[0037] Figure 1 An application scenario of a transaction system provided according to an embodiment of the present specification is shown. As shown in Figure 1 The application scenario 100 can include a transaction system 110.

[0038] The transaction system 110 can be stationed with multiple transaction subjects. The transaction subject can refer to an entity participating in the transaction process, the initiator and performer of the transaction behavior, such as an enterprise, a company, or an institution, and the like. The subject types, business scopes, geographic regions, and levels in the transaction system of different transaction subjects can be the same or different. The transaction system 110 can support different transaction subjects to carry out transaction activities as a platform. For example, the transaction system 110 can be a fund management platform, mainly serving the transaction subject to carry out fund management and fund flow, and providing corresponding functions for the transaction subject.

[0039] The transaction types supported by the transaction system 110 can include, but are not limited to, a transfer type transaction, a payment type transaction, a conversion type transaction, and the like.

[0040] Further, the transfer type transaction can further include a transfer between accounts within the transaction subject, a transfer between the transaction subject and an external account, and the like. For example, the transfer between accounts within the transaction subject can be a transfer of funds from the transaction subject to its associated subsidiary, a transfer of funds from the transaction subject to its multiple backup accounts, a withdrawal of funds from the transaction subject to the accounts of the principals / directors, and the like. The transfer between the transaction subject and the external account can be a reimbursement of certain expenses from the transaction subject to the employees, a payment of salaries from the transaction subject to the employees, a payment of fines from the transaction subject to the relevant departments, a payment of taxes from the transaction subject to the relevant parties, and the like.

[0041] Further, the payment type transaction can further include a payment of funds from the transaction subject to different suppliers, and the like. The different suppliers can provide different goods or product services. For example, after the transaction subject purchases electronic equipment (e.g., computers, printing equipment, and the like), the transaction subject pays the equipment suppliers. For another example, after the transaction subject purchases stationery supplies (e.g., paper, staplers, and the like), the transaction subject pays the stationery suppliers.

[0042] Further, the conversion type transaction can further include a conversion of different currencies, and the like. For example, the transaction subject converts the funds in the account to currency 1. For another example, the transaction subject converts the funds in the account to currency 2.

[0043] In some embodiments, the transaction system 110, in addition to providing the function of fund management, can also provide other functions, which include, but are not limited to, store management, account management, team management, and the like. The present specification does not limit the same.

[0044] The transaction system 110 can be a system that only supports transactions of transaction subjects in the same country or region. The transaction system 110 can also be a system that allows transactions of transaction subjects in different countries or regions, and the transaction system 110 can support transactions in multiple currencies. The present specification does not limit the same.

[0045] The transaction subject can conduct transactions through the transaction system 110. In some embodiments, the transaction subject can have a transaction account in the transaction system 110, and the transaction subject can enjoy various services provided by the transaction system 110 by logging into the transaction account on the transaction system 110. The holder of the transaction account in the transaction subject can have full operation authority of the transaction account and conduct various types of transactions.

[0046] In some embodiments, the transaction system 110 can be communicatively connected with a plurality of transaction platforms. The transaction platforms can include e-commerce platforms and the like. When a transaction subject generates a transaction on an e-commerce platform, the transaction subject can manage the fund and the fund outflow through the transaction system 110. For example, the transaction subject can transfer money to a merchant on the e-commerce platform through the transaction system 110.

[0047] The transactions generated by the transaction system are usually complex and diverse, and the transactions are performed at a relatively high frequency. When a transaction problem occurs, the transaction subject often suffers a fund loss, and therefore the transaction subject has a very high requirement for transaction security. The transaction subject usually arranges auditors to approve the transactions to improve the transaction security. In addition, the transaction subject usually arranges a plurality of operators to collaboratively manage the transaction content to improve the transaction efficiency and facilitate the responsibility tracing. For example, a transaction subject such as an enterprise, a company, or an institution with a certain scale can have a plurality of operators, and different operators can have different permissions and functions and be responsible for different transaction types. For example, some operators are responsible for transfer type transactions, some operators are responsible for payment type transactions, and some operators are responsible for exchange type transactions, and the like. Further, the operators can be further divided according to the above transaction types and be responsible for more specific transaction types. For example, the operators responsible for payment type transactions can be further divided into operators responsible for paying money to a device supplier and operators responsible for paying money to a stationery supplier, and the like. Different transaction subjects can have different numbers of operators due to different transaction types and transaction scales.

[0048] In some embodiments, the holder of the transaction account can give different operation permissions to a plurality of operators, and the operation permissions of the operators are a subset of the permissions of the holder, so that the operators perform different types of transactions.

[0049] In some embodiments, the operators can prepare transaction documents for the transactions they are responsible for, that is, according to the rules of the enterprise, the company, or the system, the operators can organize the key information of a transaction into a standardized transaction document as a basis for subsequent processes. The information on the transaction document can include but is not limited to operator information, transaction type, payee name, payee account, currency, transaction purpose, associated files (such as contracts, invoices, and the like), and the like. For example, the operators can manually prepare the transaction documents and upload them to the system. For another example, the operators can only fill in the key information of the transaction, and the system can automatically generate a transaction document with a number. For another example, as described above, the transaction system 110 can be communicatively connected with the transaction platform. The transaction system can obtain at least part of the key information data of the transaction from the transaction platform, and the operators can check and supplement the data and strictly prepare the transaction documents according to the internal requirements.

[0050] The operators can initiate the operation of the target transaction after completing the preparation of the transaction documents to realize the fund outflow or exchange, and the like.

[0051] As an example, such as Figure 1 As shown, the transaction entities registered in transaction system 110 include transaction entity A and transaction entity B. The number of operators within each transaction entity differs, and connections between operators indicate that they are responsible for the same type of transaction. Taking transaction entity A as an example, its operators include operator 1, operator 2, and operator 3. Operator 1 and operator 2 are responsible for the same type of transaction: payments to equipment suppliers. Operator 1 and operator 3 are responsible for different types of transactions; operator 3 is responsible for payments to stationery suppliers. Operator 1 needs to process a transaction X for payment to an equipment supplier. Operator 1 can create a transaction document on transaction system 110. After creating the document on transaction system 110, operator 1 can initiate transaction X.

[0052] During the initiation of a target transaction, intentional or unintentional actions by the operator may lead to errors. For example, the operator may inadvertently fill in incorrect transaction information, including but not limited to the transaction amount and currency, on the transaction form. Another example is that the operator may intentionally fill in their own personal account as the receiving account. Compared to risks such as fraud, chargebacks, or exploitation of promotional offers, error risk is primarily due to human error or negligence on the part of the operator. Such errors can also result in financial losses and damage to the interests of the transaction participants.

[0053] In some embodiments, an operator initiating a target transaction can directly realize the outflow or exchange of funds without the need for verification by others, such as approval from an auditor. When there is a risk of error, this transaction processing method can lead to losses for the transacting parties. In some embodiments, after an operator initiates a target transaction, it needs to undergo verification by others, such as an approval process and approval from an auditor. However, as mentioned earlier, existing approval processes are usually customized and fixed, and are mainly conducted manually by auditors. Many uncertainties, such as the auditor's familiarity with the transaction, the rigor of their verification, and their workload, may prevent them from identifying potential errors in a timely manner. In other words, existing methods are not only costly but also unable to adapt to complex and ever-changing transaction scenarios, making it difficult to achieve a balance between efficiency and security.

[0054] The trading system 110 can identify the error risk of a target transaction. After the operator of the trading entity initiates a target transaction through the trading system 110, the system can identify the error risk of the target transaction, determine the approval strategy based on the identification results, and then execute the approval process. The trading system 110 can identify whether there is an error risk in the target transaction based on the transaction data of the target transaction and the transaction data of historical transactions of the same type as the target transaction. Based on the identification results, it determines the target approval strategy to be used for the target transaction and executes the approval process based on the target approval strategy. After the approval process is completed, the corresponding fund outflow for the target transaction is executed, thereby ensuring the compliance and security of the operation and reducing the error risk.

[0055] As an example, such as Figure 1 As shown, after an operator in trading entity A initiates transaction X, the trading system 110 can identify the error risk of transaction X and determine the approval strategy based on the identification results. This allows the reviewer in trading entity A to approve transaction X according to the approval tasks outlined in the approval strategy. Similarly, after an operator in trading entity B initiates transaction Y, the trading system 110 can identify the error risk of transaction Y and determine the approval strategy based on the identification results. This allows the reviewer in trading entity B to approve transaction Y according to the approval tasks outlined in the approval strategy, thereby ensuring the safety of the trading entity's funds.

[0056] In some embodiments, the trading system 110 may store data and instructions for implementing trading methods, and may execute or be used to execute the data and instructions. In some embodiments, the trading system 110 may include hardware devices with data processing capabilities and the necessary programs required to drive the hardware devices to operate.

[0057] It should be noted that the transaction system 110 can correspond to a single device or a cluster of devices; this specification does not impose any restrictions on this. When the transaction system 110 corresponds to a single device, the transaction processing method can be executed entirely on that device. When the transaction system 110 corresponds to a cluster of devices, the transaction processing method can be executed collaboratively on multiple devices corresponding to the cluster, or the transaction processing method can have other execution methods; this specification does not impose any restrictions on this.

[0058] In some embodiments, the transaction system 110 may include a terminal and a server. Figure 1 (Not shown in the image).

[0059] The terminal can be a device that interacts with an operator. The operator can input various data or instructions to the terminal through the terminal input and output device, and receive data or results from the terminal. In some embodiments, the terminal can include a hardware device with data information processing functions and necessary application programs required to drive the hardware device to work. The application program can provide the operator with the ability to interact with the outside world through the network and the interface. For example, the application program can be a transaction platform applet, a transaction platform webpage, etc. The operator can complete account login, order making, initiating target transactions, etc. on the terminal.

[0060] In some embodiments, the terminal can include a mobile device, a tablet computer, a notebook computer, a built-in device of a motor vehicle, or the like, or any combination thereof. In some embodiments, the mobile device can include a smart home device, a smart mobile device, a virtual reality device, an augmented reality device, or the like, or any combination thereof. In some embodiments, the smart home device can include a smart television, a desktop computer, etc., or any combination thereof. In some embodiments, the smart mobile device can include a smart phone, a personal digital assistant, a game device, a navigation device, etc., or any combination thereof. In some embodiments, the built-in device in the motor vehicle can include an on-board computer, an on-board television, etc.

[0061] As an example, after the operator completes order making and initiates a target transaction on the terminal, the terminal can send a transaction processing instruction to the server, and the server can obtain transaction data of the target transaction and respond to the transaction processing instruction to perform the transaction processing method provided in the present specification.

[0062] It should be understood that Figure 1 the number of transaction systems 110, transaction subjects, and operators shown in FIG. 1 is only illustrative. Any number can be provided according to the implementation needs.

[0063] Figure 2 A hardware structure diagram of a system 200 according to an embodiment of the present specification is shown.

[0064] As Figure 2 shown, the system 200 can be a transaction system 110 in Figure 1 .

[0065] The system 200 includes at least one storage medium 230 and at least one processor 220. In some embodiments, the system 200 can also include a communication port 250 and an internal communication bus 210. In addition, the system 200 can also include an I / O component 260.

[0066] The internal communication bus 210 can connect different system components. For example, the internal communication bus 210 can connect the storage medium 230, the processor 220, the communication port 250, and the I / O component 260.

[0067] The I / O component 260 supports input / output between the system 200 and other components.

[0068] The communication port 250 is used for data communication between the system 200 and the outside world. For example, the communication port 250 can be used for data communication between the system 200 and a network. The communication port 250 can be a wired communication port or a wireless communication port.

[0069] In some embodiments, the network can be any type of wired or wireless network, or a combination thereof. For example, the network can include a cable network, a wired network, a fiber optic network, a telecommunications network, an intranet, the Internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Public Switched Telephone Network (PSTN), a Bluetooth network™, a short-range wireless network (ZigBee™), a Near Field Communication (NFC) network, or the like.

[0070] In some embodiments, the network can include one or more network access points. For example, the network can include wired or wireless network access points, such as a base station or an Internet exchange point. Through the access point, one or more components of each device corresponding to the system 200 can be connected to the network to exchange data or information.

[0071] The storage medium 230 can include a data storage device. The data storage device can be a non-transitory storage medium or a transitory storage medium. For example, the data storage device can include one or more of a disk 232, a read-only memory (ROM) 234, or a random access memory (RAM) 236. The storage medium 230 also includes at least one instruction set stored in the data storage device. The instruction set can include computer program code, which can include programs, routines, objects, components, data structures, processes, modules, and the like that perform the transaction processing methods provided in this specification.

[0072] The processor 220 can be communicatively connected with the storage medium 230. The processor 220 is configured to execute the at least one instruction set. When the system 200 is in operation, the processor 220 reads the at least one instruction set and executes the transaction processing method provided in the specification according to the instructions of the at least one instruction set.

[0073] The processor 220 can be in the form of one or more processors. In some embodiments, the processor 220 can include one or more hardware processors, such as a microcontroller, a microprocessor, a reduced instruction set computer (RISC), an application-specific integrated circuit (ASIC), an application-specific instruction set processor (ASIP), a central processing unit (CPU), a graphics processing unit (GPU), a physics processing unit (PPU), a microcontroller unit, a digital signal processor (DSP), a field programmable gate array (FPGA), an advanced RISC machine (ARM), a programmable logic device (PLD), any circuit or processor capable of executing one or more functions, or the like, or any combination thereof.

[0074] For the sake of illustration only, only one processor 220 is shown in the system 200 in the accompanying drawings. However, it should be noted that the system 200 in the specification can also include multiple processors. Therefore, the operations and / or method steps disclosed in the specification can be performed by one processor as described in the specification, or jointly performed by multiple processors. For example, if the processor 220 of the system 200 in the specification performs step A and step B, it should be understood that step A and step B can also be performed jointly or separately by two different processors 220 (e.g., a first processor performs step A, a second processor performs step B, or the first and second processors jointly perform steps A and B).

[0075] Figure 3 A flowchart of a transaction processing method P300 according to an embodiment of the specification is shown. The transaction system 110 can perform the transaction processing method P300. As shown, Figure 3 The transaction processing method P300 includes the following steps.

[0076] S310: In response to detecting the operator's initiation operation on the target transaction, obtaining transaction data of the target transaction.

[0077] The transaction system can obtain the transaction data of the target transaction in response to the operator's initiation operation on the target transaction on the transaction system. For example, as previously described, the operator can initiate the target transaction on the terminal of the transaction system.

[0078] The target transaction can include, but is not limited to, the aforementioned transfer type transaction, the payment type transaction, the exchange type transaction, and the like. The transaction data of the target transaction can include, but is not limited to, the transaction type, the name of the payee or the payer, the account of the payee or the payer, the currency, the transaction commodity, the transaction purpose, the associated file (such as a contract, an invoice, and the like), and the like.

[0079] In some embodiments, the transaction data of the target transaction can be filled in by the operator. For example, the operator can arrange the key information of a transaction into a standardized transaction form on the terminal according to the rules of the enterprise, the company, or the system, as the basis for subsequent processes. In some embodiments, as mentioned above, the transaction system can be communicatively connected with the transaction platform. The transaction system can obtain at least part of the key data of the target transaction from the transaction platform. For example, the transaction commodity and the transaction purpose. The operator can check, review, supplement, and the like, for example, supplement the transaction amount, the transaction account, and the like, for these data.

[0080] Figure 4 A schematic diagram of an interactive interface of a terminal is shown according to an embodiment of the present specification. As shown, taking a computer as an example, the computer can display an interactive interface 410. The interactive interface can be a web page displayed by the transaction system on the computer. The operator can fill in the payment account, the transfer currency, and the transfer amount of the transfer transaction in the web page, thereby completing the transfer transaction. The operator can realize the initiation operation of the target transaction by clicking the initiation transaction button on the interactive interface 410. Figure 4

[0081] S320: Determine a plurality of historical transactions, and obtain the transaction data of the plurality of historical transactions, wherein the plurality of historical transactions are of the same transaction type as the target transaction.

[0082] The historical transaction can refer to a transaction performed on the transaction system before the target transaction. The transaction data of the historical transaction can reflect the transaction habits and transaction characteristics of the transaction type thereof. The transaction data between the transaction types have reference value. The historical transaction is of the same transaction type as the target transaction, and thus the transaction data of the historical transaction has reference value for the transaction data of the target transaction. For example, the transaction amount, the transaction currency, the payment account, and the like between the two can have similarities. By obtaining the historical transaction as a reference for the target transaction, it is convenient to subsequently identify whether there is an error risk in the target transaction.

[0083] ​The historical transaction is of the same transaction type as the target transaction. For example, the target transaction is a transaction of a transfer type, and the historical transaction is also a transaction of the transfer type. For another example, the target transaction is a transaction of a payment type, and the historical transaction is also a transaction of the payment type. Further, as mentioned above, the transaction type can be divided more specifically. For example, the target transaction is a transaction of payment to a device supplier, and the historical transaction is also a transaction of payment to the device supplier. For another example, the target transaction is a transaction of payment to a stationery supplier, and the historical transaction is also a transaction of payment to the stationery supplier.

[0084] The more specifically the transaction type is divided, the higher the similarity between the transaction data, and the higher the reference value of the transaction data, but the data volume of the transaction data can be less. The transaction system can determine the historical transaction in a balance between the data volume of the transaction data and the similarity of the transaction data.

[0085] The transaction data of the historical transaction can correspond to the transaction data of the target transaction, so as to facilitate the subsequent identification of the error risk. For example, the transaction data of the target transaction includes the transaction amount, the transaction currency, and the payment account of the target transaction. The transaction data of the historical transaction at least includes the transaction amount, the transaction currency, and the payment account of the historical transaction. For another example, the transaction data of the target transaction includes the transaction number (e.g., the target transaction is the first transaction of the day) and the transaction currency of the target transaction. The transaction data of the historical transaction at least includes the transaction number and the transaction currency of the historical transaction.

[0086] In some embodiments, the determining the plurality of historical transactions can include the following steps:

[0087] (1) determining a target transaction type to which the target transaction belongs.

[0088] The transaction system can determine the target transaction type to which the target transaction belongs through a transaction document filled by an operator. The transaction system can also autonomously determine the target transaction type from the transaction data of the target transaction. For example, when the target transaction includes a transaction commodity, the transaction system determines that the target transaction is a transaction of a payment type. The target transaction can include a transaction field for indicating the transaction type to which the target transaction belongs, and thus the transaction system can also determine the target transaction type from the transaction field of the target transaction. For example, the target transaction is a transaction of a currency 1. The “currency 1” field can indicate the transaction type. For another example, the target transaction is a transaction of payment to a device supplier. The “payment” field can indicate the transaction type. The “payment to the device supplier” field can indicate a more specific transaction type corresponding to the transaction.

[0089] In some embodiments, different operators are responsible for different transaction types. Each operator is responsible for a corresponding transaction type. The transaction system can also determine the target transaction type according to the operator who initiates the target transaction. For example, operator 1 is responsible for transactions of the transfer type, and operator 2 is responsible for transactions of the payment type. If the target transaction is initiated by operator 2, the transaction system can determine that the target transaction type is the payment type.

[0090] (2) Obtain a historical transaction set generated by the transaction system in a target historical period, the end time of the target historical period being the initiation time of the target transaction.

[0091] The target historical period can be a period before the initiation time of the target transaction. The historical transaction set generated in the target historical period can be considered to include all transactions performed on the transaction system before the initiation time. As described above, multiple transaction subjects can be arbitrarily hosted in the transaction system. The historical transaction set can include multiple historical transaction subsets generated by the multiple transaction subjects. In some embodiments, the historical transaction set can include historical transactions generated by all transaction subjects hosted in the transaction system. The historical transaction set generated in the target historical period can also be considered to include part of the transactions performed on the transaction system before the initiation time. For example, the historical transaction set can include all historical transactions in the 3 days before the initiation of the target transaction. For another example, the historical transaction set can include all historical transactions in the week before the initiation of the target transaction.

[0092] (3) Based on the target transaction type, obtain multiple historical transactions belonging to the target transaction type from the historical transaction set.

[0093] The transaction system can obtain multiple historical transactions with the same transaction type as the target transaction from the historical transaction set. As described above, transaction data can reflect transaction habits and transaction characteristics. When the transaction types are the same, the similarity between the transaction data is higher, and the reference value is higher, thereby facilitating subsequent identification of whether there is a risk of error in the target transaction.

[0094] Figure 5 A process diagram for obtaining multiple historical transactions belonging to the target transaction type is shown according to an embodiment of the present specification. The following describes the process of obtaining multiple historical transactions belonging to the target transaction type. Figure 5 The process of obtaining multiple historical transactions belonging to the target transaction type is described.

[0095] (A) Determine a first subject who generates the target transaction, and obtain at least one first historical transaction belonging to the target transaction type in a historical transaction subset corresponding to the first subject.

[0096] The historical transaction subset corresponding to the first subject can include historical transactions initiated by the first subject on the transaction system in the historical transaction set.

[0097] For example, the first subject of the target transaction is company A, and the target transaction type is a transfer transaction. The historical transaction subset includes historical transactions initiated by company A on the transaction system in the historical transaction set. The transaction system can obtain at least one first historical transaction belonging to the transfer type in the historical transaction subset initiated by company A on the transaction system.

[0098] In some embodiments, there is a certain transaction field in the historical transaction to indicate the transaction type of the historical transaction. The transaction system can obtain at least one first historical transaction in the historical transaction subset through the transaction field. For example, the transaction system can obtain a historical transaction with the same transaction field as the target transaction in the historical transaction subset, and take it as at least one first historical transaction.

[0099] In some embodiments, different operators are responsible for different transaction types. For example, one operator is responsible for one transaction type. Therefore, the operator corresponding to the target transaction is likely to be responsible for the same transaction type as the target transaction. The transaction system can obtain at least one first historical transaction belonging to the target transaction type in the historical transaction subset according to the operator. For example, the transaction system can obtain historical transactions initiated by the operator corresponding to the target transaction in the historical transaction subset, and take them as at least one first historical transaction.

[0100] In some embodiments, one operator can be responsible for multiple transactions. Different transactions can belong to the same transaction type, or belong to different transaction types. For example, one operator is responsible for transactions of paying money to device suppliers, stationery suppliers, and daily necessities suppliers. The three transactions belong to the same transaction type of payment. The transaction fields can be “paying money to device suppliers”, “paying money to stationery suppliers”, and “paying money to daily necessities suppliers”, respectively. Compared with purchasing equipment, the frequency, amount, and currency of transaction data of purchasing stationery and daily necessities by the transaction subject have higher similarity and higher reference value, so the transactions related to stationery and daily necessities can be considered as transactions of the same transaction type. The transaction system can obtain at least one historical transaction in the historical transaction subset according to the transaction field and the operator. For example, the transaction system can obtain historical transactions initiated by the operator corresponding to the target transaction in the historical transaction subset, and then determine at least one first historical transaction of the same transaction type from these historical transactions according to the transaction field.

[0101] (B) determining at least one second subject, and obtaining at least one second historical transaction belonging to the target transaction type in the historical transaction subset corresponding to each of the at least one second subject, respectively, each second subject satisfying a preset subject similarity condition with the first subject.

[0102] The transaction system can determine one or more second subjects. The second subject is a transaction subject different from the first subject. The second subject can satisfy a preset subject similarity condition with the first subject, that is, the first subject and the second subject are similar. Therefore, there is also similarity between the transaction performed by the second subject and the transaction performed by the first subject, the transaction performed by the second subject has reference value for the target transaction generated by the first subject, and more data reference can be provided for identifying the error risk of the target transaction, so that the identification result of the error risk is more accurate. The transaction system can obtain at least one second historical transaction belonging to the target transaction type in the historical transaction subset corresponding to the second subject.

[0103] For example, the first subject generating the target transaction is company A, the target transaction type is a transfer transaction, and the second subject includes company B and company C. The transaction system can obtain second historical transactions belonging to the transfer type in the historical transaction subsets corresponding to company B and company C, respectively.

[0104] The method of obtaining at least one second historical transaction belonging to the target transaction type from the historical transaction subset can refer to the first historical transaction described above, and will not be described here.

[0105] In some embodiments, the subject similarity condition includes at least one of the following:

[0106] (a) The same geographical region belongs to.

[0107] For example, the first subject and the second subject are in the Asian region.

[0108] (b) The same subject type belongs to.

[0109] For example, the first subject and the second subject are both limited companies. For another example, the first subject and the second subject are both joint-stock companies.

[0110] (c) The same scope of business.

[0111] For example, the scope of business of the first subject and the second subject is both catering services.

[0112] (d) The same level in the transaction system.

[0113] The level can represent the time of entering the transaction system or the transaction experience, etc. For example, the level of the first subject and the second subject in the transaction system is both level 5. For another example, the level of the first subject and the second subject in the transaction system is both medium level.

[0114] The more the two satisfy the subject similarity condition, the higher the correlation between the transaction data, and the higher the reference value.

[0115] (C) the at least one first historical transaction and the at least one second historical transaction as the plurality of historical transactions.

[0116] The second historical transaction can be supplementary and referenced to the first historical transaction. The transaction system takes the first historical transaction and the second historical transaction as the historical transaction corresponding to the target transaction, which can provide more data reference for identifying the error risk of the target transaction, so that the identification result of the error risk is more accurate.

[0117] S330: Based on the transaction data of the target transaction and the transaction data of the plurality of historical transactions, identifying whether the target transaction has an error risk and obtaining an identification result.

[0118] The transaction system takes the transaction data of the plurality of historical transactions as reference, which can more accurately identify whether the transaction data of the target transaction has an error risk and obtain an identification result, thereby ensuring the safety of the funds of the transaction subject.

[0119] Figure 6 A process diagram for identifying whether a target transaction has an error risk is shown according to an embodiment of the present specification. The following will be described in combination with Figure 6 The process of identifying whether a target transaction has an error risk is described.

[0120] (1) Based on the target transaction type to which the target transaction belongs, a plurality of feature dimensions are determined.

[0121] The plurality of feature dimensions can be related to the operations involved in the initiation process of the transaction under the target transaction type. In some embodiments, the plurality of feature dimensions are related to the operations of the operator in the process of initiating the transaction under the target transaction type. For example, as described above, the operator needs to make a transaction document on the transaction platform, fill in and check the transaction data. Under the same transaction type, the data part that the operator needs to fill in is usually the same. The plurality of feature dimensions can include the data part filled in or needed to be filled in by the operator, or the data part that can be modified by the operator.

[0122] For example, as Figure 4 shown, before initiating the transfer, the operator needs to fill in the payment account, the transfer currency and the transfer amount of the transaction. In this case, the plurality of feature dimensions can include the payment account, the transfer currency and the transfer amount.

[0123] Different target transaction types can determine different feature dimensions. The transaction system can determine a plurality of feature dimensions under a target transaction type based on the target transaction type to which the target transaction belongs. For example, the feature dimensions of a transfer type transaction can include, but are not limited to, a payment account, a transfer currency, a transfer amount, etc. The feature dimensions of a payment type transaction can include, but are not limited to, a payment currency, a payment amount, and a payment number, etc. The feature dimensions of a conversion type transaction can include, but are not limited to, a conversion currency, a conversion amount, a real-time exchange rate, etc.

[0124] (2) Based on the transaction data of the target transaction and the transaction data of the plurality of historical transactions, respectively determine the error probability of the target transaction from the plurality of feature dimensions.

[0125] By comprehensively reviewing the target transaction under a plurality of feature dimensions and considering the error probability of the target transaction under different feature dimensions from multiple perspectives, the accuracy and reliability of the identification result are improved, and the security of the transaction is ensured.

[0126] In some embodiments, for any target feature dimension in the plurality of feature dimensions, the error probability corresponding to the target feature dimension is determined by:

[0127] (A) Based on the transaction data of the target transaction, determine the current feature information corresponding to the target feature dimension.

[0128] The feature information corresponding to the target feature dimension can reflect the specific circumstances of the target transaction. The feature dimensions can include quantitative feature dimensions and qualitative feature dimensions. The quantitative feature dimensions can be considered as feature dimensions that can be numerically valued, including but not limited to transaction amount, transaction number, timing exchange rate, etc. The qualitative feature dimensions can be considered as feature dimensions that cannot be numerically valued, including but not limited to currency, payment method, region, etc.

[0129] Different types of feature dimensions can correspond to different forms of feature information. The transaction system can determine the current feature information corresponding to the target feature dimension according to the dimension type of the target feature dimension.

[0130] When the target feature dimension is a quantitative dimension, the current feature information can be a specific numerical value corresponding to the target feature dimension. For example, the target feature dimension is the transaction amount, and the current feature information can be the amount of money. As an example, the target feature dimension is the transaction amount, and the current feature information is 500. For another example, the target feature dimension is the transaction number, and the current feature information can be the number of transactions. As an example, the target feature dimension is the transaction number, and the current feature information is 51. That is, the target transaction is the 51st transaction within a predetermined time (e.g., the same day).

[0131] When the target feature dimension is a qualitative dimension, the current feature information can reflect the qualitative selection corresponding to the target feature dimension. For example, the current feature information can be a multi-dimensional vector to represent the selection in the vector. The dimension of the vector represents all options of the target feature dimension, and the elements of the vector represent the selection of the target transaction under the target feature dimension.

[0132] For example, the target feature dimension is the transaction currency, and the transaction system supports N currency transactions. Then the current feature information can be an N-dimensional vector, and different currencies are represented by different elements in the vector.

[0133] As an example, the target feature dimension is the transaction currency, and the transaction currency of the target transaction is currency 1, the current feature information can be represented as {1, 0, …, 0}, and the transaction currency of the target transaction is currency 2, the current feature information can be represented as {0, 1, …, 0}.

[0134] (B) Based on the transaction data of the plurality of historical transactions, determine the historical feature information corresponding to the target feature dimension.

[0135] The transaction system can determine the historical feature information corresponding to the target feature dimension based on the transaction data of the plurality of historical transactions. For the transaction data of each historical transaction, the specific method of determining the historical feature information corresponding to the target feature dimension can refer to the current feature transaction described above, and will not be repeated here.

[0136] In some embodiments, the transaction system can determine the historical feature information corresponding to the target feature dimension based on the transaction data of each historical transaction. The transaction data of each historical transaction can determine the corresponding historical feature information under the target feature dimension. The transaction system can further process the plurality of historical feature information to obtain one, comprehensive historical feature information corresponding to the target feature dimension.

[0137] For example, when the target feature dimension is a qualitative dimension, the transaction system can average the plurality of historical feature information to obtain the comprehensive historical feature information.

[0138] As an example, the target feature dimension is the transaction currency, and the transaction system supports 4 currency transactions, and the transaction system determines 4 historical transactions. Under the feature dimension of transaction currency, the historical feature information of the first historical transaction is {1, 0, 0, 0}, the historical feature information of the second historical transaction is {1, 0, 0, 0}, the historical feature information of the third historical transaction is {0, 0, 1, 0}, and the historical feature information of the fourth historical transaction is {0, 0, 1, 0}. Then the historical feature information of the plurality of historical transactions under the transaction currency is {1 / 2, 1 / 4, 1 / 4, 0}.

[0139] For another example, when the target feature dimension is a quantitative dimension, the transaction system can directly use the set of multiple historical feature information as the historical feature information.

[0140] As an example, the target feature dimension is transaction amount, and the transaction system determines 4 historical transactions. Under the feature dimension of transaction amount, the historical feature information of the first historical transaction is 198, the historical feature information of the second historical transaction is 197, the historical feature information of the third historical transaction is 180, and the historical feature information of the fourth historical transaction is 226. Then, the historical feature information of the multiple historical transactions under the transaction currency is {198, 197, 180, 226}.

[0141] In some embodiments, when the target feature dimension is a quantitative dimension, the transaction system can also process the multiple historical feature information before using it as the historical feature information, which is not limited in the present specification.

[0142] (C) determining the error probability corresponding to the target feature dimension based on the difference between the current feature information and the historical feature information.

[0143] The historical feature information can be used as a judgment basis or standard for the transaction type. The difference between the current feature information and the historical feature information can reflect the degree of deviation of the target transaction from the normal transaction under the target feature dimension. When the difference between the current feature information and the historical feature information is too large, the transaction system can consider that the probability of error in the target feature dimension of the target transaction is high.

[0144] As mentioned above, the multiple historical transactions can include at least one first historical transaction and at least one second historical transaction. The transaction subject initiating the first historical transaction is the same as the transaction subject initiating the target transaction, and the transaction subject initiating the second historical transaction is different from the transaction subject initiating the target transaction. The historical feature information can include first historical feature information and second historical feature information. The transaction system can obtain the first historical feature information based on the transaction data of the at least one first historical transaction, and obtain the second historical feature information based on the transaction data of the at least one second historical transaction.

[0145] The method for the transaction system to obtain the first historical feature information and / or the second historical feature information can refer to the above.

[0146] In some embodiments, the step of determining the error probability corresponding to the target feature dimension based on the difference between the current feature information and the historical feature information can include the following steps:

[0147] (a) determining the first error probability corresponding to the target feature dimension based on the difference between the current feature information and the first historical feature information.

[0148] Different types of feature dimensions can correspond to different ways of calculating error probability. The transaction system can determine the way of calculating the first error probability corresponding to the target feature dimension according to the dimension type of the target feature dimension.

[0149] When the target feature dimension is a qualitative dimension, the current feature information and the first historical feature information can be vectors of the same dimension. The transaction system can determine the first error probability corresponding to the target feature dimension by calculating the cosine similarity between the vectors.

[0150] As an example, the target feature dimension is the transaction currency, the current feature information is {1, 0, 0, 0}, and the first historical feature information is {1 / 2, 1 / 4, 1 / 4, 0}. The transaction system can calculate the cosine similarity between the two vectors and take it as the first error probability corresponding to the transaction currency.

[0151] When the target feature dimension is a quantitative dimension, the current feature information and the first historical feature information are both numerical values. The transaction system can have multiple ways to calculate the first error probability corresponding to the target feature. For example, the transaction system calculates the volatility between the numerical values. For another example, the transaction system uses a model to calculate the law of historical transactions, uses the model to predict the ideal numerical value of the target transaction, and then compares the difference between the ideal numerical value of the target transaction and the actual numerical value.

[0152] As an example, the target feature dimension is the transaction amount, the current feature information is 100, and the first historical feature information is {98, 97, 80, 126, 101}. The transaction system can calculate the mean, volatility (e.g., standard deviation) of the first historical feature information, and then calculate the difference between the current feature information and the first historical feature information according to a preset rule (e.g., Z-score = 100 - mean / standard deviation).

[0153] (b) determining a second error probability corresponding to the target feature dimension based on the difference between the current feature information and the second historical feature information.

[0154] The specific method can refer to the method of determining the first error probability described above, and the present specification is not limited herein.

[0155] (c) weighting and averaging the first error probability and the second error probability according to the corresponding weight coefficients to obtain the error probability corresponding to the target feature dimension.

[0156] The first error probability is derived based on transaction data corresponding to the same transaction subject and the same transaction type. The second error probability is derived based on transaction data corresponding to similar transaction subjects and the same transaction type. The first error probability is more representative and is more important in deciding whether the target transaction has an error risk. Therefore, the weight system of the first error probability can be greater than the weight coefficient of the second error probability. The transaction system can weight and average the two error probabilities according to the corresponding weight coefficients to obtain the error probability corresponding to the target feature dimension.

[0157] (3) determining whether the target transaction has an error risk based on the error probability corresponding to each of the plurality of feature dimensions.

[0158] By comprehensively reviewing the target transaction in multiple feature dimensions and considering the error probability of the target transaction in different feature dimensions from multiple perspectives, it is possible to accurately determine whether the target transaction has an error risk.

[0159] In some embodiments, determining whether the target transaction has an error risk based on the error probability corresponding to each of the plurality of feature dimensions can include the following two ways:

[0160] (A) If the error probability corresponding to at least one of the plurality of feature dimensions is greater than a preset threshold, it is determined that the target transaction has an error risk.

[0161] Since in the transaction scenario, the transaction has a risk of financial loss, the cost is extremely high. Therefore, even if the error probability corresponding to most of the feature dimensions is low, if the error probability corresponding to at least one feature dimension is high, that is, if the operator makes an operation error in at least one feature dimension, the completed transaction may result in financial loss. In this case, in order to ensure the safety of the transaction and the funds of the transaction subject are not lost, the transaction system can determine that the target transaction has an error risk.

[0162] The preset threshold can be set according to human experience or obtained according to neural network training. Different feature dimensions can have different preset thresholds.

[0163] (B) If the error probability corresponding to each of the plurality of feature dimensions is less than or equal to the preset threshold, it is determined that the target transaction does not have an error risk.

[0164] When the error probability corresponding to each of the feature dimensions is less than or equal to the preset threshold, it can be considered that the operator does not have an operation error in these dimensions, and the transaction is safe and reliable. The transaction system can determine that the target transaction does not have an error risk.

[0165] S340: Determine a target approval policy applicable to the target transaction based on the identification result, and perform an approval process of the target transaction based on the target approval policy.

[0166] According to the identification result of whether the target transaction has an error risk, the transaction system can determine a target approval policy applicable to the target transaction. The target approval policy can be how to specifically approve the target transaction. Further, the transaction system can approve the target transaction based on the target approval policy.

[0167] In some embodiments, the determining the target approval policy applicable to the target transaction based on the identification result can include the following steps: obtaining an original approval policy corresponding to the target transaction; and in a case where the identification result indicates that the target transaction has an error risk, adjusting the original approval policy to obtain the target approval policy, the approval strength of the target approval policy being greater than that of the original approval policy.

[0168] The original approval policy corresponding to the target transaction can be an approval policy used in a normal case for a target transaction type corresponding to the target transaction. The original approval policy can be set in advance. For example, the holder of a transaction subject account can set rules and strategies for approval in advance according to different transaction types, so that each transaction type is provided with an applicable approval policy. When an operator initiates a transaction, the transaction system can automatically match the pre-set approval rules with the corresponding approval policy.

[0169] For example, a transaction of transferring money to a device supplier usually involves a larger amount of money than a transaction of transferring money to a stationery supplier. Therefore, the original approval policy corresponding to the former is usually more stringent than that corresponding to the latter.

[0170] When the identification result indicates that the target transaction has an error risk, the transaction system can adjust the original approval policy to approve the target transaction with a target approval policy with greater approval strength, so as to ensure the security of the transaction.

[0171] Figure 7 A schematic diagram showing a way of adjusting an original approval policy according to an embodiment of the present specification is shown. The following describes the way of adjusting the original approval policy in combination with the schematic diagram. Figure 7 Several ways of adjusting the original approval policy are described.

[0172] (a) increasing the number of approval nodes in the original approval policy, wherein different approval nodes correspond to different auditors.

[0173] At each approval node of the approval process, an auditor can approve the target transaction and check information. By increasing the number of approval nodes in the original approval strategy, increasing auditors, and conducting multi-level approval of the target transaction, the security of the target transaction can be enhanced, and the loss of funds can be avoided.

[0174] For example, as shown in adjustment mode one in the Figure 7 The original approval strategy of the target transaction includes an approval node corresponding to auditor 1. The target approval strategy of the adjusted target transaction includes an approval node corresponding to auditor 1 and an approval node corresponding to auditor 2.

[0175] (b) adjusting the first approval node in the original approval strategy to a second approval node, the second approval node corresponding to an auditor with a higher level than the first approval node corresponding to an auditor.

[0176] The auditor with a higher level usually has more abundant auditing knowledge and auditing experience, and the auditing decision made by the auditor with a higher level is usually more in line with the transaction situation and more accurate. By adjusting the approval node in the original approval strategy to an approval node corresponding to an auditor with a higher level, the security of the target transaction is enhanced, and the loss of funds is avoided.

[0177] For example, as shown in adjustment mode two in the Figure 7 The original approval strategy of the target transaction includes a first approval node corresponding to auditor 1. The target approval strategy of the adjusted target transaction includes a second approval node corresponding to auditor 2 with a higher level.

[0178] (c) adding risk prompt information to the approval node in the original approval strategy.

[0179] The risk prompt information can include a prompt statement that the target transaction has an error risk, or can include a characteristic dimension in the target transaction that has an error risk, so as to facilitate the auditor to quickly locate the source of the error risk and conduct auditing. The risk prompt information can be displayed on the terminal interface of the auditor.

[0180] For example, as shown in adjustment mode three in the Figure 7 The original approval strategy of the target transaction includes an approval node corresponding to auditor 1. The target approval strategy of the adjusted target transaction includes an approval node corresponding to auditor 1 with added risk prompt information.

[0181] In some embodiments, the transaction processing method can further include: in a case where the identification result indicates that the target transaction does not have an error risk, determining the original approval strategy as the target approval strategy. When the target transaction does not have an error risk, the transaction system can approve the target transaction according to the original approval strategy.

[0182] In some embodiments, the performing the approval process of the target transaction based on the target approval policy can comprise: in a case where the target approval policy comprises at least one approval node, sending an approval task to an auditor corresponding to the at least one approval node according to an approval order of the at least one approval node, the approval task instructing the auditor to audit the target transaction.

[0183] The approval tasks of the auditors corresponding to different approval nodes can be the same or different. For example, each auditor is responsible for approving data in a specific feature dimension. The auditors can audit the target transaction on terminals. The transaction system sends the approval task to the auditor corresponding to the approval node, so that the auditor audits the target transaction, thereby enhancing the security of the target transaction and avoiding loss of funds.

[0184] In some embodiments, for any one target approval node in the target approval policy, in a case where the target approval node comprises risk prompt information, the risk prompt information is included in the approval task sent to the auditor corresponding to the target approval node. The risk prompt information can be displayed on the terminal interface of the auditor. For example, the risk prompt information is displayed on the terminal interface before the auditor performs the approval, and the auditor can only approve the target transaction after reading and knowing the risk prompt information.

[0185] In some embodiments, after the performing the approval process of the target transaction based on the target approval policy, the transaction processing method can further comprise: if an approval result corresponding to the approval process represents approval passing, performing a transaction process of the target transaction. The approval result can be given by the auditor corresponding to the last approval node in the approval process, or can be derived by the transaction system according to the approval opinions given by the auditors corresponding to each approval node in the approval process. When the approval result represents approval passing, the transaction system can perform the transaction process such as exchange, payment, and transfer, to complete the outflow or exchange of funds.

[0186] In summary, the transaction processing method and the transaction system provided by the present specification determine the historical transactions of the same type as the target transaction. Since the historical transactions and the target transaction are of the same type, the transaction data have similarity and reference value. Therefore, the transaction system takes the transaction data of the historical transactions as a reference to identify the error risk of the transaction data of the target transaction, thereby ensuring the transaction efficiency, improving the accuracy of the identification result, and enhancing the security of the target transaction.

[0187] Another aspect of the present specification provides a non-transitory storage medium storing at least one set of executable instructions for performing the transaction processing. When the executable instructions are executed by a processor, the executable instructions direct the processor to implement the steps of the transaction processing method P300 described in the present specification. In some possible implementation, various aspects of the present specification can also be implemented in the form of a program product including program code. When the program product is run on a transaction system, the program code is used to cause the transaction system to perform the steps of the transaction processing method P300 described in the present specification. The program product for implementing the above method can include program code in a portable compact disc read-only memory (CD-ROM) and can be run on a transaction system. However, the program product of the present specification is not limited to this, and in the present specification, the readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system. The program product can adopt any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable storage medium may, for example, be but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or apparatus, or any combination of the above. More specific examples of the readable storage medium include an electrical connection having one or more wires, a portable disc, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. The computer readable storage medium can include a data signal propagating in a baseband or as a carrier wave in a propagated signal, where the readable program code is carried. Such a propagated signal can take on many forms, including but not limited to an electromagnetic signal, an optical signal, or any suitable combination thereof. The readable storage medium can also be any readable medium that is not a storage medium that can send, propagate, or transmit the program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the readable storage medium can be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, and the like, or any suitable combination thereof. The program code for performing the operations of the present specification can be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, C++, and the like, and a conventional procedural programming language such as the "C" programming language or the like. The program code can be executed entirely on a transaction system, partially on a transaction system, as an independent software package, partially on a transaction system and partially on a remote computing device, or entirely on a remote computing device.

[0188] The above described embodiments of the disclosure have been described. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order and still accomplish desirable results. Additionally, the processes depicted in the accompanying figures do not necessarily require the particular order shown or sequential order to achieve desirable results. In certain implementations, multitasking and parallel processing can be advantageous.

[0189] In light of the above, those skilled in the art will appreciate that the foregoing detailed description of the present disclosure is susceptible to various modifications and / or revisions without departing from the spirit and scope of the present disclosure. Although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement which is calculated to achieve the same purpose can be substituted for the specific embodiments shown. This disclosure is intended to cover any adaptations or variations of the present disclosure. Therefore, it is intended that the application be protected by: the broadest interpretation of the appended claims to take into account unforeseen equivalents and alternatives based on current knowledge, or future knowledge.

[0190] In addition, certain terminology has been used to describe embodiments of the disclosure. For example, "one embodiment," "an embodiment," and / or "some embodiments” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. Therefore, it is understood that the use of "embodiment" or "one embodiment" or "an embodiment" or "some embodiments” in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics can be combined in any suitable manner on one or more embodiments without limitation.

[0191] It should be understood that in the foregoing description of embodiments of the disclosure, various features can be combined in a single embodiment or in multiple embodiments of the disclosure. Such descriptions should be seen as but one embodiment of the methods made in the present disclosure and is submitted for patentability as such. That is, various embodiments of the disclosure can also be understood as combinations of the various features in sub-combinations. Each of the sub-combinations can be understood as a separate embodiment of the disclosure.

[0192] Each patent, patent application, publication of a patent application, and other material, for example articles, books, specifications, publications, documents, things, and / or the like which can have been cited or referred to in this document, are incorporated by reference into the present document, and are hereby made part of the present document, for all purposes, to the same extent as if each individual publication or item had been individually cited or incorporated by reference. Additionally, where a definition or use of a term in this document is provided to overcome a definition or use of the term in an individually cited document that is incorporated by reference, the definition or use of the term in this document prevails.

[0193] Finally, it should be understood that the embodiments of the application disclosed herein are illustrative of the principles of the present specification. Other modifications that fall within the scope of the present specification can also be made. Accordingly, the present specification discloses embodiments only as examples. Substantially any arrangement, which is neither specifically described nor explicitly illustrated, can be substituted for the specific embodiments disclosed, without departing from the scope of the present specification. Accordingly, the present specification discloses embodiments only as examples.

Claims

1. A transaction processing method applied to a transaction system, the method comprising: In response to detecting an operator's initiation of an operation on a target transaction, the transaction data of the target transaction is obtained; Identify multiple historical transactions and obtain transaction data for the multiple historical transactions, wherein the multiple historical transactions belong to the same transaction type as the target transaction; Based on the transaction data of the target transaction and the transaction data of the multiple historical transactions, identify whether the target transaction has any error risk and obtain the identification result; and Based on the identification results, a target approval strategy applicable to the target transaction is determined, and the approval process for the target transaction is executed based on the target approval strategy.

2. The method according to claim 1, wherein, The determination of multiple historical transactions includes: Determine the target transaction type to which the target transaction belongs; Obtain the set of historical transactions generated by the transaction system within a target historical period, wherein the end time of the target historical period is the initiation time of the target transaction; and Based on the target transaction type, obtain multiple historical transactions belonging to the target transaction type from the historical transaction set.

3. The method according to claim 2, wherein, The transaction system has multiple transaction entities registered, and the historical transaction set includes multiple subsets of historical transactions generated by these multiple transaction entities. The step of obtaining multiple historical transactions belonging to the target transaction type from the historical transaction set based on the target transaction type includes: Determine the first entity that generated the target transaction, and obtain at least one first historical transaction belonging to the target transaction type from the historical transaction subset corresponding to the first entity; Identify at least one second entity, and obtain at least one second historical transaction belonging to the target transaction type from the historical transaction subset corresponding to each of the at least one second entity, wherein each second entity satisfies a preset entity similarity condition with the first entity; and The at least one first historical transaction and the at least one second historical transaction are considered as the plurality of historical transactions.

4. The method according to claim 3, wherein, The subject similarity conditions include at least one of the following: They belong to the same geographical region. They belong to the same subject type. The same business scope, or They are at the same level in the transaction system.

5. The method according to claim 1, wherein, The step of identifying whether the target transaction has an error risk based on the transaction data of the target transaction and the transaction data of the multiple historical transactions includes: Based on the target transaction type to which the target transaction belongs, multiple feature dimensions are determined, and these multiple feature dimensions are related to the operations involved in the initiation process of the transaction under the target transaction type; Based on the transaction data of the target transaction and the transaction data of the multiple historical transactions, the error probability of the target transaction is determined from the multiple feature dimensions, respectively; and Based on the error probabilities corresponding to each of the multiple feature dimensions, it is determined whether the target transaction has an error risk.

6. The method according to claim 5, wherein, For any target feature dimension among the plurality of feature dimensions, the error probability corresponding to the target feature dimension is determined in the following manner: Based on the transaction data of the target transaction, determine the current feature information corresponding to the target feature dimension; Based on the transaction data of the multiple historical transactions, determine the historical feature information corresponding to the target feature dimension; as well as Based on the differences between the current feature information and the historical feature information, the error probability corresponding to the target feature dimension is determined.

7. The method according to claim 6, wherein, The plurality of historical transactions includes at least one first historical transaction and at least one second historical transaction. The transaction entity that initiated the first historical transaction is the same as the transaction entity that initiated the target transaction, and the transaction entity that initiated the second historical transaction is different from the transaction entity that initiated the target transaction. The historical feature information includes first historical feature information and second historical feature information. The first historical feature information is obtained based on the transaction data of the at least one first historical transaction, and the second historical feature information is obtained based on the transaction data of the at least one second historical transaction.

8. The method according to claim 7, wherein, Determining the error probability corresponding to the target feature dimension based on the difference between the current feature information and the historical feature information includes: Based on the differences between the current feature information and the first historical feature information, a first error probability corresponding to the target feature dimension is determined. Based on the difference between the current feature information and the second historical feature information, a second error probability corresponding to the target feature dimension is determined, and The error probability corresponding to the target feature dimension is obtained by weighting the first error probability and the second error probability according to their corresponding weight coefficients.

9. The method according to claim 5, wherein, The step of determining whether the target transaction has an error risk based on the error probabilities corresponding to each of the multiple feature dimensions includes: If at least one of the multiple feature dimensions has an error probability greater than a preset threshold, then the target transaction is determined to have an error risk; or If the error probability corresponding to each of the multiple feature dimensions is less than or equal to the preset threshold, then it is determined that the target transaction has no error risk.

10. The method according to claim 1, wherein determining the target approval strategy applicable to the target transaction based on the identification result includes: Obtain the original approval strategy corresponding to the target transaction; as well as If the identification result indicates that the target transaction has an error risk, the original approval strategy is adjusted to obtain the target approval strategy, and the approval strength of the target approval strategy is greater than that of the original approval strategy.

11. The method according to claim 10, wherein, The methods for adjusting the original approval strategy include one or more of the following: The number of approval nodes is increased in the original approval strategy, where different approval nodes correspond to different reviewers; Adjust the first approval node in the original approval strategy to a second approval node, where the level of the reviewer corresponding to the second approval node is higher than the level of the reviewer corresponding to the first approval node; or Add risk warning information to the approval nodes in the original approval strategy.

12. The method of claim 10, further comprising: If the identification result indicates that there is no risk of error in the target transaction, the original approval strategy is determined as the target approval strategy.

13. The method according to claim 1, wherein, The approval process for executing the target transaction based on the target approval strategy includes: When the target approval strategy includes at least one approval node, an approval task is sent to the reviewer corresponding to the at least one approval node in the order of approval of the at least one approval node, and the approval task instructs the reviewer to review the target transaction.

14. The method according to claim 13, wherein, For any target approval node in the target approval strategy, if the target approval node includes risk warning information, the approval task sent to the reviewer corresponding to the target approval node shall include the risk warning information.

15. The method according to claim 13, wherein, After executing the approval process for the target transaction based on the target approval strategy, the method further includes: If the approval result corresponding to the approval process indicates that the approval has been passed, then the transaction process of the target transaction will be executed.

16. A trading system, comprising: At least one storage medium, including at least one instruction set, for processing the target transaction; as well as At least one processor is communicatively connected to the at least one storage medium. When the system is running, the at least one processor reads the at least one instruction set and executes the transaction processing method according to any one of claims 1-15 according to the instructions of the at least one instruction set.

Images