WO2024093960A1 - 异常交易应对策略的验证方法和验证装置 - Google Patents

异常交易应对策略的验证方法和验证装置 Download PDF

Info

Publication number
WO2024093960A1
WO2024093960A1 PCT/CN2023/128100 CN2023128100W WO2024093960A1 WO 2024093960 A1 WO2024093960 A1 WO 2024093960A1 CN 2023128100 W CN2023128100 W CN 2023128100W WO 2024093960 A1 WO2024093960 A1 WO 2024093960A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
transaction
strategy
knowledge
node
Prior art date
Application number
PCT/CN2023/128100
Other languages
English (en)
French (fr)
Inventor
汪自立
蒋宁
肖冰
吴海英
夏粉
马超
Original Assignee
马上消费金融股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 马上消费金融股份有限公司 filed Critical 马上消费金融股份有限公司
Publication of WO2024093960A1 publication Critical patent/WO2024093960A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
    • G06F16/36—Creation of semantic tools, e.g. ontology or thesauri
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N5/00—Computing arrangements using knowledge-based models
    • G06N5/02—Knowledge representation; Symbolic representation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists

Definitions

  • the present disclosure relates to the field of artificial intelligence technology, and in particular to a verification method and a verification device for an abnormal transaction response strategy.
  • the present invention provides a verification method and a verification device for an abnormal transaction response strategy.
  • the present disclosure provides a method for verifying an abnormal transaction response strategy, which includes: constructing a payment knowledge graph based on payment field data and general data; determining strategy scenario information based on the payment knowledge graph and historical transaction data, and constructing a strategy graph based on the strategy scenario information; generating transaction simulation data corresponding to the abnormal transaction means to be verified based on the payment knowledge graph and the strategy graph; verifying the abnormal transaction response strategy corresponding to the abnormal transaction means to be verified based on the transaction simulation data, and obtaining a strategy verification result.
  • the present disclosure provides a verification device for an abnormal transaction response strategy.
  • the verification device for the abnormal transaction response strategy includes: a construction module, which is used to construct a payment knowledge graph based on payment field data and general data, and is used to determine strategy scenario information based on the payment knowledge graph and historical transaction data, and to construct a strategy graph based on the strategy scenario information; a generation module, which is used to generate transaction simulation data corresponding to the abnormal transaction means to be verified based on the payment knowledge graph and the strategy graph; and a verification module, which is used to verify the abnormal transaction response strategy corresponding to the abnormal transaction means to be verified based on the transaction simulation data to obtain a strategy verification result.
  • the present disclosure provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores one or more computer programs executable by the at least one processor, and when one or more of the computer programs are executed by the at least one processor, the at least one processor is enabled to execute the above-mentioned method for verifying the abnormal transaction response strategy.
  • the present disclosure provides a computer-readable storage medium having a computer program stored thereon, which implements the above-mentioned method for verifying the abnormal transaction response strategy when executed by a processor/processing core.
  • FIG1 is a flow chart of a method for verifying an abnormal transaction response strategy according to an embodiment of the present disclosure
  • FIG2 is a schematic diagram of a payment knowledge graph framework according to an embodiment of the present disclosure.
  • FIG3 is a schematic diagram of a payment knowledge graph according to an embodiment of the present disclosure.
  • FIG4 is a schematic diagram of a strategy map according to an embodiment of the present disclosure.
  • FIG5 is a schematic diagram of a strategy map according to an embodiment of the present disclosure.
  • FIG6 is a schematic diagram of a strategy map according to an embodiment of the present disclosure.
  • FIG7 is a flow chart of a method for verifying an abnormal transaction response strategy according to an embodiment of the present disclosure
  • FIG8 is a schematic diagram of sub-graph merging according to an embodiment of the present disclosure.
  • FIG9 is a schematic diagram of a process of acquiring a candidate payment knowledge subgraph according to an embodiment of the present disclosure
  • FIG10 is a schematic diagram of an extended strategy map according to an embodiment of the present disclosure.
  • FIG11 is a block diagram of a verification device for an abnormal transaction response strategy according to an embodiment of the present disclosure.
  • FIG. 12 is a block diagram of an electronic device according to an embodiment of the present disclosure.
  • the verification method for abnormal transaction response strategies provided by the present invention can generate transaction simulation data in a timely manner without relying on the transaction data of real abnormal transaction means, thereby facilitating accurate and timely verification of corresponding abnormal transaction response strategies, shortening the time between the emergence of new abnormal transaction means and the verification of abnormal transaction response strategies, and being able to quickly formulate abnormal transaction response strategies with better effects, thereby further ensuring the safety of users' funds.
  • the verification method of the abnormal transaction response strategy of the embodiment of the present disclosure can be performed by an electronic device such as a terminal device or a server.
  • the terminal device can be a user equipment (UE), a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (PDA), a handheld device, a computing device, a vehicle-mounted device, a wearable device, etc.
  • the verification method can be implemented by a processor calling a computer-readable program instruction stored in a memory.
  • the server can be an independent physical server, a server cluster composed of multiple servers, or a cloud server capable of cloud computing.
  • Fig. 1 is a flow chart of a method for verifying an abnormal transaction response strategy according to an embodiment of the present disclosure.
  • the method for verifying an abnormal transaction response strategy includes steps S11 to S14.
  • a payment knowledge graph is constructed based on payment field data and general data.
  • General data is data that is universal in multiple fields.
  • the payment knowledge graph is used to characterize entities in the payment field, the attributes of entities, and the relationships between entities. Entities include user entities and payment-related institution entities.
  • the entity may also include other entities, such as an address entity, etc.
  • Payment field data refers to professional data about the payment field, while general data refers to general data that may be involved in all fields.
  • payment field data include industry-regulated data, relevant information and payment business data in the payment industry, among which the relevant information mainly includes public information of payment-related institutional entities (for example, banks, third-party payment institutions) in the laws and regulations in the payment field, and payment business data includes data in the business systems of banks and other payment-related organizations (for example, data in a bank's credit card payment system).
  • relevant information mainly includes public information of payment-related institutional entities (for example, banks, third-party payment institutions) in the laws and regulations in the payment field
  • payment business data includes data in the business systems of banks and other payment-related organizations (for example, data in a bank's credit card payment system).
  • the general data includes geographic information data, time information data, etc.
  • Knowledge Graph is a knowledge domain mapping diagram obtained by visualizing the knowledge domain.
  • knowledge graph can be used to describe various entities and concepts, as well as the relationships between them, and can be regarded as a semantic network.
  • the basic component unit of the knowledge graph is the "entity-relationship-entity" triple, as well as the entity and its related attribute-value pairs. Entities are connected to each other through relationships to form a network knowledge structure.
  • the payment knowledge graph is a knowledge graph in the payment field, which is used to represent various entities in the payment field, the attributes of entities, and the relationships between entities.
  • entities in the basic component unit "entity-relationship-entity" triple, most entities should belong to the payment field (a small number of entities are common to all fields), and When determining relationships, more emphasis is placed on determining the associations between entities in the payment field (for example, consumption time, payment amount, etc.).
  • the payment knowledge graph When constructing the payment knowledge graph, you can use a top-down (data schema) construction method or a bottom-up (bottom-up) construction method.
  • a top-down construction method you can first design a data schema for the payment knowledge graph, then extract data in a targeted manner based on the data schema, and construct the extracted data into a graph form to obtain the payment knowledge graph.
  • the bottom-up construction method you usually first collect and organize data (including payment field data and related general data), then summarize and summarize the response characteristics based on the data content, refine the framework, and gradually form the final data schema to obtain the corresponding payment knowledge graph.
  • a payment knowledge graph is constructed based on payment field data and general data, including: first, from the industry regulation data of the payment industry, the basic concepts and the relationships between concepts in the payment process are summarized and concluded, and a payment knowledge graph framework is established based on the relationships between concepts; second, based on relevant information of the payment industry, some of the above concepts are instantiated as entities, and the attributes of each entity and the corresponding relationships between entities are confirmed; third, based on payment business data (such as business system data of the payment industry), another part of the above concepts are instantiated as entities, and the attributes of each entity and the corresponding relationships between entities are confirmed; then, based on general data, some of the above concepts are instantiated as entities, and the attributes of each entity and the corresponding relationships between entities are confirmed, so as to obtain a payment knowledge graph including the relationships between entities; finally, the payment knowledge graph is constructed according to the payment knowledge graph framework, entities, and the relationships between entities.
  • the payment knowledge graph is a structured semantic knowledge base in the payment field. It aggregates a large amount of knowledge by reducing the data granularity from the document level to the data level. It can quickly describe the entities in the payment field and their relationships, and achieve rapid response and reasoning of payment knowledge.
  • the entities involved in the payment knowledge graph can include user entities and payment-related institutional entities, where user entities refer to individuals who have payment transactions, and payment-related institutional entities refer to organizations or units related to resources, such as banks, stores, etc.
  • step S12 the strategy field is determined based on the payment knowledge graph and historical transaction data. and construct a strategy map based on the strategy scenario information.
  • the historical transaction data is transaction data in the payment field that has actually been generated, which can be obtained from a business system in the payment field or in other ways, and the embodiments of the present disclosure are not limited to this.
  • the payment knowledge graph mainly reflects information in the payment field from the level of entities and their relationships, including the associations between various people, organizations, etc., but lacks knowledge or information at the behavioral level. Therefore, based on the payment knowledge graph and historical transaction data, the attributes of the entities are summarized, the transaction scenarios are statistically abstracted, and the corresponding transaction behaviors are analyzed to obtain strategic scenario information, and the strategic scenario information is used to construct a strategic graph. In other words, the strategic graph tends to reflect knowledge in the payment field from the level of transaction behavior.
  • the strategy graph represents the payment behaviors of multiple user groups in the payment field in multiple transaction scenarios, and the multiple user groups are determined based on the categories of the groups to which each user entity in the payment knowledge graph belongs.
  • the strategy scenario information includes at least a user group node, a transaction scenario node, and a rule feature node.
  • step S12 includes: clustering each user entity in the payment knowledge graph to determine at least one user group node; determining the transaction scenario node corresponding to each user group node and the transaction behavior characteristics under each transaction scenario node based on historical transaction data; determining at least one rule feature node corresponding to the transaction scenario node based on the transaction behavior characteristics under each transaction scenario node.
  • the corresponding relationship between these user group nodes, transaction scenario nodes, and rule feature nodes constitutes the corresponding strategy graph.
  • Clustering is the process of aggregating entities with high similarity into one category.
  • the user entities of the payment knowledge graph include Zhang San and Li Si. Based on their attributes and their transaction relationships with financial organizations such as banks and consumer organizations such as hotels and restaurants, it can be determined that both of them are business people. Therefore, Zhang San and Li Si can be clustered and it can be determined that they correspond to a user group node, and the user group node is a business person attribute node. Similarly, entities such as organizations can also be clustered.
  • the historical transaction data includes various historical records of payments made by multiple user entities at different locations during different time periods.
  • Yi Data we can abstract the transaction scenarios with higher frequency, and thus obtain the corresponding transaction scenario nodes.
  • the transaction behavior characteristics of the same user entity are also different. Therefore, we can also summarize the corresponding transaction behavior characteristics for each transaction scenario node, and then obtain at least one rule feature node corresponding to each transaction scenario node through statistical analysis and other methods based on the transaction behavior characteristics.
  • determining at least one rule feature node corresponding to a transaction scenario node based on transaction behavior features includes: performing statistical analysis on various transaction behavior features under various transaction scenario nodes corresponding to various user group nodes to determine the statistical distributions that various transaction behavior features conform to; performing fitting processing on the statistical distributions of various transaction behavior features to obtain fitting functions of various statistical distributions; and constructing various rule feature nodes corresponding to various transaction behavior features based on the fitting functions of various statistical distributions.
  • Various transaction behavior features are divided according to the categories of transaction behaviors, and the categories of transaction behaviors include amount, time, transaction object, etc.
  • the probability density function with the highest maximum likelihood value is selected as the fitting function, so that the corresponding rule feature node can be constructed based on the fitting function.
  • the probability density function includes probability density functions of various distributions such as normal distribution, uniform distribution, and exponential distribution.
  • the fitting function is the probability density function selected from them that is closest to the actual transaction behavior characteristics.
  • the corresponding rule feature node is constructed based on the fitting function, and the rule feature node can be constructed based on the relevant parameters of the fitting function.
  • transaction behavior characteristics include transaction amounts.
  • the scipy.stats.fit method in python (a computer programming language) can be used to search for the best fitting probability density function, and construct a transaction amount rule feature node based on the parameters of the probability density function.
  • a strategy map is constructed based on the correspondence between user group nodes, transaction scenario nodes, and rule feature nodes, including: establishing connecting lines between user group nodes, transaction scenario nodes, and rule feature nodes according to the correspondence between user group nodes, transaction scenario nodes, and rule feature nodes, and the attributes of the connecting lines may include probability attributes, which represent the association probability/participation probability between two nodes connected by the corresponding connecting line, and the value of the probability attribute can be determined based on historical transaction data.
  • the transaction scene nodes corresponding to the business person attribute node include a dining scene node and an accommodation scene node.
  • the business person attribute node is connected to the dining scene node and the accommodation scene node respectively, and the probability attribute value of the connection line between the business person attribute node and the dining scene node is 40%, and the probability attribute value of the connection line between the business person attribute node and the accommodation scene node is 60%.
  • step S13 based on the payment knowledge graph and the strategy graph, transaction simulation data corresponding to the abnormal transaction means to be verified is generated.
  • the transaction simulation data includes simulation data of two dimensions, the first dimension is simulation data about entities and relationships between entities, and the second dimension is simulation data about entity transaction behaviors.
  • the transaction simulation data includes entity simulation data (corresponding to the first dimension) and behavior simulation data (corresponding to the second dimension).
  • transaction simulation data is generated only based on the payment knowledge graph, there will be a lack of simulation data on the behavioral level of each entity (it is only clear which people and organizations the subject includes, and the relationship between them, but there is no transaction behavior data of these people and organizations), and subsequent verification processing cannot be performed accurately. If transaction simulation data is generated only based on the strategy graph, the relationship between each entity cannot be retained (it is only clear which transaction behaviors the people and organizations have performed, but the relationship between these people and organizations is unknown), and subsequent verification processing cannot be performed accurately.
  • step S13 includes: determining the attributes of multiple entities to be simulated and the relationships between entities based on the abnormal transaction means to be verified; based on the attributes of multiple entities to be simulated and the relationships between entities, selecting entities that match the attributes and relationships of the entities to be simulated from the payment knowledge graph as simulation entities to obtain entity simulation data; determining the user group node corresponding to the simulation entity, and generating behavior simulation data based on the user group node in the strategy graph and the corresponding transaction scenario node and rule feature node.
  • the abnormal transaction means to be verified are the abnormal transaction means to be verified. Only when it is clear which abnormal transaction means to be verified can it be clear which entities need to be verified. Simulate (i.e., the entity to be simulated), and determine the attributes of the entity to be simulated and the relationship between the entities.
  • transaction simulation data may be generated based on a preset configuration file, wherein the configuration file includes the number of individual entities in the simulation entity, the proportion of each population node, the number of business organization entities and their proportion, time interval (indicating the time interval for generating simulation data), time offset, generation quantity, etc.
  • the time offset is set because when generating transaction simulation data, there may be some difference between individual times and the actual transaction time distribution.
  • sampling based on the time offset method can correct the transaction time and improve the accuracy of the simulation data; the generation quantity is used to configure the number of transaction simulation data generated each time, which can be configured in a variety of ways (for example, setting a fixed value, based on normal random sampling configuration, based on multi-peak normal random sampling configuration, etc.), and sampling can choose to be with replacement sampling or without replacement sampling.
  • the attributes of multiple entities to be simulated and the relationships between entities are determined; based on the attributes of the entities to be simulated and the relationships between entities, entities that match the attributes and relationships of the entities to be simulated are selected from the payment knowledge graph as simulation entities, and entity simulation data is obtained based on the payment knowledge graph.
  • entity simulation data is obtained based on the payment knowledge graph.
  • the area corresponding to the user group node in the strategy graph is searched, the corresponding transaction scenario nodes are extracted and a sampling sequence is constructed, and random sampling is performed based on the sampling sequence to obtain transaction simulation data for each scenario node.
  • the constructed sampling sequence contains 4 sampling sequences corresponding to "transaction scenario node 1" and 6 sampling sequences corresponding to "transaction scenario node 2".
  • simulation data about transaction behavior i.e., transaction simulation data
  • the rule feature node includes a time rule node, and the sampling method is uniformly distributed, with a value range of 10 to 16 o'clock, uniform sampling can be performed according to the time interval and other information required in the configuration file, thereby obtaining transaction simulation data about the time rule node.
  • rule feature nodes are similar and will not be described in detail here.
  • entity information including entity attributes, entity relationships, etc.
  • the abnormal transaction method to be verified is to obtain other people's information based on the way of social insurance agency, and use other people's information to illegally register credit cards, open loans to the outside through credit cards, and earn interest rate spreads for arbitrage.
  • the simulation entity includes multiple employees with the same social insurance payment unit, and the responsible personnel of the unit (for example, legal representatives, financial management personnel, etc.), and the corresponding attribute information includes credit cards and banks under the names of these employees and responsible personnel.
  • search for entities that match the above conditions as simulation entities and obtain corresponding entity simulation data.
  • determine the user group nodes of each simulation entity determine the user group nodes of each simulation entity, and generate behavior simulation data based on the transaction scenario nodes and rule feature nodes of the corresponding user group nodes in the strategy graph.
  • the entity simulation data includes that the legal representative of XX company is A, the financial manager is B, and the employees who pay social security include C, D and E.
  • A has a credit card from F Bank and a credit card from G Bank
  • B has a credit card from F Bank and three credit cards from G Bank
  • C has two credit cards from G Bank and a credit card from H Bank
  • D has five credit cards from G Bank and a credit card from I Bank
  • E has three credit cards from G Bank and a credit card from H Bank.
  • the user group nodes corresponding to A and B are fraudulent attribute nodes
  • the user group node corresponding to C is a business attribute node
  • the user group node corresponding to D is an unemployed person attribute node
  • the user group node corresponding to E is a self-media attribute node.
  • the behavior simulation data of A and B are generated;
  • the behavior simulation data of C is generated; similarly, the behavior simulation data of D and E can be generated.
  • the above entity simulation data and each person's behavior simulation data constitute the final transaction simulation data.
  • step S14 the abnormal transaction coping strategy corresponding to the abnormal transaction means to be verified is verified based on the transaction simulation data to obtain a strategy verification result.
  • Abnormal transaction response strategy is a strategy formulated for abnormal transaction means to be verified, used to identify, prevent and curb such abnormal transaction means.
  • Strategy verification results include abnormal The transaction response strategy can identify, detect, and suppress abnormal trading methods. Therefore, based on the strategy verification results, the effectiveness of the abnormal transaction response strategy can be determined.
  • a preset risk control system may be used to verify the abnormal transaction response strategy.
  • the risk control system is provided with a corresponding verification model.
  • the transaction simulation data is input into the risk control system, which processes the transaction simulation data and outputs the verification results.
  • the verification results may include the false recognition rate, the rejection rate, the expected profit and the expected loss, etc.
  • the risk control system includes a data processing module, a feature extraction module, and a model calculation module.
  • the model calculation module contains a variety of hybrid models (for example, boosting models).
  • the data processing module performs some preprocessing on the transaction simulation data (removing outliers, filling in blank values, etc.) to obtain the processed transaction simulation data.
  • the feature extraction module extracts the features of the processed transaction simulation data, and the features are input into the model calculation module.
  • the model therein calculates the relevant risk indicators and outputs the indicator values corresponding to each risk indicator.
  • the model in the risk control system can be a single model or a mixed model formed by a mixture of multiple models.
  • the results of multiple models can be merged through corresponding rules or decision tree methods, and a final result can be output externally.
  • the input special risk value corresponding to model one is 0.6
  • the whitelist value corresponding to model two is 0.8
  • the fraud risk value corresponding to model three is 0.4. If model two has the highest priority, it will get a "good” label. If model one has the highest priority, it will output a "special risk" label.
  • the abnormal transaction response strategy can be updated, and then the updated abnormal transaction response strategy can be verified until an abnormal transaction response strategy that meets the preset requirements is obtained; new transaction simulation data can also be regenerated, and the abnormal transaction response strategy can be re-verified based on the new transaction simulation data; the payment knowledge graph and/or strategy graph can also be expanded, and then the abnormal transaction response strategy can be re-verified based on the expanded payment knowledge graph and/or strategy graph.
  • the present disclosure does not limit this.
  • payment knowledge is constructed based on payment field data and general data.
  • the payment knowledge graph is used to intuitively and vividly represent the attributes of entities and the relationships between entities;
  • the strategy scenario information is determined, and a strategy graph is constructed based on the strategy scenario information, which abstracts the attributes, scenarios and behaviors of entities, so that the characteristics of different types of entities in different scenarios can be reflected at the behavioral level;
  • transaction simulation data corresponding to the abnormal transaction means to be verified can be generated, which is no longer dependent on or limited by the actual historical transaction data, and a sufficient amount of transaction simulation data can be obtained, providing a data basis for subsequent strategy verification;
  • the corresponding abnormal transaction response strategies can be verified in a timely and accurate manner, shortening the time between the emergence of new abnormal transaction means and the verification of abnormal transaction response strategies, so that better abnormal transaction response strategies can be quickly formulated, further ensuring the safety of users'
  • Figure 2 is a schematic diagram of a payment knowledge graph framework according to an embodiment of the present disclosure.
  • the concepts in the payment knowledge graph framework include individuals, business organizations, deposit accounts, credit card accounts, banks, third-party payment institutions, and addresses, and the relationships between the above concepts include belonging to, owning, legal person, payment, registration, location, household address, permanent address, contact address, etc.
  • the concepts involved in the credit card payment process are determined to include: “organization”, “individual”, “bank”, “account”, “non-bank institution”, etc., and these concepts are further refined and expanded to obtain corresponding instance concepts, including “individual”, “commercial organization”, “bank”, “third-party payment institution”, “credit card account”, “deposit-like account” and “address”; in addition, the relationship between the concepts shown in Figure 2 can be further determined.
  • FIG3 is a schematic diagram of a payment knowledge graph according to an embodiment of the present disclosure.
  • the user entity i.e., the "personal” entity
  • the “personal” entity includes attributes such as “name”, “gender”, “age”, “household address”, and “permanent address”, and is set with corresponding attribute values
  • the “credit card account” entity includes attributes such as “card number”, “limit”, “billing date”, and “application date”, and is set with corresponding attribute values
  • the "Bank” entity includes attributes such as “Name”, “Bank”, “Bank Category”, “Business Address”, and “Bank Code”, and are set with corresponding attribute values
  • the "Address” entity includes attributes such as “Name”, “Longitude”, “Latitude”, “Province”, “City”, “District/County”, and “Alias”, and are set with corresponding attribute values
  • the “Deposit Account” entity includes attributes such as “Account Number” and “Processing Time”, and are set with corresponding attribute values
  • the concept of "bank” in Figure 2 is instantiated based on the laws and regulations in the banking field, so that each "bank” entity is determined to contain attributes such as "name” and "bank affiliated to”;
  • the concept of "third-party payment institution” in Figure 2 is instantiated based on the laws and regulations in the third-party payment field, so that each "third-party payment institution” entity is determined to contain attributes such as "name” and "acquirer code”.
  • the instantiation process of other concepts is similar to that of "bank” and "third-party payment institution", and will not be described in detail here.
  • the corresponding strategy graph can be generated in combination with the historical transaction data.
  • the strategy graph of the embodiment of the present disclosure is described below.
  • FIG4 is a schematic diagram of a strategy map according to an embodiment of the present disclosure.
  • user group node 1 corresponds to k transaction scenario nodes, and each transaction scenario node corresponds to a number of rule feature nodes.
  • the probability that user group node 1 is in transaction scenario node 1 is participation probability 1
  • the probability that user group node 1 is in transaction scenario node 2 is participation probability 2
  • the probability that user group node 1 is in transaction scenario node k is participation probability k
  • the sum of participation probability 1 to participation probability k should theoretically be 1.
  • the n rule feature nodes corresponding to the transaction scenario node 1 are rule feature node 11, rule feature node 12, ..., rule feature node 1n, respectively, indicating that the transaction behavior characteristics of the user group node 1 when it is in the transaction scenario node 1 can be represented by the above n rule feature nodes.
  • the transaction scenario node 2 corresponds to m rule feature nodes, which are used to represent the transaction behavior characteristics of the user group node 1 when it is in the transaction scenario node 2;
  • the transaction scenario node k corresponds to t rule feature nodes, which are used to represent the transaction behavior characteristics of the user group node 1 when it is in the transaction scenario node k.
  • n, m, k, t are all integers greater than or equal to 1.
  • FIG. 4 only shows the relevant content about the user group node 1 in the strategy map.
  • the strategy map there may be other user group nodes (not shown), and the present disclosure does not limit this.
  • Figure 5 is a schematic diagram of a strategy map according to an embodiment of the present disclosure.
  • a user group node is a crowd node
  • the probability of being in a corresponding transaction scenario node is a participation probability
  • the transaction scenario node corresponds to two types of rule feature nodes, the first type is a conventional rule feature node, including a time rule node, an amount rule node, and a transaction object rule node, and the second type belongs to a prerequisite rule feature node, indicating that certain prerequisite conditions must be met, including a prerequisite rule node.
  • Fig. 6 is a schematic diagram of a strategy map according to an embodiment of the present disclosure.
  • the user group node includes a business travel group node and a fraud type 1 group node, wherein the transaction scenario node corresponding to the business travel group node includes an online shopping scenario node and an accommodation scenario node, and the probability of the business travel group node being in the online shopping scenario node is 40%, and the probability of being in the accommodation scenario node is 60%, and the transaction scenario node corresponding to the fraud type 1 group node includes an accommodation scenario node and a fraud scenario node, and the probability of the fraud type 1 group node being in the accommodation scenario node is 30%, and the probability of being in the fraud scenario node is 70%.
  • the accommodation scene node corresponds to a premise rule node and three conventional rule feature nodes, namely the time rule node, the amount rule node and the transaction object rule node.
  • the content of the premise rule node is that there is no accommodation consumption at present, the time rule node satisfies the normal distribution (18,2) and the value is (0,24), the amount rule node satisfies the normal distribution (50,10) and the value is (200,100), and the content of the transaction object rule node includes address and type, where the address value is the address of the day, and the type value includes homestay and hotel.
  • ⁇ represents the mathematical expectation
  • ⁇ 2 represents the variance
  • the corresponding value (x1,x2) indicates that the value range based on the normal distribution is greater than x1 and less than x2.
  • the time rule node satisfies the normal distribution (18,2), which means that the value of time in the time rule node satisfies the normal distribution with an expectation of 18 and a variance of 2.
  • the value (0,24) indicates that the value range of time is from time 0 to time 24.
  • the payment knowledge graph and/or strategy graph may be expanded to obtain an expanded payment knowledge graph and/or strategy graph.
  • the expanded payment knowledge graph effectively expands the scope of representation of entities, attributes and relationships.
  • the expanded strategy graph adds new strategy scenario information or expands the original strategy scenario information, thereby being able to more comprehensively and vividly represent the behavioral characteristics of various entities.
  • the expanded payment knowledge graph and/or strategy graph can also be used to generate corresponding transaction simulation data. Since the graph is expanded, the types of generated transaction simulation data are more diverse and rich, and are closer to real transaction data, thereby obtaining more accurate strategy verification results and facilitating the formulation and updating of abnormal transaction response strategies.
  • Fig. 7 is a flow chart of a method for verifying an abnormal transaction coping strategy according to an embodiment of the present disclosure.
  • the method for verifying an abnormal transaction coping strategy includes steps S71 to S75.
  • step S71 a payment knowledge graph is constructed based on payment field data and general data, where general data is data that is common in multiple fields.
  • the payment knowledge graph is used to represent entities in the payment field, the attributes of entities, and the relationships between entities. Entities include user entities and payment-related institution entities.
  • step S72 the strategy scenario information is determined according to the payment knowledge graph and the historical transaction data, and a strategy graph is constructed based on the strategy scenario information.
  • the strategy graph represents the payment behaviors of multiple user groups in the payment field in multiple transaction scenarios.
  • the multiple user groups are determined based on the categories of the groups to which each user entity in the payment knowledge graph belongs.
  • Steps S71 and S72 are the same as steps S 11 and S 12 described with reference to FIG1 and will not be described in detail here.
  • step S73 based on the knowledge base, the payment knowledge graph and/or the strategy graph is expanded to obtain an expanded payment knowledge graph and/or an expanded strategy graph.
  • a knowledge base is a collection of knowledge, and the knowledge therein is organized into a structured form that is easy to use based on its application domain characteristics, background characteristics, usage characteristics, attribute characteristics, etc.
  • the knowledge base is a database built based on an expert system, which includes various rules, strategies, and mutual relationships designed and formulated by experts.
  • the payment knowledge graph is expanded based on the knowledge base to obtain an expanded payment knowledge graph, including: determining a candidate payment knowledge subgraph based on the knowledge base and the payment knowledge graph; formulating an expansion strategy based on the knowledge base, and expanding at least one of the topological structure, entity attributes and entity relationships of the candidate payment knowledge subgraph based on the expansion strategy to obtain a payment knowledge expansion subgraph; and integrating the payment knowledge expansion subgraph into the payment knowledge graph to obtain an expanded payment knowledge graph.
  • the candidate payment knowledge subgraph is the basis for graph expansion. Only after the candidate payment knowledge subgraph is determined can the corresponding expansion operation be performed.
  • the payment knowledge graph includes multiple payment knowledge subgraphs.
  • the payment knowledge graph may be divided into multiple payment knowledge subgraphs according to the structure of the desired candidate payment knowledge subgraph (e.g., which entities it has).
  • each payment knowledge subgraph may include an "address" entity and at least one user entity having a relationship with the "address" entity.
  • the candidate payment knowledge subgraph is determined, including: based on the knowledge base, a payment knowledge subgraph query condition is constructed; according to the payment knowledge subgraph query condition, a query is performed in the multiple payment knowledge subgraphs included in the payment knowledge graph to obtain multiple matching payment knowledge subgraphs; according to a preset merging condition, the matching payment knowledge subgraphs that meet the merging condition are merged to obtain a merged payment knowledge subgraph; according to a preset subgraph cropping scheme, the merged payment knowledge subgraph is cropped to obtain a candidate payment knowledge subgraph.
  • the address is one of the important relationships of the associated entities
  • the corresponding payment knowledge subgraph query conditions can be set based on the address, and finally the candidate payment knowledge subgraph about the address can be obtained.
  • the payment knowledge subgraph query condition is that the similarity between the addresses represented by the "address" entities of at least two payment knowledge subgraphs is greater than the similarity threshold, so as to query the payment knowledge subgraphs whose similarity between the addresses in the multiple payment knowledge subgraphs included in the payment knowledge graph is greater than the similarity threshold as matching payment knowledge subgraphs.
  • the distance between the addresses represented by the "address" entities of the matching payment knowledge subgraphs is less than the preset distance threshold.
  • Multiple matching payment knowledge subgraphs refer to subgraphs obtained by querying multiple payment knowledge subgraphs included in the payment knowledge graph according to the payment knowledge subgraph query conditions.
  • the merged payment knowledge graph is obtained by merging the matching payment knowledge subgraphs whose distances between addresses are less than the preset distance threshold.
  • the subgraph cropping scheme is to crop the merged payment knowledge subgraph based on the selected cropping address.
  • a candidate payment knowledge subgraph is determined, including: querying in multiple payment knowledge subgraphs included in the payment knowledge graph according to the payment knowledge subgraph query condition, and obtaining multiple payment knowledge subgraphs whose address similarity is greater than a similarity threshold as matching payment knowledge subgraphs; merging matching payment knowledge subgraphs whose address distances are less than a preset distance threshold to obtain a merged payment knowledge subgraph; selecting at least one address from the addresses represented by the "address" entity included in the merged payment knowledge subgraph as a cropped address; cropping the merged payment knowledge subgraph based on the cropped address to obtain a candidate payment knowledge subgraph, wherein there is at least one cropped address in the addresses of the candidate payment knowledge subgraph.
  • Fig. 8 is a schematic diagram of subgraph merging according to an embodiment of the present disclosure.
  • matching payment knowledge subgraph 1 and matching payment knowledge subgraph 2 are two matching payment knowledge subgraphs obtained based on the payment knowledge subgraph query condition query.
  • the household addresses of the "personal 1" entity, the “personal 2” entity, and the “personal 3” entity all point to the "address 1" entity
  • the household addresses of the "personal 4" entity, the "personal 5" entity, and the “personal 6” entity all point to the "address 2" entity
  • the contact address of the "personal 4" entity points to the "address 1" entity. Since the distance between address 1 and address 2 is less than the preset distance threshold, the matching payment knowledge subgraph 1 and the matching payment knowledge subgraph 2 can be merged to obtain the corresponding merged payment knowledge subgraph.
  • FIG9 is a schematic diagram of the process of obtaining candidate payment knowledge subgraphs according to an embodiment of the present disclosure.
  • a query is performed in the payment knowledge graph based on the preset payment knowledge subgraph query conditions to obtain multiple matching payment knowledge subgraphs (e.g., matching payment knowledge subgraph 11, matching payment knowledge subgraph 12, ..., matching payment knowledge subgraph 17, etc.).
  • Matching payment knowledge subgraph 11 includes an "address a1" entity
  • matching payment knowledge subgraph 12 includes an “address b1” entity
  • matching payment knowledge subgraph 13 includes an “address b2" entity
  • matching payment knowledge subgraph 14 includes an “address b3” entity
  • matching payment knowledge subgraph 15 includes an "address b4" entity
  • matching payment knowledge subgraph 16 includes an "address b5" entity
  • matching payment knowledge subgraph 17 includes an "address b6” entity
  • matching payment knowledge subgraph 18 includes an "address b7” entity
  • matching payment knowledge subgraph 19 includes an "address b8” entity
  • matching payment knowledge subgraph 11 includes an "address a1” entity
  • matching payment knowledge subgraph 12 includes an “address b1” entity
  • matching payment knowledge subgraph 13 includes an “address b2” entity
  • matching payment knowledge subgraph 14 includes an “address b3” entity
  • matching payment knowledge subgraph 15 includes an
  • the distances between address a1, address a2, address a3, and address a4 are relatively close, less than the preset distance threshold, and the distances between address b1, address b2, and address b3 are relatively close, less than the preset distance threshold.
  • the matching payment knowledge subgraphs whose distances between addresses are less than the preset distance threshold can be merged, so that matching payment knowledge subgraphs 11, 14, 15, and 16 are merged into a merged payment knowledge subgraph 21, and matching payment knowledge subgraphs 12, 13, and 17 are merged into a merged payment knowledge subgraph 22.
  • the candidate payment knowledge subgraph 31 includes the cropping address a1
  • the candidate payment knowledge subgraph 32 includes the cropping address a3
  • the candidate payment knowledge subgraph 33 includes the cropping address b2
  • the candidate payment knowledge subgraph 34 includes the cropping address a4
  • the candidate payment knowledge subgraph 35 includes the cropping address b3.
  • the portion including address a1 and address a2 or the portion including address a3 and address a4 in the merged payment knowledge subgraph 21 the portion including address b1 and address b2 or the portion including address b2 and address b3 in the merged payment knowledge subgraph 22, etc. can also be cropped as candidate payment knowledge subgraphs.
  • each payment knowledge subgraph included in the payment knowledge graph may include a "bank” entity or a "credit card account” entity and other entities that have relationships with them.
  • the obtained candidate payment knowledge subgraph may be displayed to the expert for confirmation and modification.
  • the modification of the candidate payment knowledge subgraph by the expert includes but is not limited to: adding new entities (the new entities can be initialized), adding new relationships, deleting entities, deleting relationships, modifying attributes (for example, changing the name attribute value of the person entity by randomly sampling from the name library) or deleting, etc.
  • the strategy graph is expanded to obtain an expanded strategy graph, including: based on the knowledge base, determining new nodes, the new nodes including at least one of user group nodes, new transaction scenario nodes and new rule feature nodes; based on the new nodes, constructing a strategy extension subgraph; integrating the strategy extension subgraph into the strategy graph to obtain an expanded strategy graph.
  • Figure 10 is a schematic diagram of a strategy map according to an embodiment of the present disclosure.
  • a new user group node is determined, that is, a new fraud group node, and the new fraud group node is determined to correspond to a new fraud scenario node 1 and a new fraud scenario node 2, and the probability that the new fraud group node is in the new fraud scenario node 1 is 80%, and the probability that the new fraud group node is in the new fraud scenario node 2 is 20%, and each new fraud scenario node corresponds to a number of rule feature nodes.
  • the new fraud scenario node 1 corresponds to three rule feature nodes, namely the time rule node, the amount rule node and the transaction object rule node.
  • the time rule node satisfies the uniform distribution and takes the value of (10,16)
  • the amount rule node satisfies the normal distribution (0.8,0.1) and takes the value of (0.2,0.9)
  • the transaction object rule node includes the address and type, where the address value is XX District, XX City, and the type value includes homestay and hotel.
  • the new fraud scenario node 2 also corresponds to the corresponding rule feature node (not shown in the figure).
  • the expansion of the payment knowledge graph and strategy graph can be done by timely expanding the payment knowledge graph and strategy graph based on the new fraud method after it emerges; or, when experts anticipate possible fraud methods or formulate new abnormal transaction response strategies, they can expand the existing payment knowledge graph and/or strategy graph accordingly, generate transaction simulation data based on the expanded payment knowledge graph and/or strategy graph, and perform verification of abnormal transaction response strategies.
  • step S74 based on the payment knowledge graph and the strategy graph, transaction simulation data corresponding to the abnormal transaction means to be verified is generated.
  • transaction simulation data corresponding to the abnormal transaction means to be verified can be generated based on the expanded payment knowledge graph and the original strategy graph; when only the strategy graph is expanded, transaction simulation data corresponding to the abnormal transaction means to be verified can be generated based on the original payment knowledge graph and the expanded strategy graph; when both the payment knowledge graph and the strategy graph are expanded, transaction simulation data corresponding to the abnormal transaction means to be verified can be generated based on the expanded payment knowledge graph and the expanded strategy graph.
  • the rule feature node when generating the transaction simulation data, it is also necessary to screen the rule feature node under the corresponding transaction scenario node based on the premise rule node. Exemplarily, first determine whether the premise rule node exists. If it does, obtain the historical transaction record of the corresponding entity, and make a judgment based on the premise rule node to determine whether the historical transaction record conforms to the content of the premise rule node. If it does not conform, re-determine the new entity and carry out a new judgment operation; if it conforms, generate the corresponding transaction simulation data according to each rule feature node.
  • step S75 based on the transaction simulation data, the abnormal transaction response strategy corresponding to the abnormal transaction means to be verified is verified to obtain a strategy verification result.
  • the payment knowledge graph and/or the strategy graph can also be expanded, which can increase the representation scope of entities and relationships, enrich various transaction scenarios and transaction behaviors, and enable the payment knowledge graph and the strategy graph to have certain learning and updating capabilities, so as to obtain more comprehensive and closer to the actual transaction simulation data based on the expanded payment knowledge graph and/or the strategy graph, so as to be suitable for pre-simulating abnormal transaction means that may occur but have not actually occurred, and formulating appropriate abnormal transaction response strategies as early as possible, or promptly verifying the abnormal transaction response strategies that have just been formulated, so as to formulate effective abnormal transaction response strategies, thereby ensuring asset security.
  • FIG11 is a block diagram of a verification device for abnormal transaction response strategy according to an embodiment of the present disclosure.
  • the verification device 1100 for abnormal transaction response strategy includes a construction module 1101 , a generation module 1102 and a verification module 1103 .
  • Construction module 1101 is used to construct a payment knowledge graph based on payment field data and general data.
  • General data is data that is universal in multiple fields.
  • the payment knowledge graph is used to represent entities in the payment field, the attributes of entities, and the relationships between entities. Entities include user entities and payment-related institution entities.
  • Construction module 1101 is also used to determine strategy scenario information based on the payment knowledge graph and historical transaction data, and to construct a strategy graph based on the strategy scenario information.
  • the strategy graph represents the payment behaviors of multiple user groups in the payment field in multiple transaction scenarios.
  • the multiple user groups are determined based on the categories of the groups to which each user entity in the payment knowledge graph belongs.
  • the generation module 1102 is used to generate transaction simulation data corresponding to the abnormal transaction means to be verified based on the payment knowledge graph and the strategy graph.
  • the verification module 1103 is used to verify the abnormal transaction response strategy corresponding to the abnormal transaction means to be verified based on the transaction simulation data, and obtain a strategy verification result.
  • the strategy scenario information includes at least a user group node, a transaction scenario node, and a rule feature node.
  • the construction module includes a clustering submodule, a first determination submodule, a second determination submodule, and a strategy map establishment submodule.
  • the clustering submodule is used to cluster each user entity in the payment knowledge graph and determine at least one user group node; the first determination submodule is used to determine the transaction scenario node corresponding to each user group node and the transaction behavior characteristics under each transaction scenario node based on historical transaction data; the second determination submodule is used to determine at least one rule feature node corresponding to the transaction scenario node based on the transaction behavior characteristics; the strategy map establishment submodule is used to establish a strategy map based on the correspondence between the user group node, the transaction scenario node, and the rule feature node.
  • the second determination submodule includes a statistical unit, a fitting unit, and a construction unit.
  • the statistical unit is used to perform statistical analysis on various types of transaction behavior characteristics under various transaction scenario nodes corresponding to various user group nodes, and determine the statistical distribution that various types of transaction behavior characteristics conform to;
  • the fitting unit is used to perform fitting processing on the statistical distribution of various types of transaction behavior characteristics, and obtain the fitting function of each statistical distribution;
  • the construction unit is used to construct various rule feature nodes corresponding to various types of transaction behavior characteristics based on the fitting function of each statistical distribution.
  • the transaction simulation data includes entity simulation data and Behavior simulation data.
  • the generation module includes a third determination submodule, a first simulation submodule and a second simulation submodule.
  • the third determination submodule is used to determine the attributes of multiple entities to be simulated and the relationships between entities based on the abnormal transaction means to be verified;
  • the first simulation submodule is used to select entities that match the attributes and relationships of the entities to be simulated from the payment knowledge graph as simulation entities based on the attributes of the multiple entities to be simulated and the relationships between entities, and obtain entity simulation data;
  • the second simulation submodule is used to determine the user group nodes corresponding to the attributes of the simulation entities, and generate behavior simulation data based on the user group nodes in the strategy graph and the corresponding transaction scenario nodes and rule feature nodes.
  • the verification device 1100 for abnormal transaction response strategies also includes an expansion module, which is used to expand the payment knowledge graph and/or the strategy graph based on the knowledge base to obtain the expanded payment knowledge graph and/or the expanded strategy graph.
  • the expansion module includes a first expansion submodule and a second expansion submodule.
  • the first expansion submodule is used to expand the payment knowledge graph to obtain an expanded payment knowledge graph
  • the second expansion submodule is used to expand the strategy graph to obtain an expanded strategy graph.
  • the first extension submodule includes a first determination unit, a first extension unit, and a first fusion unit.
  • the first determination unit is used to determine a candidate payment knowledge subgraph based on the knowledge base and the payment knowledge graph; the first extension unit is used to formulate an extension strategy based on the knowledge base, and based on the extension strategy, expand at least one of the topological structure, entity attributes, and entity relationships of the candidate payment knowledge subgraph to obtain a payment knowledge extension subgraph; the first fusion unit is used to fuse the payment knowledge extension subgraph into the payment knowledge graph to obtain an extended payment knowledge graph.
  • the first determination unit includes a condition construction subunit, a query subunit, a merging subunit, and a cutting subunit.
  • the condition construction subunit is used to construct a payment knowledge subgraph query condition based on the knowledge base;
  • the query subunit is used to query the payment knowledge graph according to the payment knowledge subgraph query condition to obtain multiple matching payment knowledge subgraphs;
  • the merging subunit is used to merge the matching payment knowledge subgraphs that meet the merging condition according to the preset merging condition to obtain a merged payment knowledge subgraph;
  • the cutting subunit is used to cut the merged payment knowledge subgraph according to the preset subgraph cutting scheme to obtain a candidate payment knowledge subgraph.
  • the payment knowledge subgraph query condition is that the similarity between the addresses represented by the "address" entities of at least two payment knowledge subgraphs is greater than the similarity threshold, so as to query multiple payment knowledge subgraphs whose similarity between addresses in the multiple payment knowledge subgraphs included in the payment knowledge graph is greater than the similarity threshold as matching payment knowledge subgraphs.
  • the merging condition is that the distance between the addresses represented by the "address" entities of at least two matching payment knowledge subgraphs is less than the preset distance threshold.
  • the query subunit is used to query the multiple payment knowledge subgraphs included in the payment knowledge graph according to the payment knowledge subgraph query condition, and obtain multiple payment knowledge subgraphs whose address similarity is greater than the similarity threshold as matching payment knowledge subgraphs.
  • the merging subunit is used to merge the matching payment knowledge subgraphs whose distance between addresses is less than the preset distance threshold to obtain a merged payment knowledge subgraph;
  • the cropping subunit is used to select at least one address from the addresses included in the merged payment knowledge subgraph as a cropped address, and crop the merged payment knowledge subgraph based on the cropped address to obtain a candidate payment knowledge subgraph, wherein there is at least one cropped address in the address of the candidate payment knowledge subgraph.
  • the second extension submodule includes a second determination unit, a second extension unit, and a second fusion unit.
  • the second determination unit is used to determine at least one of a newly added user group node, a newly added transaction scenario node, and a newly added rule feature node based on the knowledge base;
  • the second extension unit is used to construct a strategy extension subgraph based on at least one of the newly added group node, the newly added transaction scenario node, and the newly added rule feature node;
  • the second fusion unit is used to fuse the strategy extension subgraph into the strategy map to obtain an extended strategy map.
  • the construction module constructs a payment knowledge graph based on payment field data and general data to intuitively and vividly represent entity attributes and the relationship between entities; secondly, the construction module determines the strategy scenario information based on the payment knowledge graph and historical transaction data, and constructs a strategy graph based on the strategy scenario information, abstracting the attributes, scenarios and behaviors of the entities, so that the characteristics of different types of entities in different scenarios can be reflected at the behavioral level; then, the generation module can generate transaction simulation data corresponding to the abnormal transaction means to be verified based on the payment knowledge graph and the strategy graph, which is no longer dependent on or limited by the actual historical transaction data, and can obtain a sufficient amount of transaction simulation data, providing a data basis for subsequent strategy verification; finally, the verification module can verify the corresponding abnormal transaction response strategy in a timely and accurate manner based on the transaction simulation data, shortening the time for new abnormalities.
  • the time between the occurrence of the transaction method and the verification of the abnormal transaction response strategy can quickly formulate a better abnormal transaction response strategy, further ensuring
  • the present disclosure also provides electronic devices and computer-readable storage media, which can be used to implement the verification method of the abnormal transaction response strategy according to the embodiments of the present disclosure.
  • the corresponding technical solutions and descriptions are referred to the corresponding records in the method part and will not be repeated here.
  • FIG. 12 is a block diagram of an electronic device according to an embodiment of the present disclosure.
  • the present disclosure provides an electronic device, which includes: at least one processor 1201; at least one memory 1202, and one or more I/O interfaces 1203, which are connected between the processor 1201 and the memory 1202.
  • the memory 1202 stores one or more computer programs that can be executed by the at least one processor 1201, and when the one or more computer programs are executed by the at least one processor 1201, the at least one processor 1201 can execute the above-mentioned verification method of the abnormal transaction response strategy.
  • the present disclosure also provides a computer-readable storage medium on which a computer program is stored, and when the computer program is executed by a processor/processing core, the computer-readable storage medium implements the above-mentioned verification method of the abnormal transaction response strategy.
  • the computer-readable storage medium can be a volatile or non-volatile computer-readable storage medium.
  • the present disclosure also provides a computer program, including a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code.
  • a computer program including a computer-readable code, or a non-volatile computer-readable storage medium carrying the computer-readable code.
  • computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable program instructions, data structures, program modules or other data).
  • Computer storage media include, but are not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technology, portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer.
  • communication media typically contain computer-readable program instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and may include any information delivery medium.
  • the computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing/processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and/or a wireless network.
  • the network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and/or edge servers.
  • the network adapter card or network interface in each computing/processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in the computer-readable storage medium in each computing/processing device.
  • the computer program instructions for performing the operations of the present disclosure may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and conventional procedural programming languages such as "C" or similar programming languages.
  • the computer readable program instructions may be executed entirely on a user's computer, partially on a user's computer, as a stand-alone software package, or partially on a computer.
  • the user computer may be partially executed on a remote computer, or may be executed entirely on a remote computer or server.
  • the remote computer may be connected to the user computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).
  • an electronic circuit such as a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may be customized by utilizing state information of a computer-readable program instruction, and the electronic circuit may execute a computer-readable program instruction, thereby implementing various aspects of the present disclosure.
  • the computer program described herein may be implemented in hardware, software, or a combination thereof.
  • the computer program is embodied as a computer storage medium, and in another optional embodiment, the computer program is embodied as a software product, such as a software development kit (SDK), etc.
  • SDK software development kit
  • These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, thereby producing a machine, so that when these instructions are executed by the processor of the computer or other programmable data processing device, a device that implements the functions/actions specified in one or more boxes in the flowchart and/or block diagram is generated.
  • These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and/or other equipment to work in a specific manner, so that the computer-readable medium storing the instructions includes a manufactured product, which includes instructions for implementing various aspects of the functions/actions specified in one or more boxes in the flowchart and/or block diagram.
  • Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device so that a series of operating steps are performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to implement the functions/actions specified in one or more boxes in the flowchart and/or block diagram.
  • each square box in the flow chart or block diagram can represent a part of a module, program segment or instruction, and the part of the module, program segment or instruction contains one or more executable instructions for realizing the specified logical function.
  • the function marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two continuous square boxes can actually be executed substantially in parallel, and they can sometimes be executed in reverse order, depending on the functions involved.
  • each square box in the block diagram and/or flow chart, and the combination of the square boxes in the block diagram and/or flow chart can be implemented with a dedicated hardware-based system that performs the specified function or action, or can be implemented with a combination of special hardware and computer instructions.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • General Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • General Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Artificial Intelligence (AREA)
  • Evolutionary Computation (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

本公开提供了一种异常交易应对策略的验证方法和验证装置。该验证方法包括：根据支付领域数据和通用数据，构建支付知识图谱；根据支付知识图谱和历史交易数据确定策略场景信息，并基于策略场景信息构建策略图谱；基于支付知识图谱和策略图谱，生成与待验证异常交易手段对应的交易仿真数据；基于交易仿真数据，对与待验证异常交易手段对应的异常交易应对策略进行验证，获得策略验证结果。

Description

异常交易应对策略的验证方法和验证装置
相关申请的交叉引用
该专利申请要求于2022年11月1日在中国国家知识产权局提交的中国专利申请202211357465.3的优先权，该中国专利申请的公开以引用方式全文并入本文中。
技术领域
本公开涉及人工智能技术领域，特别涉及一种异常交易应对策略的验证方法和验证装置。
背景技术
随着非法交易手段的不断演进，非法交易手段更加多样化、隐蔽化。在相关技术中，通常需要积累一定数量的非法交易案例之后，才能制定相应的异常交易应对策略。另外，在制定异常交易应对策略之后，通常需要基于相应的交易历史数据进行验证，在验证成功的基础上才能确定该异常交易应对策略具有良好效果。
发明内容
本公开提供一种异常交易应对策略的验证方法和验证装置。
第一方面，本公开提供了一种异常交易应对策略的验证方法，该异常交易应对策略的验证方法包括：根据支付领域数据和通用数据，构建支付知识图谱；根据支付知识图谱和历史交易数据确定策略场景信息，并基于策略场景信息构建策略图谱；基于支付知识图谱和策略图谱，生成与待验证异常交易手段对应的交易仿真数据；基于交易仿真数据对与待验证异常交易手段对应的异常交易应对策略进行验证，获得策略验证结果。
第二方面，本公开提供了一种异常交易应对策略的验证装置， 该异常交易应对策略的验证装置包括：构建模块，用于根据支付领域数据和通用数据，构建支付知识图谱，以及用于根据支付知识图谱和历史交易数据确定策略场景信息，并基于策略场景信息构建策略图谱；生成模块，用于基于支付知识图谱和所述策略图谱，生成与待验证异常交易手段对应的交易仿真数据；验证模块，用于基于交易仿真数据对与待验证异常交易手段对应的异常交易应对策略进行验证，获得策略验证结果。
第三方面，本公开提供了一种电子设备，该电子设备包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的一个或多个计算机程序，一个或多个所述计算机程序被所述至少一个处理器执行时，使至少一个处理器能够执行上述的异常交易应对策略的验证方法。
第四方面，本公开提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序在被处理器/处理核执行时实现上述的异常交易应对策略的验证方法。
应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
附图用来提供对本公开的进一步理解，并且构成说明书的一部分，与本公开的实施例一起用于解释本公开，并不构成对本公开的限制。通过参考附图对详细示例实施例进行描述，以上和其他特征和优点对本领域技术人员将变得更加显而易见，在附图中：
图1为根据本公开的实施例的异常交易应对策略的验证方法的流程图；
图2为根据本公开的实施例的支付知识图谱框架的示意图；
图3为根据本公开的实施例的支付知识图谱的示意图；
图4为根据本公开的实施例的策略图谱的示意图；
图5为根据本公开的实施例的策略图谱的示意图；
图6为根据本公开的实施例的策略图谱的示意图；
图7为根据本公开的实施例的异常交易应对策略的验证方法的流程图；
图8为根据本公开的实施例的子图合并的示意图；
图9为根据本公开的实施例的候选支付知识子图的获取过程示意图；
图10为根据本公开的实施例的扩展的策略图谱的示意图；
图11为根据本公开的实施例的异常交易应对策略的验证装置的框图；以及
图12为根据本公开的实施例的的一种电子设备的框图。
具体实施方式
为使本领域的技术人员更好地理解本公开的技术方案，以下结合附图对本公开的示范性实施例做出说明，其中包括本公开的实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
在不冲突的情况下，本公开的各实施例及实施例中的各特征可相互组合。
如本文所使用的，术语“和/或”包括一个或多个相关列举条目的任何和所有组合。
本文所使用的术语仅用于描述特定实施例，且不意欲限制本公开。如本文所使用的，单数形式“一个”和“该”也意欲包括复数形式，除非上下文另外清楚指出。还将理解的是，当本说明书中使用术语“包括”和/或“由……制成”时，指定存在所述特征、整体、步骤、操作、元件和/或组件，但不排除存在或添加一个或多个其它特征、整体、步骤、操作、元件、组件和/或其群组。“连接”或者“相连”等类似的词语并非限定于物理的或者机械的连接，而是可以包括电性的连接，不管是直接的还是间接的。
除非另外限定，否则本文所用的所有术语(包括技术和科学术语)的含义与本领域普通技术人员通常理解的含义相同。还将理解，诸如那些在常用字典中限定的那些术语应当被解释为具有与其在相关技术以及本公开的背景下的含义一致的含义，且将不解释为具有理想化或过度形式上的含义，除非本文明确如此限定。
随着信用卡规模的日益增长，利用信用卡进行非法交易(例如，套现)的违法行为也越来越多，非法交易的手段也不断升级，隐蔽性更强，且呈现出团体化、产业化的发展趋势，对金融安全带来巨大风险。在应对非法交易手段上，传统方法需要积累一定数量的案例之后，才能制定相应的异常交易应对策略，从而导致新非法交易方法从出现到相应的异常交易应对策略的制定之间存在一定的时间差，在这段时间差内，存在较大的交易风险，可能会影响用户的资产安全。另外，在制定异常交易应对策略之后，通常需要基于相应的交易历史数据进行验证，在验证成功的基础上才能确定该异常交易应对策略具有良好效果。但是，在发现新非法交易方法之初，相应的交易历史数据较少，可能无法保障验证结果的准确性，从而也无法准确评估异常交易应对策略的效果。
本公开提供的异常交易应对策略的验证方法，能够不依赖真实的异常交易手段的交易数据，及时地生成交易仿真数据，从而便于准确及时地对相应的异常交易应对策略进行验证，缩短了新的异常交易手段出现到验证异常交易应对策略之间的时间，能够快速地制定出效果较好的异常交易应对策略，进一步保障了用户的资金安全。
根据本公开的实施例的异常交易应对策略的验证方法可以由终端设备或服务器等电子设备执行。终端设备可以为用户设备(User Equipment，UE)、移动设备、用户终端、终端、蜂窝电话、无绳电话、个人数字助理(Personal Digital Assistant，PDA)、手持设备、计算设备、车载设备、可穿戴设备等。该验证方法可以通过处理器调用存储器中存储的计算机可读程序指令的方式来实现。服务器可以是独立的物理服务器、由多个服务器组成的服务器集群或者能够进行云计算的云服务器。
图1为根据本公开的实施例的异常交易应对策略的验证方法的流程图。参照图1，该异常交易应对策略的验证方法包括步骤S 11至S14。
在步骤S11中，根据支付领域数据和通用数据，构建支付知识图谱，通用数据为在多个领域具有通用性的数据，支付知识图谱用于表征支付领域的实体、实体的属性以及实体之间的关系，实体包括用户实体和支付相关机构实体。
在一些可选的实现方式中，实体也可包括其它实体，例如，地址实体等。
支付领域数据是关于支付领域的专业性数据，通用数据则为各个领域均可能涉及到的具有通用性的数据。
在一些可选的实现方式中，支付领域数据包括支付行业中的行业规定数据、相关资料以及支付业务数据，其中，相关资料主要包括支付领域的法律法规中的支付相关机构实体(例如，银行、第三方支付机构)的公开资料，支付业务数据包括银行等支付领域相关组织的业务系统中的数据(例如，银行的信用卡支付系统中的数据)。
在一些可选的实现方式中，通用数据包括地理信息数据、时间信息数据等。
需要说明的是，以上对于支付领域数据和通用数据仅是举例说明，本公开对此不作限制。
知识图谱(Knowledge Graph)是将知识域进行可视化处理，从而获得的相应的知识领域映射图。在实际应用中，知识图谱可以用来描述各种实体和概念，以及他们之间的关系，可以视作一种语义网络。在一些可选的实现方式中，知识图谱的基本组成单位是“实体—关系—实体”三元组，以及实体及其相关属性—值对，实体之间通过关系相互连接，构成网状的知识结构。
支付知识图谱是支付领域的知识图谱，其用于表示支付领域的各类实体、实体的属性以及实体之间的关系。换言之，在支付知识图谱中，基本组成单位“实体—关系—实体”三元组中，实体大多应属于支付领域的实体(少部分实体为各个领域都通用的实体)，且在确 定关系时，更注重于确定实体之间在支付领域的关联关系(例如，消费时间、支付金额等关系)。
在构建支付知识图谱时，可以采用自顶向下(data schema)的构建方法，也可以采用自底向上(bottom-up)的构建方法。采用自顶向下的构建方法时，可以先为支付知识图谱设计数据模式(data schema)，再依据该数据模式有针对性的进行数据抽取，并将抽取的数据构建成图谱形式，从而获得支付知识图谱。采用自底向上的构建方法时，通常先进行数据(包括支付领域数据和涉及到的通用数据)的收集和整理，再根据数据内容总结、归纳响应特点，提炼框架，逐步形成最终的数据模式，从而获得相应的支付知识图谱。
在一些可选的实现方式中，在步骤S 11中，根据支付领域数据和通用数据，构建支付知识图谱，包括：首先，从支付行业的行业规定数据中，归纳总结出支付流程中各个基本概念和概念之间的关系，并基于概念和概念之间的关系建立支付知识图谱框架；其次，根据支付行业的相关资料，将上述概念中的一部分概念实例化为实体，确认每个实体的属性和相应的实体间的关系；再次，根据支付业务数据(如，支付行业的业务系统数据)进行抽象分析，将上述概念的中的另一部分概念实例化为实体，确认每个实体的属性和相应的实体间的关系；然后，基于通用数据，将上述概念中的一部分概念实例化为实体，确认每个实体的属性和相应的实体间的关系，获得包括实体和实体之间的关系的支付知识图谱；最后，根据所述支付知识图谱框架、实体、实体间的关系构建所述支付知识图谱。
综上，支付知识图谱是结构化的支付领域语义知识库，其通过将数据粒度从文件(Document)级别降到数据(Data)级别，从而聚合了大量知识，可以迅速描述支付领域中的实体及其相互关系，实现支付知识的快速响应和推理。支付知识图谱中涉及的实体可以包括用户实体和支付相关机构实体，其中用户实体是指发生支付交易行为的个人，支付相关机构实体是指与资源有关的组织或者单位，比如银行、商店等等。
在步骤S12中，根据支付知识图谱和历史交易数据确定策略场 景信息，并基于策略场景信息构建策略图谱。
历史交易数据是已经实际产生的支付领域的交易数据，其可以从支付领域的业务系统中获得，也可以采用其他方式获得，本公开实施例对此不作限制。
如前所述，支付知识图谱主要从实体及其关系层面上反映支付领域的信息，其包括各个人物、组织等之间的关联关系，但是缺乏行为层面的知识或信息。因此，在支付知识图谱和历史交易数据的基础上，对实体的属性进行归纳总结，对交易场景进行统计抽象，并分析相应的交易行为，从而获得策略场景信息，并利用策略场景信息构建策略图谱。换言之，策略图谱倾向于从交易行为层面上反映支付领域的知识。
在一些可选的实现方式中，策略图谱表征支付领域中多个用户群体在多个交易场景下的支付行为，多个用户群体是基于支付知识图谱中的各个用户实体所属的群体的类别确定的。
在一些可选的实现方式中，策略场景信息至少包括用户群体节点、交易场景节点和规则特征节点。与之相应的，步骤S12包括：对支付知识图谱中的各个用户实体进行聚类处理，确定至少一个用户群体节点；根据历史交易数据，确定各个用户群体节点所对应的交易场景节点，以及各个交易场景节点下的交易行为特征；基于各个交易场景节点下的交易行为特征确定与交易场景节点对应的至少一个规则特征节点。这些用户群体节点、交易场景节点、规则特征节点的对应关系构成对应的策略图谱。
聚类处理是将相似度较高的实体聚合成一个类别。例如，支付知识图谱的用户实体包括张三和李四，根据两者的属性以及与银行等金融组织、酒店餐厅等消费组织的交易关系，可以确定两者都属于商务人士，从而可以将张三和李四进行聚类，确定两者对应一个用户群体节点，且该用户群体节点为商务人士属性节点。类似的，可以对组织等实体也进行聚类处理。
在一些可选的实现方式中，历史交易数据中包括多个用户实体在各个时段内，于不同地点进行支付的各项历史记录。通过对历史交 易数据进行统计分析，可以抽象出出现频率较高的交易场景，从而获得对应的交易场景节点。在不同的交易场景下，同一用户实体的交易行为特征也相应不同，因此，还可以针对各个交易场景节点，总结归纳对应的交易行为特征，进而根据交易行为特征，通过统计分析等方法，获得各个交易场景节点所对应的至少一个规则特征节点。
示例性地，基于交易行为特征确定与交易场景节点对应的至少一个规则特征节点，包括：对与各个用户群体节点对应的各个交易场景节点下的各类交易行为特征进行统计分析，确定各类交易行为特征符合的统计分布；对各类交易行为特征的统计分布进行拟合处理，获得各个统计分布的拟合函数；基于各个统计分布的拟合函数，构建与各类交易行为特征对应的各个规则特征节点。各类交易行为特征是根据交易行为的类别进行划分的，交易行为的类别包括金额、时间、交易对象等。
例如，统计某一类交易行为特征的特征值分布情况，并利用多个概率密度函数去拟合这种分布，选择最大似然值最高的概率密度函数作为拟合函数，从而可以基于该拟合函数构建相应的规则特征节点。概率密度函数包括正态分布、均匀分布、指数分布等各类分布的概率密度函数，拟合函数是从中选取的最接近实际交易行为特征的概率密度函数，基于拟合函数构建相应的规则特征节点，可以是基于该拟合函数的相关参数构建规则特征节点。
例如，交易行为特征包括交易金额，针对交易金额，可以使用python(一种计算机编程语言)中的scipy.stats.fit方法去搜索拟合最佳的概率密度函数，并基于该概率密度函数的参数构造交易金额规则特征节点。
在一些可选的实现方式中，基于用户群体节点、交易场景节点、规则特征节点的对应关系，构建策略图谱，包括：根据用户群体节点、交易场景节点、规则特征节点的对应关系，建立用户群体节点、交易场景节点、规则特征节点之间的连接线，该连接线的属性可以包括概率属性，概率属性表示由相应的连接线连接的两个节点之间的关联概率/参与概率，且概率属性的取值可以根据历史交易数据确定。
例如，通过对历史交易数据进行统计分析发现，商务人士处于餐饮场景的概率为40％，处于住宿场景的概率为60％。相应的，商务人士属性节点对应的交易场景节点包括餐饮场景节点和住宿场景节点，在策略图谱中，商务人士属性节点分别连接餐饮场景节点和住宿场景节点，并且，商务人士属性节点与餐饮场景节点之间的连接线的概率属性取值为40％，商务人士属性节点与住宿场景节点之间的连接线的概率属性取值为60％。
在步骤S13中，基于支付知识图谱和策略图谱，生成与待验证异常交易手段对应的交易仿真数据。
在一些可选的实现方式中，交易仿真数据包括两个维度的仿真数据，第一个维度是关于实体及实体间关系的仿真数据，第二个维度是关于实体交易行为的仿真数据。示例性地，交易仿真数据包括实体仿真数据(对应第一个维度)和行为仿真数据(对应第二个维度)。换言之，在生成交易仿真数据时，不仅要确定仿真哪些实体，还要确定仿真这些实体的哪些行为，同时还需保留这些实体之间的关系。
需要说明的是，若只基于支付知识图谱生成交易仿真数据，则缺乏各个实体在行为层面的仿真数据(只明确主体包括哪些人物和组织，以及相互之间的关系，但是没有这些人物和组织的交易行为数据)，无法准确地执行后续的验证处理，若只基于策略图谱生成交易仿真数据，则无法保留各个实体之间的关系(只明确人物和组织执行了哪些交易行为，但是并不知道这些人物和组织之间的关联关系)，同样无法准确地执行后续的验证处理。
在一些可选的实现方式中，步骤S13包括：根据待验证异常交易手段，确定待仿真的多个实体的属性和实体之间的关系；基于待仿真的多个实体的属性和实体之间的关系，从支付知识图谱中选取与待仿真的实体的属性及关系均相匹配的实体作为仿真实体，获得实体仿真数据；确定与仿真实体对应的用户群体节点，根据策略图谱中用户群体节点以及对应的交易场景节点、规则特征节点，生成行为仿真数据。待验证异常交易手段为待验证的异常交易手段，只有在明确要对何种异常交易手段进行验证的情况下，才能明确需要对哪些实体进行 仿真(即待仿真的实体)，并确定待仿真的实体的属性和实体之间的关系。
在一些可选的实现方式中，可以基于预设的配置文件生成交易仿真数据，其中，配置文件中包括仿真实体中个人实体的数量、各个人群节点的占比、商业组织实体的数量及其占比、时间间隔(表示生成仿真数据的时间间隔)、时间偏移、生成数量等。设置时间偏移是因为在生成交易仿真数据时，可能存在个别时间与实际交易时间分布有一定差别，因此，基于时间偏移的方式进行采样(包括均匀采样和多峰正态采样等)，可以对交易时间进行修正，提高仿真数据的准确性；生成数量用于配置每次生成的交易仿真数据的数量，其可采用多种配置方式(例如，设置固定值，基于正态随机采样配置、基于多峰正态随机采样配置等)，且采样可以选择有放回采样和无放回采样方式。
示例性地，根据待验证异常交易手段，确定待仿真的多个实体的属性和实体之间的关系；基于待仿真的实体的属性和实体之间的关系，从支付知识图谱中选取与待仿真的实体的属性及关系均相匹配的实体作为仿真实体，并基于支付知识图谱获得实体仿真数据。针对各个仿真实体，基于配置文件中要求的时间间隔，根据当前仿真实体所属的用户群体节点，查找策略图谱中与该用户群体节点对应的区域，提取对应的各个交易场景节点并构造采样序列，基于采样序列进行随机采样获得各个场景节点的交易仿真数据。
例如，用户群体节点A对应交易场景节点1和交易场景节点2，且对应概率分别为40％和60％，则构造的采样序列中包含4个与“交易场景节点1”对应的采样序列和6个与“交易场景节点2”对应的采样序列。针对各个采样序列，根据对应的规则特征节点生成关于交易行为的仿真数据(即交易仿真数据)。假设规则特征节点包括时间规则节点，且采样方式为均匀分布，取值范围为10点至16点，则可根据配置文件中要求的时间间隔等信息进行均匀采样，从而获得关于时间规则节点的交易仿真数据，其他规则特征节点类似，在此不再展开描述。并且，在获得所有规则特征节点的交易仿真数据之后，可以 将其与实体信息(包括实体属性、实体关系等)进行打包，形成一条消费记录，并录入预设的数据库中备用。
示例性地，待验证异常交易手段为基于代办社保的方式获取他人信息，并利用他人信息非法注册信用卡，通过信用卡对外开放借贷，以此赚取利差进行套利。在生成对应的交易仿真数据时，则仿真实体包括具有相同的社保缴纳单位的多个员工、以及该单位的负责人员(例如，法人代表、财务管理人员等)，相应的属性信息包括这些员工和负责人员名下的信用卡、归属银行等。从支付知识图谱中，查找与上述条件匹配的实体作为仿真实体，并获得相应的实体仿真数据。然后，确定各个仿真实体的用户群体节点，并根据策略图谱中，相应用户群体节点的交易场景节点、规则特征节点，生成行为仿真数据。
例如，实体仿真数据包括XX公司的法人代表为A，财务管理人员为B，缴纳社保的员工包括C、D和E，其中，A名下拥有一张F银行的信用卡以及一张G银行的信用卡，B名下拥有一张F银行的信用卡以及三张G银行的信用卡，C名下拥有两张G银行的信用卡以及一张H银行的信用卡，D名下拥有五张G银行的信用卡以及一张I银行的信用卡，E名下拥有三张G银行的信用卡以及一张H银行的信用卡。进一步地，对各个实体的属性进行分析，可以确定，A和B对应用户群体节点为欺诈型属性节点，C对应用户群体节点为商务属性节点，D对应用户群体节点为无业人员属性节点，E对应用户群体节点为自媒体属性节点。然后，根据策略图谱中欺诈性属性节点及对应的交易场景节点和规则特征节点，生成A和B的行为仿真数据；根据策略图谱中商务属性节点及对应的交易场景节点和规则特征节点，生成C的行为仿真数据；类似的，可以生成D和E的行为仿真数据。上述实体仿真数据以及各个人员的行为仿真数据即构成最终的交易仿真数据。
在步骤S14中，基于交易仿真数据对与待验证异常交易手段对应的异常交易应对策略进行验证，获得策略验证结果。
异常交易应对策略即为针对待验证异常交易手段制定的、用于识别、阻止、遏制这种异常交易手段的策略。策略验证结果包括异常 交易应对策略对异常交易手段的识别、检测、抑制效果等，因此，根据策略验证结果，可以确定异常交易应对策略的有效性。
在一些可选的实现方式中，可以利用预设的风控系统执行对异常交易应对策略的验证。风控系统中设置有相应的验证模型。
示例性地，将交易仿真数据输入风控系统中，风控系统对交易仿真数据进行处理，向外输出验证结果。验证结果可以包括误识率、拒识率、预期收益与预期损失等内容。
例如，风控系统包括数据处理模块、特征抽取模块、模型计算模块。模型计算模块内包含多种混合模型(例如，boosting(提升方法)模型)。首先，由数据处理模块对交易仿真数据进行一些预处理(去除异常值、补齐空白值等)，获得处理后的交易仿真数据，通过特征抽取模块抽取处理后的交易仿真数据的特征，并将特征输入模型计算模块中，由其中的模型计算相关风险指标，并输出各项风险指标对应的指标值。
需要说明的是，风控系统中的模型可以是单一模型，也可以是由多种模型混合形成的混合模型。对于包括多种模型的情况，可以通过相应的规则或者决策树方法等手段，将多种模型的结果进行归并，并向外输出一个最终的结果。例如，模型一对应的输入特殊风险值为0.6，模型二对应的白名单值为0.8，模型三对应的欺诈风险值为0.4，若模型二的优先级最高，则获得“良好”标签，若是模型一优先级最高，则输出“特殊风险”的标签。
还需要说明的是，在一些可选的实现方式中，在获得策略验证结果之后，若基于策略验证结果确定该异常交易应对策略的有效性不满足预设要求，则可以对该异常交易应对策略进行更新之后，再对更新后的异常交易应对策略进行验证，直到获得满足预设要求的异常交易应对策略；也可以重新生成新的交易仿真数据，并基于新的交易仿真数据对该异常交易应对策略进行重新验证；还可以对支付知识图谱和/或策略图谱进行扩展处理，再基于扩展后的支付知识图谱和/或策略图谱对该异常交易应对策略进行新的验证。本公开对此不作限制。
在本公开中，首先，根据支付领域数据和通用数据构建支付知 识图谱，以直观形象地表示实体属性以及实体之间的关系；其次，根据支付知识图谱和历史交易数据，确定策略场景信息，并基于策略场景信息构建策略图谱，对实体的属性、场景和行为进行了抽象，从而可以在行为层面反映不同类型的实体在不同场景中的特征；然后，基于支付知识图谱和策略图谱，可以生成与待验证异常交易手段对应的交易仿真数据，不再依赖或受限于实际的历史交易数据，能够获得足够数量的交易仿真数据，为后续策略验证提供了数据基础；最后，基于交易仿真数据，可以及时准确地对相应的异常交易应对策略进行验证，缩短了新异常交易手段出现到验证异常交易应对策略之间的时间，从而能够快速地制定出效果较好的异常交易应对策略，进一步保障了用户的资金安全。
下面对本公开的支付知识图谱进行展开说明。
图2为根据本公开的实施例的支付知识图谱框架的示意图。参照图2，支付知识图谱框架中的概念包括个人、商业组织、类存款账户、信用卡账户、银行、第三方支付机构和地址，且上述概念之间的关系包括属于、拥有、法人、支付、注册、所在地、户口地址、常住地址、联系地址等。
示例性地，首先根据支付领域和账户管理领域的相关法律法规，确定信用卡支付过程中的涉及的概念包含：“组织”、“个人”、“银行”、“账户”、“非银机构”等，并对这些概念进行进一步地细化与拓展，获得对应的实例的概念，包括“个人”、“商业组织”、“银行”、“第三方支付机构”、“信用卡账户”、“类存款账户”和“地址”；此外，可进一步确定图2中所示的概念之间关联关系。
在获得如图2所示的支付知识图谱框架之后，还可以基于支付行业的相关资料、支付业务数据、通用数据等将概念实例化为实体并构建实体之间的关系，从而获得更加详细的支付知识图谱。
图3为根据本公开的实施例的支付知识图谱的示意图。参照图3，用户实体(即“个人”实体)包括“姓名”“性别”“年龄”“户口地址”“常驻地址”等属性，并设置有相应的属性值；“信用卡账户”实体包括“卡号”、“额度”“账单日”“申请日”等属性，并设置 有相应的属性值；“银行”实体包括“名称”“所属银行”“所属银行类别”“营业地址”“银行代码”等属性，并设置有相应的属性值；“地址”实体包括“名称”“经度”“纬度”“省”“市”“区/县”“别称”等属性，并设置有相应的属性值；“类存款账户”实体包括“账户号”、“办理时间”等属性，并设置有相应的属性值；“商业组织”实体包括“名称”“营业地址”“类型”“类型码”等属性，并设置有相应的属性值；“第三方支付机构”实体包括“名称”、“收单机构代码”等属性，并设置有相应的属性值。
示例性地，基于银行领域的法律法规实例化图2中的“银行”概念，从而确定每个“银行”实体包含“名称”、“所属银行”等属性；基于第三方支付领域的法律法规实例化图2中的“第三方支付机构”概念，从而确定每个“第三方支付机构”实体包含“名称”、“收单机构代码”等属性。其他概念的实例化过程与“银行”和“第三方支付机构”类似，在此不再展开描述。
在获得支付知识图谱之后，即可结合历史交易数据生成相应的策略图谱。下面对本公开实施例的策略图谱进行展开说明。
图4为根据本公开的实施例的策略图谱的示意图。参照图4，在该策略图谱中，用户群体节点1对应k个交易场景节点，各个交易场景节点又分别对应若干个规则特征节点。用户群体节点1处于交易场景节点1的概率为参与概率1，用户群体节点1处于交易场景节点2的概率为参与概率2，……，用户群体节点1处于交易场景节点k的概率为参与概率k，且参与概率1至参与概率k之和理论上应该为1。
示例性地，交易场景节点1对应的n个规则特征节点，分别是规则特征节点11、规则特征节点12、……、规则特征节点1n，表示用户群体节点1处于交易场景节点1时的交易行为特征可以由上述n个规则特征节点进行表示。类似的，交易场景节点2对应m个规则特征节点，用于表示用户群体节点1处于交易场景节点2时的交易行为特征；交易场景节点k对应t个规则特征节点，用于表示用户群体节点1处于交易场景节点k时的交易行为特征。其中，n、m、k、t均为大于或等于1的整数。
需要说明的是，图4仅示出策略图谱中关于用户群体节点1的相关内容，在策略图谱中，还可能存在其他用户群体节点(未示出)，本公开对此不做限制。
图5为根据本公开的实施例的策略图谱的示意图。参照图5，用户群体节点为人群节点，处于对应的交易场景节点的概率为参与概率，且交易场景节点对应两类规则特征节点，第一类为常规的规则特征节点，包括时间规则节点、金额规则节点和交易对象规则节点，第二类属于前提性的规则特征节点，表示需满足一定的前提条件，包括前提规则节点。
将图5所示的策略图谱进行进一步细化可获得图6所示的策略图谱。
图6为根据本公开的实施例的策略图谱的示意图。参照图6，用户群体节点包括商旅群体节点和欺诈1型群体节点，其中，商旅群体节点对应的交易场景节点包括网购场景节点和住宿场景节点，且商旅群体节点处于网购场景节点的概率为40％，处于住宿场景节点的概率为60％，欺诈1型群体节点对应的交易场景节点包括住宿场景节点和欺诈场景节点，且欺诈1型群体节点处于住宿场景节点的概率为30％，处于欺诈场景节点的概率为70％。
以住宿场景节点为例展开说明。如图6所示，住宿场景节点对应一个前提规则节点和三个常规的规则特征节点，分别是时间规则节点、金额规则节点和交易对象规则节点。其前提规则节点的内容为当前未出现住宿消费，时间规则节点满足正态分布(18,2)，且取值为(0,24)，金额规则节点满足正态分布(50,10)，且取值为(200,100)，交易对象规则节点的内容包括地址和类型，其中地址的取值为当天所在地址，类型取值包括民宿、酒店。
需要说明的是，正态分布N(μ,σ2)中，μ表示数学期望，σ2表示方差，对应的取值(x1,x2)表示基于该正态分布的取值范围大于x1且小于x2。时间规则节点满足正态分布(18,2)是指时间规则节点中时间的取值满足期望为18，方差为2的正态分布，取值为(0,24)表示时间的取值范围为0时刻至24时刻。
在一些可选的实现方式中，可以对支付知识图谱和/或策略图谱进行扩展，获得扩展后的支付知识图谱和/或策略图谱。扩展后的支付知识图谱相较于原有的支付知识图谱而言，有效地扩大了对实体、属性和关系的表征范围，扩展后的策略图谱中新增了策略场景信息或者对原有的策略场景信息进行了拓展，从而可以更加全面生动地表征各类实体的行为特征。
需要说明的是，扩展后的支付知识图谱和/或策略图谱同样能够用于生成相应的交易仿真数据，且由于图谱得到扩展，生成的交易仿真数据的类型更加多样丰富，且与真实交易数据的接近程度更高，从而能够获得更准确的策略验证结果，便于制定和更新异常交易应对策略。
图7为根据本公开的实施例的异常交易应对策略的验证方法的流程图。参照图7，该异常交易应对策略的验证方法包括步骤S71至S75。
在步骤S71中，根据支付领域数据和通用数据，构建支付知识图谱，通用数据为在多个领域具有通用性的数据。
支付知识图谱用于表征支付领域的实体、实体的属性以及实体之间的关系，实体包括用户实体和支付相关机构实体。
在步骤S72中，根据支付知识图谱和历史交易数据确定策略场景信息，并基于策略场景信息构建策略图谱。
策略图谱表征支付领域中多个用户群体在多个交易场景下的支付行为，多个用户群体是基于支付知识图谱中的各个用户实体所属的群体的类别确定的。
步骤S71与S72与参照图1描述的步骤S 11和S 12相同，在此不再详细描述。
在步骤S73中，基于知识库，对支付知识图谱和/或策略图谱进行扩展，获得扩展后的支付知识图谱和/或扩展后的策略图谱。
知识库是关于知识的集合，且其中的知识根据其应用领域特征、背景特征、使用特征、属性特征等被构成便于利用的、有结构的组织形式。
在一些可选的实现方式中，知识库为基于专家系统构建的数据库，其中包括由专家设计制定的各种规则、策略以及相互之间的关联关系等内容。
在一些可选的实现方式中，步骤S73中，基于知识库对支付知识图谱进行扩展，获得扩展后的支付知识图谱，包括：基于知识库和支付知识图谱，确定候选支付知识子图；基于知识库制定扩展策略，并基于扩展策略对候选支付知识子图的拓扑结构、实体属性和实体关系中的至少一种进行扩展，获得支付知识扩展子图；将支付知识扩展子图融合到支付知识图谱中，获得扩展后的支付知识图谱。
换言之，候选支付知识子图是用于进行图谱扩展的基础，只有确定候选支付知识子图之后，才能执行相应的扩展操作。
示例性地，支付知识图谱包括多个支付知识子图。将支付知识图谱划分为多个支付知识子图的划分方式可具有多种，本公开对此不做限制。例如，可根据期望得到的候选支付知识子图的结构(如，具有哪些实体)将支付知识图谱划分为多个支付知识子图。例如，每个支付知识子图可包括一个“地址”实体和与该“地址”实体具有关系的至少一个用户实体。基于知识库和支付知识图谱，确定候选支付知识子图，包括：基于知识库，构建支付知识子图查询条件；根据支付知识子图查询条件，在支付知识图谱包括的所述多个支付知识子图中进行查询，获得多个匹配支付知识子图；根据预设的合并条件，将满足合并条件的匹配支付知识子图进行合并，获得合并支付知识子图；根据预设的子图裁剪方案，对合并支付知识子图进行裁剪，获得候选支付知识子图。
考虑到在各类异常交易场景中，地址是关联实体的重要关系之一，因此，可以基于地址设置相应的支付知识子图查询条件，最终获得关于地址的候选支付知识子图。
例如，支付知识子图查询条件为至少两个支付知识子图的“地址”实体所表示的地址之间的相似度大于相似度阈值，以用于查询支付知识图谱包括的多个支付知识子图中的地址之间的相似度大于相似度阈值的支付知识子图作为匹配支付知识子图。合并条件为至少两 个匹配支付知识子图的“地址”实体所表示的地址之间的距离小于预设距离阈值。多个匹配支付知识子图是指根据支付知识子图查询条件在支付知识图谱包括的多个支付知识子图中查询获得的子图。合并支付知识图谱是将地址之间的距离小于预设距离阈值的匹配支付知识子图进行合并得到的。子图裁剪方案为基于选取的裁剪地址对合并支付知识子图进行裁剪。
基于知识库和支付知识图谱，确定候选支付知识子图，包括：根据支付知识子图查询条件在支付知识图谱包括的多个支付知识子图中进行查询，获得地址相似度大于相似度阈值的多个支付知识子图作为匹配支付知识子图；将地址之间的距离小于预设距离阈值的匹配支付知识子图进行合并，获得合并支付知识子图；从合并支付知识子图所包括的“地址”实体所表示的地址中选取至少一个地址作为裁剪地址；基于裁剪地址对合并支付知识子图进行裁剪，获得候选支付知识子图，其中，候选支付知识子图的地址中至少存在一个裁剪地址。
图8为根据本公开的实施例的子图合并的示意图。参照图8，匹配支付知识子图1和匹配支付知识子图2是基于支付知识子图查询条件查询获得的两个匹配支付知识子图。
如图8所示，在匹配支付知识子图1中，“个人1”实体、“个人2”实体和“个人3”实体的户口地址均指向“地址1”实体，在匹配支付知识子图2中，“个人4”实体、“个人5”实体和“个人6”实体的户口地址均指向“地址2”实体，且“个人4”实体的联系地址指向“地址1”实体。由于地址1和地址2之间的距离小于预设距离阈值，因此，可以将匹配支付知识子图1和匹配支付知识子图2进行合并处理，从而获得相应的合并支付知识子图。
图9为根据本公开的实施例的候选支付知识子图的获取过程示意图。参照图9，基于预设的支付知识子图查询条件在支付知识图谱中进行查询，获得的多个匹配支付知识子图(如，匹配支付知识子图11、匹配支付知识子图12、……、匹配支付知识子图17等)。匹配支付知识子图11包括“地址a1”实体，匹配支付知识子图12包括“地址b1”实体，匹配支付知识子图13包括“地址b2”实体，匹配 支付知识子图14包括“地址a2”实体，匹配支付知识子图15包括“地址a3”实体，匹配支付知识子图16包括“地址a4”实体，匹配支付知识子图17包括“地址b3”实体。
地址a1、地址a2、地址a3、地址a4之间的距离较近，小于预设距离阈值，地址b1、地址b2、地址b3之间的距离较近，小于预设距离阈值。基于此，可以将地址之间的距离小于预设距离阈值的匹配支付知识子图进行合并，从而将匹配支付知识子图11、14、15和16合并成一个合并支付知识子图21，将匹配支付知识子图12、13和17合并成一个合并支付知识子图22。
随机从上述a1、a2、…、b3共7个地址中选取a1、a3、a4、b2和b3作为裁剪地址，获得图9所示的候选支付知识子图(包括候选支付知识子图31至候选支付知识子图35)，且候选支付知识子图对应的地址中至少存在一个裁剪地址。其中，在候选支付知识子图31中，包括裁剪地址a1，在候选支付知识子图32中，包括裁剪地址a3，在候选支付知识子图33中，包括裁剪地址b2，在候选支付知识子图34中，包括裁剪地址a4，在候选支付知识子图35中，包括裁剪地址b3。
上述裁剪方式仅是示例，本公开对此不做限制。例如，也可以将合并支付知识子图21中的包括地址a1和地址a2的部分或包括地址a3和地址a4的部分等、合并支付知识子图22中的包括地址b1和地址b2的部分或包括地址b2和地址b3的部分等裁剪为候选支付知识子图。
需要说明的是，在各类异常交易场景中，除了地址之外，银行卡等也是关联实体的重要关系之一，因此，还可以基于“银行”实体或“信用卡账户”实体等设置相应的支付知识子图查询条件，最终获得关于银行卡的候选支付知识子图。在这种情况下，支付知识图谱包括的每个支付知识子图可包括一个“银行”实体或“信用卡账户”实体等以及与其具有关系的其他实体。
在一些可选的实现方式中，在获得候选支付知识子图之后，可以向专家展示获得的候选支付知识子图，供专家进行确认和修改。专 家对候选支付知识子图的修改，包括但不限于：新增实体(可以对新增实体进行初始化)，新增关系，删除实体，删除关系，属性的修改(例如，采用从姓名库中随机采样的方式，更改人物实体的姓名属性值)或删除等。
需要说明的是，以上对于对候选支付知识子图的修改仅是举例说明，本公开对此不做限制。
在一些可选的实现方式中，步骤S73中，对策略图谱进行扩展，获得扩展后的策略图谱，包括：基于知识库，确定新增节点，新增节点包括用户群体节点、新增交易场景节点和新增规则特征节点中的至少一种；基于新增节点，构建策略扩展子图；将策略扩展子图融合到策略图谱中，获得扩展后的策略图谱。
图10为根据本公开的实施例的策略图谱的示意图。参照图10，在原策略图谱的基础上，确定一个新增一个用户群体节点，即，新型欺诈群体节点，并确定该新型欺诈群体节点对应新型欺诈场景节点1和新型欺诈场景节点2，且新型欺诈群体节点处于新型欺诈场景节点1的概率为80％，新型欺诈群体节点处于新型欺诈场景节点2的概率为20％，各个新型欺诈场景节点分别对应若干规则特征节点。
如图10所示，新型欺诈场景节点1对应3个规则特征节点，分别是时间规则节点、金额规则节点和交易对象规则节点，其中，时间规则节点满足均匀分布，且取值为(10,16)，金额规则节点满足正态分布(0.8,0.1)，且取值为(0.2,0.9)，交易对象规则节点包括地址和类型，其中地址的取值为XX市XX区，类型的取值包括民宿和酒店。类似的，新型欺诈场景节点2也对应相应的规则特征节点(图中未示出)。
需要说明的是，对支付知识图谱和策略图谱的扩展，可以是在在出现新的欺诈手段之后，基于该新出现的欺诈手段及时扩展支付知识图谱和策略图谱；或者，专家预先想到可能出现的欺诈手段、或者制定新的异常交易应对策略的情况下，可以对现有的支付知识图谱和/或策略图谱进行相应扩展，基于扩展后的支付知识图谱和/或策略图谱生成交易仿真数据，并执行异常交易应对策略的验证。
在步骤S74中，基于支付知识图谱和策略图谱，生成待验证异常交易手段对应的交易仿真数据。
在一些可选的实现方式中，在只扩展了支付知识图谱的情况下，可以基于扩展后的支付知识图谱和原有的策略图谱，生成待验证异常交易手段对应的交易仿真数据；在只扩展了策略图谱的情况下，可以基于原有的支付知识图谱和扩展后的策略图谱，生成待验证异常交易手段对应的交易仿真数据；在支付知识图谱和策略图谱均得到扩展的情况下，可以基于扩展后的支付知识图谱和扩展后的策略图谱，生成待验证异常交易手段对应的交易仿真数据。
需要说明的是，若规则特征节点中包括前提规则节点，则在生成交易仿真数据时，还需基于前提规则节点筛选对应的交易场景节点下的规则特征节点。示例性地，首先判断前提规则节点是否存在，如果存在，则获取对应实体的历史交易记录，并根据前提规则节点进行判断，确定该历史交易记录是否符合该前提规则节点的内容，并在不符合的情况下重新确定新的实体，并开展新的判断操作；在符合的情况下根据各项规则特征节点生成相应的交易仿真数据。
在步骤S75中，基于交易仿真数据，对与待验证异常交易手段对应的异常交易应对策略进行验证，获得策略验证结果。
根据本公开的实施例，在获得支付知识图谱和策略图谱之后，还可以对支付知识图谱和/或策略图谱进行扩展，能够增加实体和关系的表征范围，丰富各类交易场景及交易行为，使支付知识图谱和策略图谱具有一定的学习和更新能力，以基于扩展后的支付知识图谱和/或策略图谱，获得更加全面、更接近实际情况的交易仿真数据，从而适用于对可能出现但实际还未出现的异常交易手段进行预先仿真，以及早制定合适的异常交易应对策略，或者对刚制定的异常交易应对策略进行及时验证，以制定出有效的异常交易应对策略，从而保障资产安全。
图11为根据本公开的实施例的异常交易应对策略的验证装置的框图。参照图11，该异常交易应对策略的验证装置1100，包括构建模块1101、生成模块1102和验证模块1103。
构建模块1101用于根据支付领域数据和通用数据，构建支付知识图谱，通用数据为在多个领域具有通用性的数据，支付知识图谱用于表征支付领域的实体、实体的属性以及实体之间的关系，实体包括用户实体和支付相关机构实体。
构建模块1101还用于根据支付知识图谱和历史交易数据确定策略场景信息，并基于策略场景信息构建策略图谱，策略图谱表征支付领域中多个用户群体在多个交易场景下的支付行为，多个用户群体是基于支付知识图谱中的各个用户实体所属的群体的类别确定的。
生成模块1102用于基于支付知识图谱和策略图谱，生成与待验证异常交易手段对应的交易仿真数据。
验证模块1103用于基于交易仿真数据，对与待验证异常交易手段对应的异常交易应对策略进行验证，获得策略验证结果。
在一些可选的实现方式中，策略场景信息至少包括用户群体节点、交易场景节点和规则特征节点。相应的，构建模块包括聚类子模块、第一确定子模块、第二确定子模块和策略图谱建立子模块。聚类子模块用于对支付知识图谱中的各个用户实体进行聚类处理，确定至少一个用户群体节点；第一确定子模块用于根据历史交易数据，确定各个用户群体节点所对应的交易场景节点，以及各个交易场景节点下的交易行为特征；第二确定子模块用于基于交易行为特征确定与交易场景节点对应的至少一个规则特征节点；策略图谱建立子模块用于基于用户群体节点、交易场景节点、规则特征节点的对应关系，建立策略图谱。
在一些可选的实现方式中，第二确定子模块包括统计单元、拟合单元和构建单元。统计单元用于对与各个用户群体节点对应的各个交易场景节点下的各类交易行为特征进行统计分析，确定各类交易行为特征符合的统计分布；拟合单元用于对各类交易行为特征的统计分布进行拟合处理，获得各个统计分布的拟合函数；构建单元用于基于各个统计分布的拟合函数，构建与各类交易行为特征对应的各个规则特征节点。
在一些可选的实现方式中，交易仿真数据包括实体仿真数据和 行为仿真数据。相应的，生成模块包括第三确定子模块、第一仿真子模块和第二仿真子模块。第三确定子模块用于根据待验证异常交易手段，确定待仿真的多个实体的属性和实体之间的关系；第一仿真子模块用于基于待仿真的多个实体的属性和实体之间的关系，从支付知识图谱中选取与待仿真的实体的属性及关系均相匹配的实体作为仿真实体，获得实体仿真数据；第二仿真子模块用于确定与仿真实体属性对应的用户群体节点，根据策略图谱中用户群体节点以及对应的交易场景节点、规则特征节点，生成行为仿真数据。
在一些可选的实现方式中，异常交易应对策略的验证装置1100还包括扩展模块，其用于基于知识库，对支付知识图谱和/或策略图谱进行扩展，获得扩展后的支付知识图谱和/或扩展后的策略图谱。
在一些可选的实现方式中，扩展模块包括第一扩展子模块和第二扩展子模块。第一扩展子模块用于对支付知识图谱进行扩展，获得扩展后的支付知识图谱，第二扩展子模块用于对策略图谱进行扩展，获得扩展后的策略图谱。
在一些可选的实现方式中，第一扩展子模块包括第一确定单元、第一扩展单元和第一融合单元。第一确定单元用于基于知识库和支付知识图谱，确定候选支付知识子图；第一扩展单元用于基于知识库制定扩展策略，并基于扩展策略对候选支付知识子图的拓扑结构、实体属性和实体关系中的至少一种进行扩展，获得支付知识扩展子图；第一融合单元用于将支付知识扩展子图融合到支付知识图谱中，获得扩展后的支付知识图谱。
在一些可选的实现方式中，第一确定单元包括条件构建子单元、查询子单元、合并子单元和裁剪子单元。条件构建子单元用于基于知识库，构建支付知识子图查询条件；查询子单元用于根据支付知识子图查询条件，在支付知识图谱中进行查询，获得多个匹配支付知识子图；合并子单元用于根据预设的合并条件，将满足合并条件的匹配支付知识子图进行合并，获得合并支付知识子图；裁剪子单元用于根据预设的子图裁剪方案，对合并支付知识子图进行裁剪，获得候选支付知识子图。
在一些可选的实现方式中，支付知识子图查询条件为至少两个支付知识子图的“地址”实体所表示的地址之间的相似度大于相似度阈值，以用于查询支付知识图谱包括的多个支付知识子图中的地址之间的相似度大于相似度阈值的多个支付知识子图作为匹配支付知识子图。合并条件为至少两个匹配支付知识子图的“地址”实体所表示的地址之间的距离小于预设距离阈值。相应的，查询子单元，用于根据支付知识子图查询条件在支付知识图谱中包括的多个支付知识子图进行查询，获得地址相似度大于相似度阈值的多个支付知识子图作为匹配支付知识子图。合并子单元，用于将地址之间的距离小于预设距离阈值的匹配支付知识子图进行合并，获得合并支付知识子图；裁剪子单元，用于从合并支付知识子图所包括的地址中选取至少一个地址作为裁剪地址，并基于裁剪地址对合并支付知识子图进行裁剪，获得候选支付知识子图，其中，候选支付知识子图的地址中至少存在一个裁剪地址。
在一些可选的实现方式中，第二扩展子模块包括第二确定单元、第二扩展单元和第二融合单元。第二确定单元用于基于知识库，确定新增用户群体节点、新增交易场景节点和新增规则特征节点中的至少一种；第二扩展单元用于基于确定的新增人群节点、新增交易场景节点和新增规则特征节点中的至少一种，构建策略扩展子图；第二融合单元用于将策略扩展子图融合到策略图谱中，获得扩展后的策略图谱。
在本公开中，首先，由构建模块根据支付领域数据和通用数据构建支付知识图谱，以直观形象地表示实体属性以及实体之间的关系；其次，通过构建模块根据支付知识图谱和历史交易数据，确定策略场景信息，并基于策略场景信息构建策略图谱，对实体的属性、场景和行为进行了抽象出来，从而可以在行为层面反映不同类型的实体在不同场景中的特征；然后，由生成模块基于支付知识图谱和策略图谱，可以生成与待验证异常交易手段对应的交易仿真数据，不再依赖或受限于实际的历史交易数据，能够获得足够数量的交易仿真数据，为后续策略验证提供了数据基础；最后，由验证模块基于交易仿真数据，可以及时准确地对相应的异常交易应对策略进行验证，缩短了新异常 交易手段出现到验证异常交易应对策略之间的时间，从而能够快速地制定出效果较好的异常交易应对策略，进一步保障了用户的资金安全。
可以理解，本公开提及的上述各实施例，在不违背原理逻辑的情况下，均可以彼此相互结合形成结合后的实施例，限于篇幅，本公开不再赘述。本领域技术人员可以理解，在具体实施方式的上述方法中，各步骤的具体执行顺序应当以其功能和可能的内在逻辑确定。
此外，本公开还提供了电子设备、计算机可读存储介质，上述均可用来实现根据本公开的实施例的异常交易应对策略的验证方法，相应技术方案和描述和参见方法部分的相应记载，不再赘述。
图12为根据本公开的实施例的电子设备的框图。
参照图12，本公开提供了一种电子设备，该电子设备包括：至少一个处理器1201；至少一个存储器1202，以及一个或多个I/O接口1203，其连接在处理器1201与存储器1202之间。存储器1202存储有可被至少一个处理器1201执行的一个或多个计算机程序，一个或多个计算机程序在被至少一个处理器1201执行时，使至少一个处理器1201能够执行上述的异常交易应对策略的验证方法。
本公开还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序在被处理器/处理核执行时实现上述的异常交易应对策略的验证方法。计算机可读存储介质可以是易失性或非易失性计算机可读存储介质。
本公开还提供了一种计算机程序，包括计算机可读代码，或者承载有计算机可读代码的非易失性计算机可读存储介质，当所述计算机可读代码在电子设备的处理器中运行时，所述电子设备中的处理器执行上述异常交易应对策略的验证方法。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如 中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读存储介质上，计算机可读存储介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。
如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读程序指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM)、静态随机存取存储器(SRAM)、闪存或其他存储器技术、便携式压缩盘只读存储器(CD-ROM)、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读程序指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
这里所描述的计算机可读程序指令可以从计算机可读存储介质下载到各个计算/处理设备，或者通过网络、例如因特网、局域网、广域网和/或无线网下载到外部计算机或外部存储设备。网络可以包括铜传输电缆、光纤传输、无线传输、路由器、防火墙、交换机、网关计算机和/或边缘服务器。每个计算/处理设备中的网络适配卡或者网络接口从网络接收计算机可读程序指令，并转发该计算机可读程序指令，以供存储在各个计算/处理设备中的计算机可读存储介质中。
用于执行本公开操作的计算机程序指令可以是汇编指令、指令集架构(ISA)指令、机器指令、机器相关指令、微代码、固件指令、状态设置数据、或者以一种或多种编程语言的任意组合编写的源代码或目标代码，所述编程语言包括面向对象的编程语言—诸如Smalltalk、C++等，以及常规的过程式编程语言—诸如“C”语言或类似的编程语言。计算机可读程序指令可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分 在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络—包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。在一些实施例中，通过利用计算机可读程序指令的状态信息来个性化定制电子电路，例如可编程逻辑电路、现场可编程门阵列(FPGA)或可编程逻辑阵列(PLA)，该电子电路可以执行计算机可读程序指令，从而实现本公开的各个方面。
这里所描述的计算机程序可以具体通过硬件、软件或其结合的方式实现。在一个可选实施例中，所述计算机程序具体体现为计算机存储介质，在另一个可选实施例中，计算机程序具体体现为软件产品，例如软件开发包(Software Development Kit，SDK)等等。
这里参照根据本公开实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。
这些计算机可读程序指令可以提供给通用计算机、专用计算机或其它可编程数据处理装置的处理器，从而生产出一种机器，使得这些指令在通过计算机或其它可编程数据处理装置的处理器执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。
也可以把计算机可读程序指令加载到计算机、其它可编程数据处理装置、或其它设备上，使得在计算机、其它可编程数据处理装置或其它设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其它可编程数据处理装置、或其它设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。
附图中的流程图和框图显示了根据本公开的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，所述模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
本文已经公开了示例实施例，并且虽然采用了具体术语，但它们仅用于并仅应当被解释为一般说明性含义，并且不用于限制的目的。在一些实例中，对本领域技术人员显而易见的是，除非另外明确指出，否则可单独使用与特定实施例相结合描述的特征、特性和/或元素，或可与其他实施例相结合描述的特征、特性和/或元件组合使用。因此，本领域技术人员将理解，在不脱离由所附的权利要求阐明的本公开的范围的情况下，可进行各种形式和细节上的改变。

