An abnormal transaction detection method and device

Abstract

This specification discloses an abnormal transaction detection method and apparatus. The method includes: after monitoring a transaction status feature code conversion event, obtaining the feature code before conversion and the feature code after conversion corresponding to the event; obtaining the transaction status description information before conversion according to the feature code before conversion and the first mapping relationship corresponding thereto; and obtaining the transaction status description information after conversion according to the feature code after conversion and the second mapping relationship corresponding thereto; judging whether the semantics of the transaction status description information before conversion and the transaction status description information after conversion are the same according to a preset comparison algorithm; if the judgment result is different, determining that the transaction corresponding to the feature code conversion event is abnormal.

Description

Technical Field

[0001] This application relates to the field of computer application technologies, and in particular, to a method and device for detecting abnormal transactions. Background Art

[0002] In the field of e-commerce, most of the relevant information of transactions is in the form of digital content and is transmitted among transaction participants such as customers, merchants, and banks through computer networks. However, errors are inevitable in a large number of transaction information, and these abnormal transactions often lead to disputes and asset losses among transaction participants, and in most cases, only remedial and other related treatments can be carried out after losses are caused. Summary of the Invention

[0003] In view of this, this application discloses a method and device for detecting errors in transaction information.

[0004] According to the first aspect of the embodiments of this application, an abnormal transaction detection method is disclosed, including:

[0005] After monitoring a transaction status feature code conversion event, obtaining the feature code before conversion and the feature code after conversion corresponding to the event;

[0006] According to the feature code before conversion and the first mapping relationship corresponding thereto, obtaining the transaction status description information before conversion; and according to the feature code after conversion and the first mapping relationship corresponding thereto, obtaining the transaction status description information after conversion;

[0007] According to a preset comparison algorithm, determining whether the semantics of the transaction status description information before conversion and the transaction status description information after conversion are the same;

[0008] According to the second aspect of the embodiments of this application, an abnormal transaction detection device is disclosed, including:

[0009] A feature code acquisition module, configured to obtain the feature code before conversion and the feature code after conversion corresponding to the event after monitoring a transaction status feature code conversion event;

[0010] A description information acquisition module, configured to obtain the transaction status description information before conversion according to the feature code before conversion and the first mapping relationship corresponding thereto; and obtain the transaction status description information after conversion according to the feature code after conversion and the first mapping relationship corresponding thereto;

[0011] A semantics determination module, configured to determine whether the semantics of the transaction status description information before conversion and the transaction status description information after conversion are the same according to a preset comparison algorithm;

[0012] A result determination module, configured to determine that a transaction corresponding to the signature conversion event is abnormal when the result of the above determination module is different.

[0013] In the above technical solution, since the conversion process of the transaction status signature is monitored and the semantic information corresponding to the transaction status signatures before and after the conversion is verified, it can be determined that the transaction corresponding to the above conversion process is abnormal through the semantic errors of the two, achieving early detection of abnormal transactions and reducing transaction disputes and asset losses of transaction participants. Brief Description of the Drawings

[0014] The drawings herein are incorporated into the specification and form a part of this specification, showing embodiments consistent with this specification, and are used together with the text of the specification to explain the principles.

[0015] Figure 1 is a scenario example diagram of an abnormal transaction detection shown in this specification;

[0016] Figure 2 is a flow example diagram of an abnormal transaction detection method shown in this specification;

[0017] Figure 3 is a logic example diagram of a semantic comparison shown in this specification;

[0018] Figure 4 is a flow example diagram of a translation to intermediate description rule shown in this specification;

[0019] Figure 5 is a flow example diagram of determining a threat level according to semantic similarity shown in this specification;

[0020] Figure 6 is a flow example diagram of determining a threat level according to loss prediction shown in this specification;

[0021] Figure 7 is a structure example diagram of an abnormal transaction detection device shown in this specification;

[0022] Figure 8 is a structure example diagram of an alternative embodiment of an abnormal transaction detection device shown in this specification;

[0023] Figure 9 is a more specific schematic diagram of the hardware structure of a computing device shown in this specification. Detailed Embodiments

[0024] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the following will clearly and completely describe the technical solutions in one or more embodiments of this specification in conjunction with the accompanying drawings in one or more embodiments of this specification. Obviously, the described embodiments are only some of the embodiments, rather than all of them. Based on one or more embodiments of this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this application.

