A Customer Identification and Dynamic Monitoring Analysis System and Method Based on Intelligent Agents

Abstract

This invention discloses a customer identification and dynamic monitoring analysis system and method based on intelligent agents, belonging to the field of big data monitoring technology. The invention identifies structured transaction data in target customer transfer requests and assigns an independent code to each customer; it then filters out suspected risk data based on a first risk assessment condition; it calculates the correlation between suspected risk data and transaction data by weighting the correlation based on transfer time correlation, co-occurrence correlation, and interval correlation; and it distinguishes between risky and non-risky data based on a second risk assessment condition. Simultaneously, it sets an optimization cycle, adjusting the weights in the correlation calculation according to the risky data and the first risk assessment condition. This method can reduce false triggering rates, decrease manual and computational costs, dynamically adapt to risk characteristics, improve the timeliness of risk interception and the comprehensiveness of illegal transaction identification, and safeguard financial security.

Description

Technical Field

[0001] This invention relates to the field of big data supervision technology, specifically a customer identification and dynamic supervision analysis system and method based on intelligent agents. Background Technology

[0002] With the widespread adoption of online payment services, the convenience of fund transactions has significantly improved, but it has also created space for illegal activities. Illegal activities often evade regulation by using methods such as transferring funds during off-peak hours, disrupting the flow of funds in financial institutions and posing a potential threat to social financial security.

[0003] To control the risks of fund transactions, current mainstream risk assessment methods mostly rely on single judgment conditions such as transfer amount or transaction counterparty to screen transaction data for risks. This has a high false trigger rate, which not only affects the normal transfer experience for users, but also increases the manual review costs for financial institutions. In addition, the data processing volume is huge, which not only consumes a lot of computing resources, but may also lead to risky transactions not being intercepted in time due to low screening efficiency, thus weakening the risk control effect. Summary of the Invention

[0004] The purpose of this invention is to provide a customer identification and dynamic monitoring analysis system and method based on intelligent agents to solve the problems raised in the prior art.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a customer identification and dynamic monitoring analysis method based on intelligent agents, the method comprising the following steps:

[0006] Step S1: When the target customer initiates or receives a transfer request, identify the transaction data in the transfer request, including the transaction time, source of funds, and destination of funds;

[0007] Furthermore, step S1 also includes:

[0008] Each customer has a unique code; the transfer request includes risky requests, non-risky requests, and requests to be judged. The transaction data corresponding to risky requests is risky data, the transaction data corresponding to non-risky requests is non-risky data, and the transaction data corresponding to requests to be judged is data to be judged.

[0009] Preset keywords are used to identify transaction data in transfer requests and match the corresponding target customers; the transaction data is structured data; when a target customer initiates a transfer request, the source of funds is the target customer and the destination of funds is other customers; when a target customer receives a transfer request, the source of funds is other customers and the destination of funds is the target customer.

[0010] Step S2: Set the first risk assessment condition, and filter the transaction data according to the first risk assessment condition to obtain suspected risk data;

[0011] Furthermore, step S2 also includes:

[0012] Step S2-1: Establish a coding whitelist. If the target customer and the other customers are both in the coding whitelist, then mark the transfer request as a non-risk request; otherwise, mark the transfer request as a request to be judged.

[0013] Step S2-2: Set a risk assessment period and obtain the transaction time of the target customer in the non-risk data within the risk assessment period; divide the day into risk period and non-risk period, and count the average number of transactions of the target customer in the risk period within the risk assessment period based on the transaction time in the non-risk data. Record the preset percentage quantile of the average number of transactions in the risk period as the transaction number threshold T.

[0014] Obtain the source and destination of funds of the target customer in the non-risk data during the risk assessment period, extract the codes of other users to form a risk assessment code library, regard the codes not in the risk assessment code library as users outside the library, and preset the threshold S for users outside the library;

[0015] Step S2-3: Preset transfer interval threshold D; The first risk assessment condition includes transaction frequency threshold T, off-database user threshold S, and transfer interval threshold D;