Claims (20)

  1. 一种异常交易应对策略的验证方法，包括：
    根据支付领域数据和通用数据，构建支付知识图谱；
    根据所述支付知识图谱和历史交易数据确定策略场景信息，并基于所述策略场景信息构建策略图谱；
    基于所述支付知识图谱和所述策略图谱，生成与待验证异常交易手段对应的交易仿真数据；
    基于所述交易仿真数据对与所述待验证异常交易手段对应的异常交易应对策略进行验证，获得策略验证结果。
  2. 根据权利要求1所述的验证方法，其中，所述策略场景信息至少包括用户群体节点、交易场景节点和规则特征节点，并且
    其中，根据所述支付知识图谱和所述历史交易数据确定策略场景信息包括：
    对所述支付知识图谱中的各个用户实体进行聚类处理，确定至少一个用户群体节点；
    根据所述历史交易数据，确定各个用户群体节点所对应的至少一个交易场景节点，以及各个交易场景节点下的交易行为特征；
    基于所述各个交易场景节点下的交易行为特征确定与所述各个交易场景节点对应的至少一个规则特征节点。
  3. 根据权利要求2所述的验证方法，其中，基于所述各个交易场景节点下的交易行为特征确定与所述各个交易场景节点对应的至少一个规则特征节点包括：
    对与各个用户群体节点对应的各个交易场景节点下的各类交易行为特征进行统计分析，确定各类交易行为特征符合的统计分布；
    对各类交易行为特征的统计分布进行拟合处理，获得各个统计分布的拟合函数；
    基于各个统计分布的拟合函数，构建与各类交易行为特征对应 的各个规则特征节点。
  4. 根据权利要求2或3所述的验证方法，其中，基于所述策略场景信息构建所述策略图谱包括：
    基于所述至少一个用户群体节点、所述至少一个交易场景节点和所述至少一个规则特征节点的对应关系，构建所述策略图谱。
  5. 根据权利要求4所述的验证方法，其中，基于所述至少一个用户群体节点、所述至少一个交易场景节点和所述至少一个规则特征节点的对应关系，构建所述策略图谱包括：
    根据所述至少一个用户群体节点、所述至少一个交易场景节点和所述至少一个规则特征节点的对应关系，建议所述至少一个用户群体节点、所述至少一个交易场景节点和所述至少一个规则特征节点之间的连接线，其中，所述连接线的属性包括概率属性，所述概率属性表示由相应的连接线连接的两个节点之间的关联概率/参与概率。
  6. 根据权利要求5所述的验证方法，其中，所述概率属性的取值根据所述历史交易数据确定。
  7. 根据权利要求1所述的验证方法，其中，所述方法还包括：
    基于知识库对所述支付知识图谱和/或所述策略图谱进行扩展；
    根据扩展后的支付知识图谱和/或扩展后的策略图谱，更新所述支付知识图谱和/或策略图谱。
  8. 根据权利要求7所述的验证方法，其中，基于所述知识库对所述支付知识图谱进行扩展包括：
    基于所述知识库和所述支付知识图谱，确定候选支付知识子图；
    基于所述知识库制定扩展策略，并基于所述扩展策略对所述候选支付知识子图的拓扑结构、实体属性和实体关系中的至少一种进行扩展，获得支付知识扩展子图；
    将所述支付知识扩展子图融合到所述支付知识图谱中，获得扩展后的支付知识图谱。
  9. 根据权利要求8所述的验证方法，其中，所述支付知识图谱包括多个支付知识子图，并且
    其中，基于所述知识库和所述支付知识图谱，确定候选支付知识子图，包括：
    基于所述知识库，构建支付知识子图查询条件；
    根据所述支付知识子图查询条件，在所述支付知识图谱包括的所述多个支付知识子图中进行查询，获得多个匹配支付知识子图；
    根据预设的合并条件，将所述多个匹配支付知识子图中的满足所述合并条件的匹配支付知识子图进行合并，获得合并支付知识子图；
    根据预设的子图裁剪方案，对所述合并支付知识子图进行裁剪，获得所述候选支付知识子图。
  10. 根据权利要求9所述的验证方法，其中，所述实体还包括地址实体。
  11. 根据权利要求10所述的验证方法，其中，每个支付子图包括一个地址实体和与所述地址实体具有关系的至少一个用户实体，所述支付知识子图查询条件为至少两个支付知识子图中的地址实体所表示的地址之间的相似度大于相似度阈值，所述合并条件为至少两个匹配支付知识子图中的地址实体所表示的地址之间的距离小于预设距离阈值，
    所述多个匹配支付知识子图是根据所述支付知识子图查询条件在所述支付知识图谱包括的多个支付知识子图中查询获得的，
    所述合并支付知识图谱是将所述多个匹配支付知识子图中的满足所述合并条件的匹配支付知识子图进行合并得到的，
    所述子图裁剪方案为基于选取的裁剪地址对所述合并支付知识子图进行裁剪。
  12. 根据权利要求11所述的验证方法，其中，根据所述预设的子图裁剪方案，对所述合并支付知识子图进行裁剪，获得所述候选支付知识子图，包括：
    从所述合并支付知识子图所包括的地址实体所表示的地址中选取至少一个地址作为裁剪地址；
    基于所述裁剪地址对所述合并支付知识子图进行裁剪，获得所述候选支付知识子图，其中，所述候选支付知识子图的地址中至少存在一个所述裁剪地址。
  13. 根据权利要求7所述的验证方法，其中，基于所述知识库对所述策略图谱进行扩展包括：
    基于所述知识库确定新增节点，所述新增节点包括新增用户群体节点、新增交易场景节点和新增规则特征节点中的至少一种；
    基于所述新增节点构建策略扩展子图；
    将所述策略扩展子图融合到所述策略图谱中，获得扩展后的策略图谱。
  14. 根据权利要求2所述的验证方法，其中，所述交易仿真数据包括实体仿真数据和行为仿真数据，并且
    其中，基于所述支付知识图谱和所述策略图谱，生成与所述待验证异常交易手段对应的交易仿真数据，包括：
    根据所述待验证异常交易手段，确定待仿真的多个实体的属性和实体之间的关系；
    基于所述待仿真的多个实体的属性和实体之间的关系，从所述支付知识图谱中选取与所述待仿真的实体的属性及关系均相匹配的实体作为仿真实体，获得所述实体仿真数据；
    确定与所述仿真实体对应的用户群体节点，根据所述策略图谱中所述用户群体节点以及对应的交易场景节点、规则特征节点，生成所述行为仿真数据。
  15. 根据权利要求1所述的验证方法，其中，基于所述交易仿真数据对与所述待验证异常交易手段对应的异常交易应对策略进行验证，获得所述策略验证结果，包括：
    将所述交易仿真数据输入预设的策略验证模型中，输出与所述异常交易应对策略的策略验证结果。
  16. 根据权利要求1所述的验证方法，其中，所述支付领域数据至少包括支付行业的行业规定数据、与支付领域相关的法律法规中的所述支付相关机构实体的公开资料、支付业务数据，所述通用数据至少包括地理信息数据。
  17. 根据权利要求16所述的验证方法，其中，根据所述支付领域数据和所述通用数据，构建所述支付知识图谱，包括：
    从所述支付行业规定数据中归纳支付流程中的多个概念和所述多个概念之间的关系，并基于所述多个概念和所述多个概念之间的关系建立支付知识图谱框架；
    根据所述公开资料，将所述多个概念中的一部分概念实例化为实体，确认每个实体的属性和实体间的关系；
    根据所述支付业务数据，将所述多个概念中的另一部分概念实例化为实体，确认每个实体的属性和实体间的关系；
    根据所述通用该数据，将所述多个概念中的再一部分概念实例化为实体，确认每个实体的属性和实体间的关系；以及
    根据所述支付知识图谱框架、所有实体、所有实体间的关系构建所述支付知识图谱。
  18. 一种异常交易应对策略的验证装置，包括：
    构建模块，用于根据支付领域数据和通用数据，构建支付知识图谱，所述通用数据为在多个领域具有通用性的数据，以及用于根据所述支付知识图谱和历史交易数据确定策略场景信息，并基于所述策 略场景信息构建策略图谱；
    生成模块，用于基于所述支付知识图谱和所述策略图谱，生成与待验证异常交易手段对应的交易仿真数据；
    验证模块，用于基于所述交易仿真数据对与所述待验证异常交易手段对应的异常交易应对策略进行验证，获得策略验证结果。
  19. 一种电子设备，其特征在于，包括：
    至少一个处理器；以及
    与所述至少一个处理器通信连接的存储器，其中，
    所述存储器存储有能够被所述至少一个处理器执行的一个或多个计算机程序，所述一个或多个所述计算机程序被所述至少一个处理器执行时，使所述至少一个处理器能够执行如权利要求1-17中任一项所述的异常交易应对策略的验证方法。
  20. 一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序在被处理器执行时实现如权利要求1-17中任一项所述的异常交易应对策略的验证方法。