[0025] When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. On the contrary, they are merely examples of systems and methods consistent with some aspects of this specification as detailed in the appended claims.

[0026] The terms used in this specification are for the purpose of describing specific embodiments only and are not intended to limit this specification. The singular forms "a", "the", and "said" used in this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0027] It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "when" or "while" or "in response to determining".

[0028] In the field of e-commerce, most of the relevant information of transactions is in the form of digital content and is transmitted among transaction participants such as customers, merchants, and banks through computer networks. However, errors are inevitable in a large number of transaction information, and these abnormal transactions often lead to disputes and asset losses among transaction participants, and in most cases, only relevant treatments such as remedies can be carried out after losses are caused.

[0029] In practical applications, during the process of transaction information docking among trading entities such as customers, merchants, banks, and service providers, both parties to the transaction usually provide their respective transaction status feature codes for representing the transaction status. However, it is very likely that the transaction status feature codes adopted by different trading entities are not of a unified standard. For example, Merchant A uses the string "AA" to represent a successful transaction and "BB" to represent a failed transaction, while Merchant B uses the string "CC" to represent a successful transaction and "DD" to represent a failed transaction.

[0030] Therefore, to complete the docking of transaction information, it is necessary to perform the conversion of transaction status feature codes, and the errors that occur during this conversion process are often the reasons for abnormal transaction information.

[0031] Please refer to Figure 1 , Figure 1 which is a scenario example diagram of an abnormal transaction detection shown in this specification.

[0032] As Figure 1 shown, this scenario includes three levels of information, from bottom to top are the transaction entity layer, the transaction status feature code layer, and the transaction status description information layer, where:

[0033] The transaction entity layer includes Party A and Party B of the transaction. In this scenario, taking Party A sending its own transaction status information to Party B as an example;

[0034] The transaction status feature code layer includes the pre-conversion transaction status feature code and the post-conversion transaction status feature code. In this layer, the pre-conversion transaction status feature code comes from the transaction status information that Party A attempts to send to Party B. Its specific conversion can be completed by Party A's e-commerce system or by a third-party trading platform. After the transaction status feature code conversion event, the pre-conversion transaction status feature code is converted into the post-conversion transaction status feature code for sending to Party B to complete the task of Party A sending its own transaction status information to Party B;

[0035] The transaction status description information layer includes the pre-conversion transaction status description information and the post-conversion transaction status description information. This layer is the intermediate data generated by an abnormal transaction monitoring method shown in this specification below. For its specific application, please refer to the relevant content below.

[0036] Based on the above analysis, for transactions with a transaction status feature code conversion process, this specification proposes a technical solution that determines whether an abnormal transaction occurs by semantically verifying the result of the above conversion process to judge whether the above conversion process is carried out normally.

[0037] In implementation, after detecting a transaction status feature code conversion event, the pre-conversion transaction status feature code and the post-conversion transaction status feature code corresponding to the event are respectively interpreted as pre-conversion transaction status description information and post-conversion transaction status description information, and then semantic comparison is performed on the pre-conversion transaction status description information and the post-conversion transaction status description information to detect abnormal transactions.

[0038] In the above technical solution, on the one hand, since semantic comparison is performed on the transaction status description information corresponding to the pre-conversion transaction status feature code and the post-conversion transaction status feature code respectively, it is possible to determine whether the above conversion process is carried out normally according to the comparison result, and then determine whether there are abnormal transactions; on the other hand, since this solution can be carried out on the same platform as the conversion process of the transaction status feature code, and immediate conversion and immediate inspection can be performed, abnormal transactions can be detected early, avoiding asset losses and disputes among transaction participants.

[0039] The present application will be described below through specific embodiments in combination with specific application scenarios.

[0040] Please refer to Figure 2 , Figure 2 which is a flowchart example of an abnormal transaction detection method shown in this specification. The method performs the following steps:

[0041] S201, after detecting a transaction status feature code conversion event, obtain the pre-conversion feature code and the post-conversion feature code corresponding to the event;

[0042] S202, according to the pre-conversion feature code and the first mapping relationship corresponding thereto, obtain the pre-conversion transaction status description information; and according to the post-conversion feature code and the second mapping relationship corresponding thereto, obtain the post-conversion transaction status description information;

[0043] S203, according to a preset comparison algorithm, determine whether the semantics of the pre-conversion transaction status description information and the post-conversion transaction status description information are the same;