[0016] Get the number of times that intraday transfer requests were marked as pending judgment during the risk period. Extract the number of times users outside the database appeared in the daily transfer requests. Calculate the time interval between adjacent transfer requests from users outside the database on the same day. ;like ≥T, or ≥S, or If the value is greater than or equal to D, the corresponding transfer request will be marked as a suspected risk request and the corresponding transaction data will be marked as suspected risk data; otherwise, the corresponding transfer request will be marked as a non-risk request and the corresponding transaction data will be marked as non-risk data.

[0017] Step S3: Obtain the risk correlation between suspected risk data and transaction data, set a second risk judgment condition, and filter the risk correlation according to the second risk judgment condition to obtain risk data and non-risk data.

[0018] Furthermore, step S3 also includes:

[0019] Step S3-1: Obtain the target customer's average daily total number of transactions during the risk assessment period. The average daily total number of transactions includes the target customer's average daily number of transactions during risky periods and the average daily number of transactions during non-risky periods within the risk assessment period. Calculate the percentage of transfer requests marked as suspected risky requests during risky periods in the average daily total number of transactions, as the transfer time correlation. ;

[0020] Step S3-2: Obtain the codes of other users in the suspected risk data, and denote them as codes to be tested; if the code to be tested is in the risk judgment code library, obtain the source and destination of funds in the risk data within the risk judgment period, count the total number of times all codes appear, and calculate the proportion of the code to be tested in the total number of times, which is denoted as the co-occurrence correlation degree. If the code to be tested is not in the risk assessment code library, the co-occurrence correlation will be determined. Recorded as 1;

[0021] Step S3-3: If the number of suspected risk requests in a given day is greater than 1, calculate the average transaction time interval between adjacent suspected risk requests in that day, obtain the daily average transaction time interval for different transaction times in the risk data within the risk assessment period, and calculate the interval correlation. =[1-| - | / ]×100%, of which This represents the average time interval between adjacent suspected risk requests on the same day. The average daily trading time interval represents the different trading times within the risk assessment period. - |Represents taking - The absolute value of the calculation result; if the number of suspected risk requests that occurred on that day is equal to 1, then Recorded as 0;

[0022] Step S3-4: Calculate the risk correlation S = α × 10⁻⁶ between suspected risk data and transaction data based on the transfer time correlation, co-occurrence correlation, and interval correlation. +β× +γ× α, β and γ are the corresponding weight coefficients, and their sum equals 1; a preset correlation threshold is used as the second risk judgment condition. If the risk correlation S is greater than or equal to the second risk judgment condition, the corresponding suspected risk request is marked as a risk request and the corresponding transaction data is marked as risk data; otherwise, the corresponding suspected risk request is marked as a non-risk request and the corresponding transaction data is marked as non-risk data.

[0023] Step S4: Optimize the acquisition of risk correlation based on the risk data and the first risk judgment condition;

[0024] Furthermore, step S4 also includes:

[0025] Set an optimization period and obtain risk data within that period. The number of times ≥T , The number of times ≥D Calculate the optimization coefficients and ,in = / ( + ), = / ( + The weighting coefficients in the risk correlation calculation were adjusted to... =α× , =γ× , =1-( + );in , , These are the adjusted weighting coefficients α, β, and γ, respectively.

[0026] A customer identification and dynamic monitoring analysis system based on intelligent agents, the system includes a transaction data identification module, a suspected risk screening module, a risk data judgment module and a judgment condition optimization module;

[0027] The transaction data recognition module is used to identify transaction data in a transfer request based on keywords.

[0028] The suspected risk screening module is used to set the first risk judgment condition and to screen the transaction data according to the first risk judgment condition to obtain suspected risk data.

[0029] The risk data determination module is used to set the second risk determination conditions and obtain the risk correlation between suspected risk data and transaction data to obtain risk data and non-risk data.

[0030] The judgment condition optimization module is used to optimize the acquisition of risk correlation based on risk data and the first risk judgment condition;

[0031] The transaction data identification module further includes a transaction data extraction unit and a customer code matching unit; the transaction data extraction unit is used to identify the transaction data in the transfer request based on keywords when the target customer initiates or receives the transfer request; the customer code matching unit is used to set an independent code for each customer and match the corresponding target customer based on the code.

[0032] The suspected risk screening module also includes a whitelist marking unit and a risk threshold setting unit. The whitelist marking unit is used to establish an coded whitelist. If the target customer and other customers are both in the coded whitelist, the transfer request is marked as a non-risk request; otherwise, the transfer request is marked as a request to be judged. The risk threshold setting unit is used to set the risk judgment period and judge the request to be judged as a suspected risk request or a non-risk request based on the transaction number threshold T, the off-database user threshold S, and the transfer interval threshold D.

[0033] The risk data determination module further includes a correlation calculation unit and a risk threshold determination unit; the correlation calculation unit is used to calculate the correlation of transfer time. Co-occurrence correlation Correlation with interval The risk threshold determination unit is used to preset a correlation threshold as a second risk judgment condition, and to determine whether a suspected risk request is a risk request or a non-risk request based on the second risk judgment condition.

[0034] The judgment condition optimization module further includes an optimization coefficient calculation unit and a weight coefficient adjustment unit; the optimization coefficient calculation unit is used to set the optimization period and obtain the number of requests to be judged in the risk data within the optimization period. The number of times ≥T The transfer time interval between adjacent transfer requests from users outside the database on the same day. The number of times ≥D ,according to and Calculate optimization coefficients and The weighting coefficient adjustment unit is used to adjust the weighting coefficients in the risk correlation calculation according to... and Adjust them separately.

[0035] The output of the transaction data identification module is connected to the input of the suspected risk screening module; the output of the suspected risk screening module is connected to the input of the risk data determination module; and the output of the risk data determination module is connected to the input of the judgment condition optimization module.

[0036] Compared with the prior art, the beneficial effects of the present invention are:

[0037] 1. This invention identifies transaction data in target customer transfer requests, then filters out suspected risk data based on a first risk assessment condition. Subsequently, it further calculates the correlation between transfer time, co-occurrence, and interval, and weights the correlation between suspected risk data and transaction data as the basis for a second risk assessment condition. This invention overcomes the limitations of existing technologies that rely on single-condition screening, significantly reduces the false trigger rate of risk assessment, reduces the cost of manual review by financial institutions, avoids the accidental interception of normal transfers that affects user experience, and improves the accuracy of risk identification.

[0038] 2. This invention establishes a dynamic optimization mechanism, sets an optimization cycle, and calculates optimization coefficients based on the first risk judgment condition and risk data. Accordingly, it adjusts the weight coefficients α, β, and γ of the transfer time correlation, co-occurrence correlation, and interval correlation in the risk correlation calculation, so that the risk judgment standard can be dynamically updated with the risk characteristics in actual transactions. This solves the problem that existing fixed judgment conditions are difficult to deal with the flexible avoidance methods of illegal activities, allows the supervision to always adapt to the current risk situation, improves the timeliness of risk transaction interception, and strengthens the ability to protect financial security.

[0039] 3. In the initial stage of risk screening, this invention uses a coded whitelist to quickly mark non-risk requests, directly eliminating transaction data that does not require in-depth analysis and reducing the total amount of subsequent data processing. Then, it uses multi-dimensional thresholds of the first risk judgment condition to initially focus on suspected risk data. Subsequently, it only calculates multi-dimensional correlation for suspected data, avoiding indiscriminate in-depth processing of all transactions and significantly reducing the consumption of computing resources. At the same time, it constructs a risk judgment system from three core dimensions: transaction time, transaction object, and transaction interval, comprehensively covering the means commonly used by illegal activities to evade supervision, making up for the shortcomings of the single dimension of existing technology supervision, improving the comprehensiveness of identifying illegal transactions, and maintaining the order of fund flow in financial institutions. Attached Figure Description

[0040] Figure 1 This is a flowchart illustrating a customer identification and dynamic monitoring analysis method based on intelligent agents according to the present invention.

[0041] Figure 2 This is a schematic diagram of the structure of a customer identification and dynamic monitoring analysis system based on intelligent agents according to the present invention. Detailed Implementation

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

[0043] Example 1: As Figure 1 As shown, the present invention provides a technical solution, a customer identification and dynamic monitoring analysis method based on intelligent agents, the method comprising the following steps:

[0044] Step S1: When the target customer initiates or receives a transfer request, identify the transaction data in the transfer request, including the transaction time, source of funds, and destination of funds;

[0045] Step S1 further includes:

[0046] Each customer has a unique code; the transfer request includes risky requests, non-risky requests, and requests to be judged. The transaction data corresponding to risky requests is risky data, the transaction data corresponding to non-risky requests is non-risky data, and the transaction data corresponding to requests to be judged is data to be judged.

[0047] Preset keywords are used to identify transaction data in transfer requests and match the corresponding target customers; the transaction data is structured data; when a target customer initiates a transfer request, the source of funds is the target customer and the destination of funds is other customers; when a target customer receives a transfer request, the source of funds is other customers and the destination of funds is the target customer.

[0048] Step S2: Set the first risk assessment condition, and filter the transaction data according to the first risk assessment condition to obtain suspected risk data;

[0049] Step S2 further includes:

[0050] Step S2-1: Establish a coding whitelist. If the target customer and the other customers are both in the coding whitelist, then mark the transfer request as a non-risk request; otherwise, mark the transfer request as a request to be judged.

[0051] Step S2-2: Set a risk assessment period and obtain the transaction time of the target customer in the non-risk data within the risk assessment period; divide the day into risk period and non-risk period, and count the average number of transactions of the target customer in the risk period within the risk assessment period based on the transaction time in the non-risk data. Record the preset percentage quantile of the average number of transactions in the risk period as the transaction number threshold T.

[0052] Obtain the source and destination of funds of the target customer in the non-risk data during the risk assessment period, extract the codes of other users to form a risk assessment code library, regard the codes not in the risk assessment code library as users outside the library, and preset the threshold S for users outside the library;

[0053] Step S2-3: Preset transfer interval threshold D; The first risk assessment condition includes transaction frequency threshold T, off-database user threshold S, and transfer interval threshold D;

[0054] Get the number of times that intraday transfer requests were marked as pending judgment during the risk period. Extract the number of times users outside the database appeared in the daily transfer requests. Calculate the time interval between adjacent transfer requests from users outside the database on the same day. ;like ≥T, or ≥S, or If the value is greater than or equal to D, the corresponding transfer request will be marked as a suspected risk request and the corresponding transaction data will be marked as suspected risk data; otherwise, the corresponding transfer request will be marked as a non-risk request and the corresponding transaction data will be marked as non-risk data.

[0055] Step S3: Obtain the risk correlation between suspected risk data and transaction data, set a second risk judgment condition, and filter the risk correlation according to the second risk judgment condition to obtain risk data and non-risk data.

[0056] Step S3 further includes:

[0057] Step S3-1: Obtain the target customer's average daily total number of transactions during the risk assessment period. The average daily total number of transactions includes the target customer's average daily number of transactions during risky periods and the average daily number of transactions during non-risky periods within the risk assessment period. Calculate the percentage of transfer requests marked as suspected risky requests during risky periods in the average daily total number of transactions, as the transfer time correlation. ;

[0058] Step S3-2: Obtain the codes of other users in the suspected risk data, and denote them as codes to be tested; if the code to be tested is in the risk judgment code library, obtain the source and destination of funds in the risk data within the risk judgment period, count the total number of times all codes appear, and calculate the proportion of the code to be tested in the total number of times, which is denoted as the co-occurrence correlation degree. If the code to be tested is not in the risk assessment code library, the co-occurrence correlation will be determined. Recorded as 1;

[0059] Step S3-3: If the number of suspected risk requests in a given day is greater than 1, calculate the average transaction time interval between adjacent suspected risk requests in that day, obtain the daily average transaction time interval for different transaction times in the risk data within the risk assessment period, and calculate the interval correlation. =[1-| - | / ]×100%, of which This represents the average time interval between adjacent suspected risk requests on the same day. The average daily trading time interval represents the different trading times within the risk assessment period. - |Represents taking - The absolute value of the calculation result; if the number of suspected risk requests that occurred on that day is equal to 1, then Recorded as 0;

[0060] Step S3-4: Calculate the risk correlation S = α × 10⁻⁶ between suspected risk data and transaction data based on the transfer time correlation, co-occurrence correlation, and interval correlation. +β× +γ× α, β and γ are the corresponding weight coefficients, and their sum equals 1; a preset correlation threshold is used as the second risk judgment condition. If the risk correlation S is greater than or equal to the second risk judgment condition, the corresponding suspected risk request is marked as a risk request and the corresponding transaction data is marked as risk data; otherwise, the corresponding suspected risk request is marked as a non-risk request and the corresponding transaction data is marked as non-risk data.

[0061] Step S4: Optimize the acquisition of risk correlation based on the risk data and the first risk judgment condition;

[0062] Step S4 further includes:

[0063] Set an optimization period and obtain risk data within that period. The number of times ≥T , The number of times ≥D Calculate the optimization coefficients and ,in = / ( + ), = / ( + The weighting coefficients in the risk correlation calculation were adjusted to... =α× , =γ× , =1-( + );in , , These are the adjusted weighting coefficients α, β, and γ, respectively.

[0064] For example:

[0065] The target customer is Customer A, with a unique code of C001; the risk assessment period is set to 7 days (May 13-19, 2024); the code whitelist includes C001, C002, and C003 (all of which are Customer A's historical risk-free transaction objects); a day is divided into risk periods (0:00-9:00, 18:00-24:00) and non-risk periods (9:00-18:00); the optimization period is set to 14 days.

[0066] Step S1, Transaction Data Identification:

[0067] Customer A initiated 3 transfer requests and received 1 transfer request on May 20, 2024. The transaction data is as follows:

[0068] 08:30, Funds source C001, Funds destination C004 (non-whitelisted user);

[0069] 10:15, Funds source C001, Funds destination C002 (whitelisted user);

[0070] At 19:45, the source of funds was C005 (a non-whitelisted user), and the destination of funds was C001.

[0071] 21:20, Funds source C001, Funds destination C006 (non-whitelisted user);

[0072] All transaction data is structured data, and the target customer C001 is matched by preset keywords such as "transfer amount", "payer code", and "recipient code".

[0073] Step S2, the first risk assessment criterion filters suspected risk data:

[0074] Whitelist marking: In the second transfer, the destination of funds C002 is in the whitelist and is marked as a non-risk request; the other 3 transfers are marked as requests pending judgment.

[0075] Risk threshold calculation:

[0076] Transaction frequency threshold T: During the 7-day risk assessment period, the number of non-risk transactions for client A during the risk period were 2, 1, 3, 2, 1, 2, 2, with an average daily transaction frequency of ≈1.86; taking the 80th percentile, we get T=2.

[0077] Off-site user threshold S: Based on customer A's historical risk data, S=1 is set, which means that if an off-site user's transaction count exceeds 1 time in a single day, caution is required.

[0078] Transfer interval threshold D: Within the 7-day risk assessment period, the average daily time interval between adjacent transfers in the risk data is 60 minutes, so D=60 minutes is set.

[0079] Suspected risk screening: On May 20, 2024, Customer A had 3 pending requests during the risk period (0:00-9:00, 18:00-24:00) (the 1st, 3rd, and 4th transactions), ≥T=2; there were 3 instances of users outside the database (C004, C005, and C006), ≥S=1; the transfer interval between adjacent users outside the database was ≥D=60 minutes; therefore, the 1st, 3rd, and 4th transactions were marked as suspected risk data.

[0080] Step S3, the second risk assessment condition distinguishes between risky data and non-risky data:

[0081] Relevance of transfer time Client A's average daily total number of transactions during the 7-day risk assessment period = 1.86 transactions per day during risky periods + 5 transactions per day during non-risky periods ≈ 6.86 transactions, rounded to 7. The number of suspected risk requests during the risky periods on that day was 3. =3 / 7≈42.86%.

[0082] Co-occurrence correlation The codes to be tested in the suspected risk data are C004, C005, and C006, none of which are in the risk assessment code library, therefore Simu=100%.

[0083] Interval correlation The time intervals between adjacent suspected risk requests on the same day were 675 minutes and 95 minutes, respectively, with an average interval t1 = (675 + 95) / 2 = 385 minutes; the average daily transaction time interval t2 in the risk data within the risk assessment period was 60 minutes.

[0084] =[1-|385-60| / 60]×100%=[1-325 / 60]×100%≈-441.67%, because the correlation degree cannot be negative, and a negative correlation degree means no correlation. Revised to 0%.

[0085] Overall correlation calculation: Set weights α=0.3, β=0.4, γ=0.3 (summing up to 1); S=0.3×42.86%+0.4×100%+0.3×0%≈12.86%+40%+0%=52.86%; The second risk judgment condition is preset to 50%. Since S=52.86%≥50%, the first, third, and fourth transaction data are marked as risk data.

[0086] Step S4, optimize the acquisition of risk correlation:

[0087] During the optimization period, the number of times "the number of requests to be judged ≥ T=2" in the statistical risk data was T times = 8 times, and the number of times "the interval between adjacent external transfers ≥ D=60 minutes" was D times = 7 times; =8 / (8+7)=53.33%, =7 / (8+7)=46.67%.

[0088] Weight coefficient adjustment: After adjustment, α = 0.3 × 53.33% ≈ 16%, γ = 0.3 × 46.67% ≈ 14%, β = 1 - 16% - 14% = 70%; the adjusted weights still satisfy α + β + γ = 1, completing the optimization of the second risk judgment condition, and subsequent risk judgment can be based on the new weights.

[0089] Example 2: Figure 2 As shown, the present invention provides a customer identification and dynamic monitoring analysis system based on intelligent agents. The system includes a transaction data identification module, a suspected risk screening module, a risk data judgment module, and a judgment condition optimization module.

[0090] The transaction data recognition module is used to identify transaction data in a transfer request based on keywords.

[0091] The suspected risk screening module is used to set the first risk judgment condition and to screen the transaction data according to the first risk judgment condition to obtain suspected risk data.

[0092] The risk data determination module is used to set the second risk determination conditions and obtain the risk correlation between suspected risk data and transaction data to obtain risk data and non-risk data.

[0093] The judgment condition optimization module is used to optimize the acquisition of risk correlation based on risk data and the first risk judgment condition;

[0094] The transaction data identification module further includes a transaction data extraction unit and a customer code matching unit; the transaction data extraction unit is used to identify the transaction data in the transfer request based on keywords when the target customer initiates or receives the transfer request; the customer code matching unit is used to set an independent code for each customer and match the corresponding target customer based on the code.

[0095] The suspected risk screening module also includes a whitelist marking unit and a risk threshold setting unit. The whitelist marking unit is used to establish an coded whitelist. If the target customer and other customers are both in the coded whitelist, the transfer request is marked as a non-risk request; otherwise, the transfer request is marked as a request to be judged. The risk threshold setting unit is used to set the risk judgment period and judge the request to be judged as a suspected risk request or a non-risk request based on the transaction number threshold T, the off-database user threshold S, and the transfer interval threshold D.

[0096] The risk data determination module further includes a correlation calculation unit and a risk threshold determination unit; the correlation calculation unit is used to calculate the correlation of transfer time. Co-occurrence correlation Correlation with interval The risk threshold determination unit is used to preset a correlation threshold as a second risk judgment condition, and to determine whether a suspected risk request is a risk request or a non-risk request based on the second risk judgment condition.

[0097] The judgment condition optimization module further includes an optimization coefficient calculation unit and a weight coefficient adjustment unit; the optimization coefficient calculation unit is used to set the optimization period and obtain the number of requests to be judged in the risk data within the optimization period. The number of times ≥T The transfer time interval between adjacent transfer requests from users outside the database on the same day. The number of times ≥D ,according to and Calculate optimization coefficients and The weighting coefficient adjustment unit is used to adjust the weighting coefficients in the risk correlation calculation according to... and Adjust them separately.

[0098] The output of the transaction data identification module is connected to the input of the suspected risk screening module; the output of the suspected risk screening module is connected to the input of the risk data determination module; and the output of the risk data determination module is connected to the input of the judgment condition optimization module.

[0099] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. An agent-based customer identification and dynamic monitoring analysis method, characterized in that: The method comprises the following steps: Step S1, when the target customer initiates or receives a transfer request, identifying transaction data in the transfer request, the transaction data comprising transaction time, fund source and fund destination; Step S2, setting a first risk judgment condition, screening the transaction data according to the first risk judgment condition to obtain suspected risk data; Step S3, obtaining a risk correlation degree between the suspected risk data and the transaction data, setting a second risk judgment condition, and screening the risk correlation degree according to the second risk judgment condition to obtain risk data and non-risk data; Step S4, optimizing the obtaining of the risk correlation degree according to the risk data and the first risk judgment condition; The step S3 further comprises: Step S3-1, obtaining the daily average total transaction times of the target customer in the risk judgment period, the daily average total transaction times including the daily average transaction times of the target customer in the risk period and the daily average transaction times in the non-risk period in the risk judgment period; calculating the proportion of the number of times that the transfer request in the day is marked as a suspected risk request in the risk period in the daily average total transaction times as the transfer time correlation degree ; Step S3-2, obtain the code of other users in the suspected risk data, denoted as the to-be-inspected code; if the to-be-inspected code is in the risk judgment code library, obtain the fund source and fund destination in the risk data in the risk judgment period, count the total number of occurrences of all codes, calculate the proportion of the to-be-inspected code in the total number of occurrences, denoted as the co-occurrence correlation degree ; if the to-be-inspected code is not in the risk judgment code library, the co-occurrence correlation degree is denoted as 1; Step S3-3: If the number of suspected risk requests in a given day is greater than 1, calculate the average transaction time interval between adjacent suspected risk requests in that day, obtain the daily average transaction time interval for different transaction times in the risk data within the risk assessment period, and calculate the interval correlation. =[1-| - | / ]×100%, of which This represents the average time interval between adjacent suspected risk requests on the same day. The average daily trading time interval represents the different trading times within the risk assessment period. - |Represents taking - The absolute value of the calculation result; if the number of suspected risk requests that occurred on that day is equal to 1, then Recorded as 0; Step S3-4, calculating a risk correlation degree S between the suspected risk data and the transaction data according to the transfer time correlation degree, the co-occurrence correlation degree and the interval correlation degree S=α× +β× +γ× , wherein α, β and γ are corresponding weight coefficients, and the sum is equal to 1; a preset correlation degree threshold is taken as the second risk judgment condition, if the risk correlation degree S is greater than or equal to the second risk judgment condition, the corresponding suspected risk request is marked as a risk request, and the corresponding transaction data is marked as risk data; otherwise, the corresponding suspected risk request is marked as a non-risk request, and the corresponding transaction data is marked as non-risk data.

2. The agent-based customer identification and dynamic monitoring analysis method of claim 1, wherein: The step S1 further comprises: Each customer has an independent code; the transfer request comprises a risk request, a non-risk request and a to-be-judged request, the transaction data corresponding to the risk request being risk data, the transaction data corresponding to the non-risk request being non-risk data, and the transaction data corresponding to the to-be-judged request being to-be-judged data; The preset keyword is used to identify the transaction data in the transfer request and match the corresponding target customer; the transaction data is structured data; when the target customer initiates the transfer request, the fund source is the target customer and the fund destination is another customer; when the target customer receives the transfer request, the fund source is another customer and the fund destination is the target customer.

3. The agent-based customer identification and dynamic monitoring analysis method of claim 2, wherein: The step S2 further comprises: Step S2-1, establishing a code whitelist, if the target customer and the other customer are both in the code whitelist, marking the transfer request as a non-risk request, otherwise marking the transfer request as a to-be-judged request; Step S2-2, setting a risk judgment period, obtaining the transaction time of the target customer in the non-risk data in the risk judgment period; dividing a day into a risk period and a non-risk period, according to the transaction time in the non-risk data, counting the daily average transaction times of the target customer in the risk period in the risk judgment period, and setting a preset percentage of the daily average transaction times in the risk period as a transaction times threshold T; Obtaining the fund source and the fund destination of the target customer in the non-risk data in the risk judgment period, extracting the codes of other users therefrom to form a risk judgment code library, regarding the codes not in the risk judgment code library as out-of-library users, and presetting an out-of-library user threshold S; Step S2-3, presetting a transfer interval threshold D; the first risk judgment condition comprises the transaction times threshold T, the out-of-library user threshold S and the transfer interval threshold D; Obtaining the number of times that the current-day transfer account request is marked as a request to be judged within a risk period , extracting the number of times that the current-day transfer account request appears in the out-of-bank user , calculating the transfer time interval between adjacent transfer account requests of the current-day out-of-bank user ; if ≥T, or ≥S, or ≥D, the corresponding transfer account request is marked as a suspected risk request, and the corresponding transaction data is marked as suspected risk data, otherwise the corresponding transfer account request is marked as a non-risk request, and the corresponding transaction data is marked as non-risk data.

4. The agent-based customer identification and dynamic monitoring analysis method of claim 3, wherein: The step S4 further comprises: Setting optimization period, obtaining risk data in optimization period ≥T times , ≥D times , calculating optimization coefficient and wherein = / ( + ), = / ( + ); the weight coefficients in risk correlation degree calculation are respectively adjusted to =α× , =γ× , =1-( + ); wherein , , are the adjusted weight coefficients α, β and γ respectively.

5. A system for intelligent agent-based customer identification and dynamic supervision analysis, applied to the method for intelligent agent-based customer identification and dynamic supervision analysis according to any one of claims 1-4, characterized in that: The system comprises a transaction data identification module, a suspected risk screening module, a risk data judgment module and a judgment condition optimization module; the transaction data identification module is used to identify the transaction data in the transfer request according to the keyword; the suspected risk screening module is used to set a first risk judgment condition and screen the transaction data according to the first risk judgment condition to obtain suspected risk data; The risk data judgment module is used to set a second risk judgment condition and obtain a risk correlation degree between the suspected risk data and the transaction data to obtain risk data and non-risk data; The judgment condition optimization module is configured to optimize the acquisition of the risk correlation degree according to the risk data and the first risk judgment condition; An output end of the transaction data identification module is connected to an input end of the suspected risk screening module; an output end of the suspected risk screening module is connected to an input end of the risk data judgment module; and an output end of the risk data judgment module is connected to an input end of the judgment condition optimization module.

6. The agent-based customer identification and dynamic monitoring analysis system of claim 5, wherein: The transaction data identification module further comprises a transaction data extraction unit and a customer code matching unit; the transaction data extraction unit is configured to identify transaction data in a transfer request according to a keyword when a target customer initiates or receives the transfer request; and the customer code matching unit is configured to set an independent code for each customer and match the corresponding target customer according to the code.

7. The agent-based customer identification and dynamic monitoring analysis system of claim 5, wherein: The suspected risk screening module further comprises a white list marking unit and a risk threshold setting unit; the white list marking unit is configured to establish a code white list; if the target customer and other customers are both in the code white list, the transfer request is marked as a non-risk request; otherwise, the transfer request is marked as a to-be-judged request; and the risk threshold setting unit is configured to set a risk judgment period and judge whether the to-be-judged request is a suspected risk request or a non-risk request according to a transaction frequency threshold T, an out-of-bank user threshold S and a transfer interval threshold D.

8. The agent-based customer identification and dynamic monitoring analysis system of claim 5, wherein: The risk data determination module further comprises a correlation degree calculation unit and a risk threshold determination unit; the correlation degree calculation unit is configured to calculate a transfer time correlation degree , a co-occurrence correlation degree , and an interval correlation degree , and calculate a risk correlation degree S between the suspected risk data and the transaction data; The risk threshold judgment unit is configured to preset a correlation degree threshold as a second risk judgment condition and judge whether the suspected risk request is a risk request or a non-risk request according to the second risk judgment condition.

9. The agent-based customer identification and dynamic monitoring analysis system of claim 5, wherein: The judgment condition optimization module further comprises an optimization coefficient calculation unit and a weight coefficient adjustment unit; The optimization coefficient calculation unit is configured to set an optimization period, acquire a number of times of the to-be-judged request in risk data in the optimization period The number of times of T The transfer time interval between the adjacent transfer requests of the off-site user appearing in the day The number of times of D According to And Calculate the optimization coefficient And The weight coefficient adjustment unit is configured to adjust the weight coefficient in the risk correlation degree calculation according to And Respectively.

Images