PCT/CN2023/128100 2022-11-01 2023-10-31 异常交易应对策略的验证方法和验证装置 WO2024093960A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211357465.3 2022-11-01
CN202211357465.3A CN117993910A (zh) 2022-11-01 2022-11-01 异常交易应对策略的验证方法及相关装置

Publications (1)

Publication Number Publication Date
WO2024093960A1 true WO2024093960A1 (zh) 2024-05-10

Family

ID=90885901

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/128100 WO2024093960A1 (zh) 2022-11-01 2023-10-31 异常交易应对策略的验证方法和验证装置

Country Status (2)

Country Link
CN (1) CN117993910A (zh)
WO (1) WO2024093960A1 (zh)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109299283A (zh) * 2018-08-29 2019-02-01 阿里巴巴集团控股有限公司 一种基于知识图谱的数据推理方法、装置、服务器和介质
CN111126828A (zh) * 2019-12-19 2020-05-08 浙江邦盛科技有限公司 一种基于知识图谱的多层资金异常流向监控方法
CN111711614A (zh) * 2020-05-27 2020-09-25 平安科技（深圳）有限公司 基于知识图谱的可疑用户验证方法、装置及计算机设备
CN112927072A (zh) * 2021-01-20 2021-06-08 北京航空航天大学 一种基于区块链的反洗钱仲裁方法、系统及相关装置
WO2021259002A1 (zh) * 2020-06-23 2021-12-30 平安科技（深圳）有限公司 基于决策树的异常数据源输出方法、装置和计算机设备
CN115062163A (zh) * 2022-06-24 2022-09-16 中国工商银行股份有限公司 异常组织的识别方法、装置、电子设备和介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109299283A (zh) * 2018-08-29 2019-02-01 阿里巴巴集团控股有限公司 一种基于知识图谱的数据推理方法、装置、服务器和介质
CN111126828A (zh) * 2019-12-19 2020-05-08 浙江邦盛科技有限公司 一种基于知识图谱的多层资金异常流向监控方法
CN111711614A (zh) * 2020-05-27 2020-09-25 平安科技（深圳）有限公司 基于知识图谱的可疑用户验证方法、装置及计算机设备
WO2021259002A1 (zh) * 2020-06-23 2021-12-30 平安科技（深圳）有限公司 基于决策树的异常数据源输出方法、装置和计算机设备
CN112927072A (zh) * 2021-01-20 2021-06-08 北京航空航天大学 一种基于区块链的反洗钱仲裁方法、系统及相关装置
CN115062163A (zh) * 2022-06-24 2022-09-16 中国工商银行股份有限公司 异常组织的识别方法、装置、电子设备和介质