[0044] S204, if the judgment result is different, determine that there is an abnormality in the transaction corresponding to the feature code conversion event.

[0045] In this specification, the conversion of the transaction status feature code is a prior art, referring to all related technologies that conform to the features included in the transaction status feature code conversion process in the foregoing scenario. Its specific implementation process can depend on database queries, or can depend on table item correspondence, etc. in various forms. This specification does not make specific limitations, and those skilled in the art can refer to relevant technical documents to obtain relevant information.

[0046] For example, Company A and Company B conduct transaction information docking. Company A provides a set of transaction status characteristic codes for representing its transaction status, including "A01" representing "transaction completed", "A02" representing "payment for the transaction not received", "A03" representing "transaction cancelled", and so on; Company B also provides a set of transaction status characteristic codes for representing its transaction status, including "B100" representing "transaction completed", "B010" representing "payment for the transaction not received", "B001" representing "transaction cancelled", and so on; Obviously, the transaction status characteristic codes used by the two companies are not universal and need to be converted.

[0047] Suppose Company A needs to send the information of "payment for the transaction not received" to Company B, then it will give the corresponding transaction status characteristic code "A02". Also suppose that due to system upgrades or other reasons during the conversion process of this transaction status characteristic code, "A02" is wrongly converted to "B100", which will cause Company B to mistakenly think that the transaction is in the "transaction completed" state corresponding to "B100", and may thus lead to asset disputes between the two parties.

[0048] If the solution in the above embodiment is applied, after the above conversion event occurs, the pre-conversion characteristic code "A02" and the post-conversion characteristic code "B100" corresponding to this event can be obtained; according to the preset mapping relationship corresponding to this pre-conversion characteristic code, the corresponding pre-conversion transaction status description information can be obtained, such as the string "payment for the transaction not received"; similarly, according to the preset mapping relationship corresponding to this post-conversion characteristic code, the corresponding post-conversion transaction status description information can be obtained, such as the string "transaction completed"; according to the preset comparison algorithm, compare whether the semantics of the above two transaction status description information are the same. When it is determined that the semantics of "payment for the transaction not received" and "transaction completed" are not the same, it can be determined that the above transaction status characteristic code conversion event has an abnormality, and then it can be determined that the transaction corresponding to this event has an abnormality.

[0049] In this specification, the pre-conversion and post-conversion transaction status description information can adopt the same or different description rules. For example, for expressing the semantics of "transaction successful" in the same way, both can adopt the strict string "transaction successful", or can arbitrarily adopt other description rules such as "GOOD", "SUCCESS", etc.

[0050] Please refer to Figure 3 , Figure 3 which is a logical example diagram of semantic comparison shown in this specification. For the above various situations, this solution provides different execution strategies for semantic comparison.

[0051] In a specific embodiment shown, the description rules for the transaction status description information before and after conversion can be the same. The implementation method for determining whether the semantics of the above two transaction status description information are the same can be to determine whether their semantics are the same through a string matching method; it can also be to query a thesaurus based on one of them and determine whether the other is included, and then determine whether their semantics are the same.

[0052] In a specific embodiment shown, the description rules for the transaction status description information before and after conversion can be different. The implementation method for determining whether the semantics of the above two transaction status description information are the same can include: translating at least one of the transaction status description information before conversion and the transaction status description information after conversion.

[0053] Specifically, the transaction status description information after conversion can be translated according to the description rule adopted by the transaction status description information before conversion, or the transaction status description information before conversion can be translated according to the description rule adopted by the transaction status description information after conversion.

[0054] Alternatively, determine an intermediate description rule that is different from either of the description rules adopted by the transaction status description information before and after conversion, and translate the transaction status description information before conversion and the transaction status description information after conversion according to this intermediate description rule.

[0055] For example, the transaction status description information before conversion is "successful", and the adopted description rule is denoted as description rule A; the transaction status description information after conversion is "FAIL", and the adopted description rule is description rule B.

[0056] One implementable solution is to translate "successful" into the expression under description rule B, such as "SUCCESS", or translate "FAIL" into the expression under description rule A, such as "failed". Under the same description rule, it is more convenient to compare the semantics.

[0057] Please refer to Figure 4 , Figure 4 which is a flow example diagram showing a translation to an intermediate description rule in this specification.

[0058] Another implementable solution provided by this application is to determine a new intermediate description rule, that is, description rule C, and then translate the transaction status description information before conversion and the transaction status description information after conversion into the expressions under this intermediate description rule. For example, translate "successful" in the above example into "yes" and "FAIL" into "no". Under the same description rule, that is, description rule C, it is more convenient to compare the semantics.

[0059] It is understandable that for the translation of cross-description rules, various existing technologies can be used to complete it. This specification does not make specific limitations, and those skilled in the art can refer to relevant technical materials to complete the design of this part.

[0060] In this specification, the above method can also be further expanded according to the obtained information. For example, according to a preset evaluation rule, the threat level of a transaction with an anomaly can be determined. The evaluation rule can be a semantic evaluation rule for determining the threat level based on the semantic similarity of the transaction state description information before and after conversion, or a loss threat evaluation rule for determining the threat level based on the predicted loss, or other evaluation rules obtained through the analysis of the transaction state description information and the corresponding transaction accident history, or a combination of the above multiple rules.

[0061] Please refer to Figure 5 , Figure 5 which is a flowchart example showing how to determine the threat level according to semantic similarity in this specification.

[0062] If the scheme of determining the threat level according to semantic similarity is adopted, it is necessary to first determine the semantic similarity between the transaction state description information before conversion and the transaction state description information after conversion according to a preset semantic similarity evaluation algorithm, and then determine the threat level of the transaction with an anomaly according to the above similarity and a preset semantic evaluation rule. It is understandable that the determination of the above semantic similarity can be achieved in various ways.

[0063] For example: by a method similar to the above translation into the intermediate description rule, the semantics of the transaction state description information are rated. The higher the rating, the closer it is to the complete success of the transaction, and the lower the rating, the closer it is to the complete failure of the transaction. Then, the semantic similarity between the two transaction state description information can be obtained through the results of the above rating. The closer the ratings are, the closer the semantics of the two are, and it can be considered that the losses caused will be smaller, and thus the threat level of the abnormal transaction can be obtained.

[0064] Another example: adopting natural language analysis technology, using a co-occurrence matrix method based on statistics or a language model construction method based on neural networks to obtain the word vectors of the transaction state description information, and then determining the semantic similarity between the two according to the distance between the two word vectors, and finally obtaining the threat level corresponding to the abnormal transaction.

[0065] Please refer to Figure 6 , Figure 6 which is a flowchart example showing how to determine the threat level according to loss prediction in this specification.

[0066] If the solution of determining the threat level based on the predicted loss is adopted, it is necessary to first predict the losses caused to both parties of the transaction by this abnormal transaction according to the semantics of the pre-conversion transaction status description information and the semantics of the post-conversion transaction status description information, and then determine the threat levels of this abnormal transaction to both parties of the transaction according to the predicted losses of both parties of the transaction and the loss threat evaluation rule.

[0067] It can be understood that for the same abnormal transaction, the losses caused to both parties of the transaction may not be the same. Therefore, the corresponding threat levels should also be the threat levels for both parties of the transaction respectively.

[0068] For example, assume that the above abnormal transaction is that the store sends a "cancel order" message to the buyer, and this message is mis-converted to a "completed order" message during the conversion of the transaction status feature code. In fact, the order has indeed been cancelled. For the buyer, there is no actual loss, but for the store, it may face risks such as user complaints. Therefore, the threat of this transaction anomaly to both parties is not the same.

[0069] Specifically, according to the semantics of the pre-conversion transaction status description information and the semantics of the post-conversion transaction status description information, on the one hand, the potential asset losses brought by this transaction can be obtained from the transaction information database, and on the other hand, the nature of the transaction participants, such as suppliers, banks, etc., can be combined, and then the losses caused by this abnormal transaction to both parties of the transaction can be predicted comprehensively and respectively.

[0070] In this specification, an abnormal handling solution in the case of determining that a transaction is abnormal is also provided.

[0071] In a specific embodiment shown, the above abnormal handling may include:

[0072] Recording the transaction with the anomaly in the error log; and / or

[0073] Issuing an alarm for the transaction with the anomaly; and / or

[0074] Fusing the transaction with the anomaly.