Also Published As

Publication number Publication date
CN117993910A (zh) 2024-05-07

Similar Documents

Publication Publication Date Title
CN110197280B (zh) 一种知识图谱构建方法、装置及系统
US20210241120A1 (en) Systems and methods for identifying synthetic identities
US20220076231A1 (en) System and method for enrichment of transaction data
Kulkarni et al. Advanced credit score calculation using social media and machine learning
CN113205402A (zh) 对账方法、装置、电子设备及计算机可读介质
CN112927082A (zh) 信用风险的预测方法、装置、设备、介质和程序产品
CN111949643A (zh) 基于业务建模的数据处理方法及系统
CN112581271B (zh) 一种商户交易风险监测方法、装置、设备及存储介质
CN108572988A (zh) 一种房产评估数据生成方法和装置
CN112925664A (zh) 目标用户的确定方法、装置、电子设备及存储介质
CN110197426B (zh) 一种信用评分模型的建立方法、装置及可读存储介质
Chen et al. A combined mining-based framework for predicting telecommunications customer payment behaviors
CN111798304A (zh) 一种风险贷款确定方法、装置、电子设备及存储介质
CN111415067A (zh) 企业及个人信用评级系统
CN112950359A (zh) 一种用户识别方法和装置
CN109636627B (zh) 基于区块链的保险产品管理方法、装置、介质及电子设备
CN112801784A (zh) 一种数字货币交易所的比特币地址挖掘方法及装置
CN111177653A (zh) 一种信用评估方法和装置
Bouzidi et al. LSTM-based automated learning with smart data to improve marketing fraud detection and financial forecasting
WO2024093960A1 (zh) 异常交易应对策略的验证方法和验证装置
CN116228402A (zh) 一种金融征信特征仓库技术支持系统
CN113870021B (zh) 一种数据的分析方法、装置、存储介质和电子设备
US11348115B2 (en) Method and apparatus for identifying risky vertices
CN113988878B (zh) 一种基于图数据库技术的反欺诈方法及系统
CN111429257B (zh) 一种交易监控方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23884890

Country of ref document: EP

Kind code of ref document: A1