[0075] Particularly, according to the semantic comparison of the pre-conversion transaction status description information and the post-conversion transaction status description information, the specific error location of the transaction status feature code conversion event that causes the above abnormal transaction can be determined, and combined with the translation technology mentioned above, the correct result in the transaction status feature code conversion event can be determined as the correction information. According to the above error location and correction information, it can provide a maintenance reference for maintenance personnel or perform automatic function maintenance, such as replacing the original transaction status feature code conversion relationship corresponding to this error location in the database with the correction information, and so on.

[0076] This specification also provides an embodiment of an abnormal transaction detection device corresponding to the above method.

[0077] Please refer to Figure 7 , Figure 7 which is a structural example diagram of an abnormal transaction detection device shown in this specification. The device includes:

[0078] A feature code acquisition module 801, configured to acquire the pre-conversion feature code and the post-conversion feature code corresponding to the event after detecting a transaction status feature code conversion event;

[0079] A description information acquisition module 802, configured to obtain pre-conversion transaction status description information according to the pre-conversion feature code and the first mapping relationship corresponding thereto; and obtain post-conversion transaction status description information according to the post-conversion feature code and the first mapping relationship corresponding thereto;

[0080] A semantic judgment module 803, configured to judge whether the semantics of the pre-conversion transaction status description information and the post-conversion transaction status description information are the same according to a preset comparison algorithm;

[0081] A result determination module 804, configured to determine that the transaction corresponding to the feature code conversion event is abnormal when the result of the above judgment module 803 is different.

[0082] In this specification, whether the description rules adopted for the pre-conversion transaction status description information are the same as those adopted for the post-conversion transaction status description information can correspond to a variety of different processing procedures. For example, if the description rules adopted for the pre-conversion transaction status description information are the same as those adopted for the post-conversion transaction status description information, semantic comparison can be directly performed on both within this description rule; if the description rules adopted for the pre-conversion transaction status description information are different from those adopted for the post-conversion transaction status description information, then by means of translation or the like, the above pre-conversion transaction status description information and post-conversion transaction status description information can be unified to the same description rule for semantic comparison.

[0083] In a specific embodiment shown, the description rules adopted for the pre-conversion transaction status description information are different from those adopted for the post-conversion transaction status description information. The above semantic judgment module 803 can specifically be configured to: translate at least one of the pre-conversion transaction status description information and the post-conversion transaction status description information.

[0084] In a specific embodiment shown, the above semantic judgment module 803 may specifically translate the pre-conversion transaction status description information and the post-conversion transaction status description information according to an intermediate description rule that is different from any of the description rules adopted by the pre-conversion and post-conversion transaction status description information.

[0085] In a specific embodiment shown, the above semantic judgment module 803 may specifically translate either the pre-conversion or the post-conversion transaction status description information under the description rule of the other, that is, translate the post-conversion transaction status description information according to the description rule adopted by the pre-conversion transaction status description information, or translate the pre-conversion transaction status description information according to the description rule adopted by the post-conversion transaction status description information.

[0086] On the basis of completing the above function of determining abnormal transactions, this device can also evaluate the threat caused by the abnormal transactions.

[0087] Please refer to Figure 8 , Figure 8 FIG. is a structural example diagram of an alternative embodiment of an abnormal transaction detection device shown in this specification. In the specific embodiment corresponding to this figure, the device further includes a threat evaluation module 805 for determining the threat level of the transaction with an abnormality according to a preset evaluation rule. The evaluation rule may be a semantic evaluation rule for determining the threat level according to the semantic similarity of the pre-conversion and post-conversion transaction status description information, or a loss threat evaluation rule for determining the threat level according to the predicted loss, or other evaluation rules obtained based on the transaction status description information and the corresponding transaction accident history analysis, or a combination of the above multiple rules.

[0088] In a specific embodiment shown, the evaluation rule includes a semantic evaluation rule for determining the threat level according to the semantic similarity of the pre-conversion transaction status description information and the post-conversion transaction status description information; then the threat evaluation module 805 in this device is further configured to: determine the semantic similarity of the pre-conversion transaction status description information and the post-conversion transaction status description information according to a preset semantic similarity evaluation algorithm; in this embodiment, the function of the threat evaluation module 805 to determine the threat level of the transaction with an abnormality according to the preset evaluation rule includes: determining the threat level of the transaction with an abnormality according to the semantic similarity of the pre-conversion transaction status description information and the post-conversion transaction status description information, and the semantic evaluation rule.

[0089] In a specific embodiment shown, the evaluation rule includes a loss threat evaluation rule for determining the threat level according to the predicted loss; the threat evaluation module 805 is further configured to: respectively predict the losses of both parties to the transaction caused by the abnormal transaction according to the semantics of the transaction status description information before conversion and the semantics of the transaction status description information after conversion; the process of the threat evaluation module 805 determining the threat level of the transaction with an anomaly according to the preset evaluation rule includes: determining the threat levels of the abnormal transaction to both parties to the transaction according to the predicted losses of both parties to the transaction and the loss threat evaluation rule.

[0090] In this specification, the abnormal transaction detection device also provides various abnormal handling functions.

[0091] In a specific embodiment shown, the device further includes an abnormal handling module for performing abnormal handling when it is determined that the transaction is abnormal.

[0092] In a specific embodiment shown, the above abnormal handling module can specifically be configured to:

[0093] Record the transaction with the anomaly in the error log; and / or

[0094] Send an alarm for the transaction with the anomaly; and / or

[0095] Fuse the transaction with the anomaly.

[0096] For the specific implementation processes of the functions and roles of each module in the above device, please refer to the implementation processes of the corresponding steps in the above method for details, which will not be elaborated here.

[0097] An embodiment of this specification also provides a computer device, which at least includes a memory, a processor, and a computer program stored on the memory and executable on the processor. Wherein, when the processor executes the program, it implements the foregoing abnormal transaction detection method.

[0098] Figure 9 A more specific schematic diagram of the hardware structure of the computing device provided by the embodiment of this specification is shown. The device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. Wherein, the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are communicatively connected to each other inside the device through the bus 1050.

[0099] The processor 1010 can be implemented in the form of a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits, etc., and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0100] The memory 1020 can be implemented in the form of a ROM (Read Only Memory), a RAM (Random Access Memory), a static storage device, a dynamic storage device, etc. The memory 1020 can store an operating system and other application programs. When implementing the technical solutions provided in the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 1020 and are called and executed by the processor 1010.

[0101] The input / output interface 1030 is used to connect to the input / output module to achieve information input and output. The input / output module can be configured as a component in the device (not shown in the figure) or can be externally connected to the device to provide corresponding functions. Among them, the input device can include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device can include a display, a speaker, a vibrator, an indicator light, etc.

[0102] The communication interface 1040 is used to connect to the communication module (not shown in the figure) to achieve communication interaction between this device and other devices. Among them, the communication module can achieve communication through a wired method (such as USB, network cable, etc.) or can also achieve communication through a wireless method (such as a mobile network, WIFI, Bluetooth, etc.).

[0103] The bus 1050 includes a path for transmitting information between various components of the device (such as the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040).

[0104] It should be noted that although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, this device may also include other components necessary for normal operation. In addition, those skilled in the art can understand that the above device may also only include the components necessary to implement the solutions of the embodiments of this specification and do not necessarily include all the components shown in the figure.

[0105] An embodiment of this specification also provides a computer-readable storage medium, on which a computer program is stored. When the program is executed by a processor, the foregoing abnormal transaction detection method is implemented.

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

[0107] From the description of the above embodiments, those skilled in the art can clearly understand that the embodiments of this specification can be implemented by means of software plus a necessary general hardware platform. Based on such an understanding, the technical solutions of the embodiments of this specification, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product can be stored in a storage medium such as ROM / RAM, magnetic disk, optical disc, etc., and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments of this specification.

[0108] The systems, devices, modules, or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, and the specific form of the computer can be a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of several of these devices.

[0109] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. Each embodiment focuses on the differences from other embodiments. In particular, for the device embodiments, since they are basically similar to the method embodiments, the description is relatively simple. For the relevant parts, reference can be made to the description of the method embodiments. The device embodiments described above are only illustrative. The modules described as separate components may or may not be physically separated. When implementing the solutions of the embodiments of this specification, the functions of the modules can be implemented in one or more software and / or hardware. It is also possible to select some or all of the modules according to actual needs to achieve the purpose of the solutions of this embodiment. A person of ordinary skill in the art can understand and implement it without creative efforts.

[0110] The above is only the specific implementation manner of the embodiments of this specification. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of the embodiments of this specification, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the embodiments of this specification.

Claims

1. An abnormal transaction detection method, comprising: Upon a conversion of a transaction status feature code corresponding to a transaction, obtaining the transaction status feature code before conversion and the transaction status feature code after conversion corresponding to the transaction; wherein, the transaction status feature codes before and after conversion respectively represent the transaction status based on different criteria; Performing semantic verification on the transaction status feature code before conversion and the transaction status feature code after conversion to determine whether the transaction status description information before conversion corresponding to the transaction status feature code before conversion is semantically the same as the transaction status description information after conversion corresponding to the transaction status feature code after conversion; If not, determining that the transaction is abnormal.

2. The method according to claim 1, wherein the step of responding to a conversion of a transaction status feature code corresponding to a transaction, comprises: Responding to detecting a transaction status feature code conversion event corresponding to the transaction.

3. The method according to claim 1, wherein the step of performing semantic verification on the transaction status feature code before conversion and the transaction status feature code after conversion, comprises: Obtaining the transaction status description information before conversion corresponding to the transaction status feature code before conversion according to a first mapping relationship between the transaction status feature code before conversion and the transaction status description information before conversion; and obtaining the transaction status description information after conversion corresponding to the transaction status feature code after conversion according to a second mapping relationship between the transaction status feature code after conversion and the transaction status description information after conversion; Determining whether the transaction status description information before conversion is semantically the same as the transaction status description information after conversion.

4. The method according to claim 1, wherein the description rule adopted by the transaction status description information before conversion is the same as the description rule adopted by the transaction status description information after conversion; The step of performing semantic verification on the transaction status feature code before conversion and the transaction status feature code after conversion, comprises: Performing string matching on the transaction status feature code before conversion and the transaction status feature code after conversion; or, Performing a thesaurus query based on either one of the transaction status feature code before conversion and the transaction status feature code after conversion to determine whether the other one is included.

5. The method according to claim 1, wherein the description rule adopted by the transaction status description information before conversion is different from the description rule adopted by the transaction status description information after conversion; The step of performing semantic verification on the transaction status feature code before conversion and the transaction status feature code after conversion, comprises: Translating at least one of the transaction status description information before conversion and the transaction status description information after conversion.

6. The method according to claim 1, the method further comprises: Determining the threat level of the transaction determined to be abnormal according to a preset evaluation rule.

7. The method according to claim 6, wherein the evaluation rule includes a semantic evaluation rule for determining the threat level according to the semantic similarity between the transaction status description information before conversion and the transaction status description information after conversion; The method further comprises: Determine the semantic similarity between the transaction status description information before conversion and the transaction status description information after conversion according to a preset semantic similarity evaluation algorithm; The determining the threat level of the transaction with anomalies according to a preset evaluation rule includes: Determine the threat level of the transaction with anomalies according to the semantic similarity between the transaction status description information before conversion and the transaction status description information after conversion, and the semantic evaluation rule.

8. The method according to claim 6, wherein the evaluation rule includes a loss threat evaluation rule for determining the threat level according to the predicted loss; The method also includes: Predict the losses of both parties to the transaction with anomalies respectively according to the semantics of the transaction status description information before conversion and the semantics of the transaction status description information after conversion; The determining the threat level of the transaction with anomalies according to a preset evaluation rule includes: Determine the threat levels of the transaction with anomalies to both parties to the transaction respectively according to the predicted losses of both parties to the transaction and the loss threat evaluation rule.

9. An abnormal transaction detection device, comprising: An acquisition module, configured to acquire the transaction status feature code before conversion and the transaction status feature code after conversion corresponding to the transaction in response to a conversion of the transaction status feature code corresponding to the transaction; wherein, the transaction status feature codes before and after conversion respectively represent the transaction status based on different criteria; A semantic verification module, configured to perform semantic verification on the transaction status feature code before conversion and the transaction status feature code after conversion, so as to determine whether the transaction status description information before conversion corresponding to the transaction status feature code before conversion is semantically the same as the transaction status description information after conversion corresponding to the transaction status feature code after conversion; A determination module, configured to determine that the transaction has an anomaly if the transaction status description information before conversion corresponding to the transaction status feature code before conversion is not semantically the same as the transaction status description information after conversion corresponding to the transaction status feature code after conversion.

10. A computer device, comprising a processor, a memory, and a computer program stored in the memory and executable by the processor; wherein, when the computer program is executed by the processor, the method according to any one of claims 1 to 8 is implemented.

Images