Construction method, device, equipment and storage medium based on RPA automated robot platform

Abstract

The present application discloses a construction method, device, equipment and storage medium based on an RPA automated robot platform, and relates to the field of robotic process automation technology. The construction method based on the RPA automated robot platform includes: obtaining business process data, analyzing the business process data, identifying repetitive tasks and standardized tasks; writing target automation scripts according to the repetitive tasks, the standardized tasks and the RPA orchestrator; building a robot matrix according to the automation script; integrating the robot matrix with the business system through API and database connection through the RPA orchestrator, and embedding the RPA monitoring module into the business system to complete the construction of the automated robot platform. The present application can realize the comprehensive automation of business processes, improve efficiency and accuracy, reduce error rates, and ensure standardized execution of processes.

Description

Technical Field

[0001] The present application relates to the field of robotic process automation technology, and in particular to a construction method, device, equipment and storage medium based on an RPA automated robot platform. Background Art

[0002] With the advancement of informatization and digitalization, enterprises have built a large number of separate business systems according to the needs of different business processes, realizing the onlineization of business processes. Although this process has improved efficiency, it has also generated a large number of repetitive system operation processes that need to be performed manually, becoming mechanical low-value-added labor. In addition, a large number of business processes require cumbersome cross-system operations and form data islands. Enterprises have a growing demand for cross-system process connections and data integration.

[0003] Faced with the above problems, enterprises usually adopt business process outsourcing to reduce costs, but they still face the pressure of rising labor costs and the efficiency bottleneck of manual operations. Traditional IT solutions are for IT personnel to develop system interfaces or reconstruct systems to improve process efficiency, but they are often costly and have a long development cycle, making it difficult to respond to rapid changes in business needs in a timely manner.

[0004] Traditional manual operations and IT solutions are not only inefficient but also prone to errors when dealing with a large number of repetitive tasks, making it difficult to ensure data consistency and accuracy. At the same time, these methods have shown obvious shortcomings in dealing with the needs of rapid changes in business processes and cross-system operations, and cannot quickly adapt to the development needs of enterprises. Therefore, how to improve the efficiency and accuracy of business processes through automated robots has become an urgent problem to be solved.

[0005] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0006] The purpose of this application is to provide a construction method, device, equipment and storage medium based on the RPA automated robot platform, aiming to solve the technical problem of how to improve the efficiency and accuracy of business processes through automated robots.

[0007] To achieve the above objectives, the present application proposes a construction method based on an RPA automated robot platform, the method comprising:

[0008] Acquire business process data, and analyze the business process data to identify repetitive tasks and standardized tasks;

[0009] Writing a target automation script according to the repetitive tasks, the standardized tasks, and the RPA orchestrator;

[0010] constructing a robot matrix according to the automation script;

[0011] The robot matrix is ​​integrated with the business system through API and database connection through the RPA orchestrator, and the RPA monitoring module is embedded into the business system to complete the construction of the automated robot platform.

[0012] In one embodiment, the step of writing a target automation script according to the repetitive task, the standardized task, and the RPA orchestrator includes:

[0013] Determining automation requirements based on the repetitive tasks and the standardized tasks;

[0014] Designing an automated process based on the automation requirements and the RPA orchestrator, wherein the automated process includes a suspect payment stop process, a fund checking and control process, a task inspection process, and a data distribution process;

[0015] Compile a suspect payment stop script, a fund control script, a task inspection script, and a data distribution script according to the suspect payment stop process, the fund control process, the task inspection process, the data distribution process, and the RPA orchestrator;

[0016] The suspect payment stop script, the fund checking and controlling script, the task inspection script and the data distribution script are used as target automation scripts.

[0017] In one embodiment, the robot matrix includes a suspect payment stop robot, and after the steps of integrating the robot matrix with the business system through API and database connection through the RPA orchestrator, and embedding the RPA monitoring module into the business system, and completing the steps of building an automated robot platform, the following steps are further included:

[0018] Running the suspect payment stop robot through the RPA interpreter;

[0019] Determining the suspect account through the suspect stop payment robot;

[0020] Determining abnormal transactions in the suspect's account through the suspect's stop payment robot;

[0021] The abnormal transaction is terminated by the suspect stop payment robot.

[0022] In one embodiment, the step of determining the suspect account by the suspect stop payment robot includes:

[0023] In the suspect's stop payment robot, obtaining initial account data;

[0024] Cleaning and standardizing the account data to obtain target account data;

[0025] Extracting basic account information, transaction history, account balance, transaction frequency, account geographic location, historical abnormal behavior records, device information, and account type from the target account data as clustering features;

[0026] Determining a minimum number of neighbors and a neighborhood radius according to at least one of the clustering feature and the target account data;

[0027] Determine the number of accounts within the neighborhood radius of each account according to the distance matrix;

[0028] The target suspect account is determined according to the number of accounts, the minimum number of neighbors, and the neighborhood radius.

[0029] In one embodiment, the step of determining the target suspect account according to the number of accounts, the minimum number of neighbors, and the neighborhood radius includes:

[0030] Marking the accounts whose number of accounts is greater than or equal to the minimum number of neighbors as normal accounts;

[0031] Marking the account whose number of accounts is less than the minimum number of neighbors as an initial suspect account;

[0032] The accounts in the neighborhood radius of the initial suspect accounts that do not include the normal accounts are marked as target suspect accounts.

[0033] In one embodiment, the step of determining the minimum number of neighbors and the neighborhood radius according to at least one of the clustering feature and the target account data includes:

[0034] Determining a minimum number of neighbors according to the clustering characteristics;

[0035] Calculate the distance matrix between all accounts based on the target account data;

[0036] Draw a distance map according to the distance matrix;

[0037] The neighborhood radius is determined according to the inflection point on the distance graph.

[0038] In one embodiment, the step of determining abnormal transactions in the suspect's account by the suspect's stop payment robot includes:

[0039] In the suspect payment stop robot, initial transaction data is obtained, and the initial transaction data is normalized to obtain target transaction data;

[0040] Extracting transaction amount, transaction frequency, transaction time, transaction object, transaction location and account balance from the target transaction data as transaction features;

[0041] Determine a local density parameter and an abnormal factor threshold according to the target transaction data, and calculate a proximity distance between each transaction;

[0042] Determine a neighbor transaction set of each transaction in the target transaction data according to the local density parameter and the neighbor distance;

[0043] Calculate the reachable distance between each transaction and the corresponding neighbor transaction set;

[0044] Calculate the local reachable density according to the local density parameter and the reachable distance;

[0045] Calculating a local outlier value according to the local reachable density of each transaction and the local reachable density of each transaction in the corresponding neighboring transaction set;

[0046] Transactions in the target transaction data whose local abnormal value is greater than the abnormal factor threshold are marked as abnormal transactions.

[0047] In addition, to achieve the above objectives, the present application also proposes a construction device based on the RPA automated robot platform, the device comprising:

[0048] A task identification module, used to obtain business process data, analyze the business process data, and identify repetitive tasks and standardized tasks;

[0049] A script writing module, used for writing a target automation script according to the repetitive tasks, the standardized tasks and the RPA orchestrator;

[0050] A robot matrix construction module, used to construct a robot matrix according to the automation script;

[0051] The platform construction module is used to integrate the robot matrix with the business system through API and database through the RPA orchestrator, and embed the RPA monitoring module into the business system to complete the construction of the automated robot platform.

[0052] In addition, to achieve the above-mentioned objectives, the present application also proposes a construction device based on an RPA automated robot platform, the device comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the construction method based on the RPA automated robot platform as described above.

[0053] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the construction method based on the RPA automated robot platform as described above are implemented.

[0054] In addition, to achieve the above-mentioned objectives, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the construction method based on the RPA automated robot platform as described above.

[0055] One or more technical solutions proposed in this application have at least the following technical effects:

[0056] Obtain business process data, analyze the business process data, identify repetitive tasks and standardized tasks; write target automation scripts based on the repetitive tasks, the standardized tasks and the RPA orchestrator; build a robot matrix based on the automation script; integrate the robot matrix with the business system through API and database connection through the RPA orchestrator, and embed the RPA monitoring module into the business system to complete the construction of the automated robot platform. In the process of building the RPA automation platform, first, by acquiring and analyzing business process data, the RPA system can identify repetitive and standardized tasks. By integrating with existing business systems (such as ERP, CRM, financial systems, etc.), the RPA robot can automatically obtain relevant data, such as transaction records, customer information, order details, etc., to provide support for subsequent automation tasks. Using data mining technology, the system analyzes the execution rules, frequency and standardization of tasks, identifies processes and operations suitable for automation, thereby improving work efficiency and reducing human errors. Secondly, based on the identified repetitive tasks and standardized tasks, the RPA orchestrator will automatically generate or edit the target automation script. Through the orchestrator, users can design and adjust automated processes to ensure that tasks are executed according to predetermined rules, such as suspect payment suspension, fund control, task inspection, and data distribution. These scripts can ensure efficient and stable execution of business processes. The orchestrator can not only automatically generate simple repetitive task scripts, but also handle complex business rules to ensure that each task is executed according to standards, avoiding inconsistencies caused by manual intervention. Then, based on these automated scripts, the RPA system builds a robot matrix, which brings together a group of robots designed specifically to perform these automated tasks. These robots can perform tasks independently or coordinate and cooperate to complete more complex business processes. Through the robot matrix, enterprises can centrally manage the execution of all automated tasks and ensure that the execution of each task is automatically executed according to process sequence, input and output conditions, thereby improving enterprise operational efficiency. Finally, the RPA orchestrator integrates the robot matrix with the business system through API and database connection to ensure that the robot can seamlessly interact with the existing system and perform tasks. Through API integration, RPA robots can directly obtain data and perform operations from the company's financial system, customer relationship management system, etc.; through database connection, robots can process large amounts of data stored in the database, perform operations such as query, update, and analysis, thereby improving the efficiency and accuracy of data processing. At the same time, the RPA monitoring module embedded in the business system can monitor the robot's operating status in real time to ensure the smooth completion of tasks, and provide timely feedback on error information to help companies optimize automation processes. Through this series of steps, the RPA system can achieve comprehensive automation of business processes, improve efficiency and accuracy, reduce error rates, and ensure standardized execution of processes. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0058] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0059] Figure 1 A flowchart of the first embodiment of the construction method of the RPA automated robot platform provided in this application;

[0060] Figure 2 A schematic diagram of the robotic process automation system architecture provided in Example 1 of the construction method based on the RPA automated robot platform of this application;

[0061] Figure 3 A flowchart diagram of the second embodiment of the construction method of the present application based on the RPA automated robot platform;

[0062] Figure 4 This is a schematic diagram of the module structure of a construction device based on the RPA automated robot platform in an embodiment of the present application;

[0063] Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the construction method based on the RPA automated robot platform in the embodiment of the present application.

[0064] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0065] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0066] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0067] With the development of enterprise informatization and digitalization, although many business systems have been established to improve efficiency, a large number of repetitive and cross-system inefficient manual operations have also been generated, forming data islands. Although traditional solutions such as business process outsourcing and IT system development can partially alleviate the problem, they face limitations such as high costs and slow responses, making it difficult to meet rapidly changing business needs and ensure data consistency and accuracy.

[0068] The main solution of the embodiment of the present application is: using RPA automation robots, first identify repetitive and standardized tasks that can be automated by analyzing business process data, and integrate with existing systems (such as ERP, CRM) to obtain necessary data. Next, the RPA orchestrator generates or edits automation scripts, designs and adjusts processes to ensure that tasks such as suspect payment stop, fund control, etc. are performed according to rules. Then, a robot matrix is ​​built to perform these tasks, enabling independent or collaborative processing of complex processes. Finally, through API integration and database connection, the RPA robot interacts seamlessly with the business system to perform data operations, while the monitoring module tracks the operating status in real time to ensure that the task is completed efficiently and accurately.

[0069] It should be noted that the execution subject of the embodiment of the present application may be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a robotic process automation system, etc. The following takes the robotic process automation system as an example to illustrate this embodiment and the following embodiments.

[0070] Based on this, the present application embodiment provides a construction method based on the RPA automated robot platform, referring to Figure 1 , Figure 1 This is a flow chart of the first embodiment of the construction method of the RPA automated robot platform based on this application.

[0071] In this embodiment, the method for constructing an RPA automated robot platform includes steps S10 to S40:

[0072] Step S10, acquiring business process data, and analyzing the business process data to identify repetitive tasks and standardized tasks;

[0073] It should be noted that Robotic Process Automation (RPA) is a software technology that allows software robots to automatically perform repetitive tasks previously completed by humans. These tasks usually include data acquisition, form filling, file movement, etc. The core of RPA is to automate business processes by simulating human user operations on computers. Business process data in RPA refers to various data generated by enterprises during daily operations. These data may include transaction records, customer information, order details, etc. These data are the basis for RPA robots to perform automated tasks. Robots obtain these data to perform tasks such as data entry, processing and analysis. In this embodiment, business process data refers to data in existing business systems. These data are the basis for RPA robots to perform tasks. For example, suspect stop payment RPA needs to access and process data related to financial transactions, fund control RPA needs to process account and transaction records, task inspection RPA may need to monitor system status and log data, and data distribution RPA involves data collection and distribution. Repetitive tasks refer to those tasks that frequently occur in business processes and follow a fixed pattern, such as data entry, invoice processing, report generation, etc. These tasks often do not require complex judgments, but require a high degree of accuracy and consistency. In this embodiment, they include: Suspect stop payment: automatically monitor transactions, identify and stop suspicious transactions; Funds control: regularly check account activities to ensure fund security; Task inspection: regularly check system status to ensure that all services are operating normally; Data distribution: regularly collect data and distribute it to different business systems or departments. Standardized tasks refer to those tasks that have established clear operating rules and processes, such as compliance inspection, data verification, etc. The execution steps and standards of these tasks are usually pre-defined. RPA robots can automatically execute tasks according to these rules to ensure the consistency and compliance of the process. In this embodiment, they include: Suspect stop payment RPA: automatically execute stop payment operations according to preset rules; Funds control RPA: check fund flow according to compliance requirements to ensure that there are no illegal operations; Task inspection RPA: inspect system status according to a predetermined checklist; Data distribution RPA: distribute data accurately to designated systems or users according to data management policies.

[0074] It is understandable that, first, the robotic process automation system obtains business process data by integrating with existing business systems. This usually includes connecting to the company's ERP, CRM, financial systems, etc., through API interfaces, database queries, or directly grabbing relevant data from the system, such as transaction records, customer information, order details, etc. Then, the RPA system conducts in-depth analysis of the acquired data, using data mining and process analysis techniques, such as process mining (ProcessMining) tools, to identify key tasks in the process. This step involves classifying the data and identifying characteristics such as the execution frequency of tasks, the stability of steps, and the required processing time. Through statistical analysis of historical data, the RPA system can find out which tasks are recurring and have fixed rules, such as data entry, report generation, etc.; at the same time, the system will also check whether the tasks have clear execution standards, such as whether the approval process is fixed, whether there are predetermined rules for fund review, etc. Finally, the RPA system marks these repetitive and standardized tasks based on the analysis results, and prioritizes them according to their automation potential to ensure that the tasks most suitable for automation are executed first. Through this series of automated data acquisition and analysis processes, the RPA system can effectively identify and classify tasks that need to be automated, thereby providing an accurate basis for subsequent automation deployment, thereby achieving efficient business process optimization.

[0075] Step S20, writing a target automation script according to the repetitive tasks, the standardized tasks, and the RPA orchestrator;

[0076] It should be noted that the RPA orchestrator is a tool for centrally managing and controlling the execution of RPA robot tasks. It is not only used to coordinate and schedule the execution of tasks by robots, but also to write and generate automation scripts. Through the RPA orchestrator, users can design, edit and deploy automation processes through a graphical interface or script editor. These automation scripts define the execution steps of the robot, including the input, processing, and output of tasks. The RPA orchestrator allows business process automation scripts to be orchestrated into a series of operation instructions to automatically complete a series of tasks from data collection, processing to result output. Target automation scripts refer to scripts written and generated by the RPA orchestrator. These scripts describe the specific execution process of automation tasks. For example, it can instruct the robot how to interact with the application, how to crawl data, how to fill in forms, how to perform calculations or make decisions, etc. Target automation scripts are the core of converting business tasks into automation processes. Through clear process logic and operation steps, it enables robots to independently complete various tasks in business processes. Through the orchestrator, users can connect multiple tasks in series to form a complete automation process to ensure the automatic execution and accurate completion of each task.

[0077] It is understandable that, first, based on the identified repetitive tasks and standardized tasks, the RPA orchestrator will automatically generate or edit the target automation script according to the characteristics of the task. For repetitive tasks, the orchestrator will analyze the fixed processes and steps of these tasks and convert them into executable scripts, which usually include a series of simple, reusable operation instructions, such as data extraction, data entry, file operations, etc.; for standardized tasks, the orchestrator will write corresponding automation scripts according to the defined operation rules and process standards to ensure that each execution is strictly carried out in accordance with the preset rules. These automation scripts are implemented through the graphical interface or script editing tool of the RPA orchestrator, and can flexibly adjust the task logic, process sequence, input and output, etc. When writing scripts, the orchestrator will also consider the execution conditions, exception handling and process optimization of the task, so as to ensure the efficiency, accuracy and stability of the automation process. Finally, these scripts will be scheduled and automatically executed by the orchestrator to realize the automation of the entire business process.

[0078] As an example, the step of writing a target automation script based on the repetitive tasks, the standardized tasks and the RPA orchestrator includes: determining automation requirements based on the repetitive tasks and the standardized tasks; designing an automation process based on the automation requirements and the RPA orchestrator, the automation process including a suspect stop payment process, a fund check and control process, a task inspection process and a data distribution process; writing a suspect stop payment script, a fund check and control script, a task inspection script and a data distribution script based on the suspect stop payment process, the fund check and control process, the task inspection process, the data distribution process and the RPA orchestrator; and using the suspect stop payment script, the fund check and control script, the task inspection script and the data distribution script as the target automation script.

[0079] Automation requirements refer to the analysis and definition of automation requirements for identified repetitive and standardized tasks. It refers to which specific tasks or processes need to be completed through RPA automation, and what goals should be achieved by automating these tasks, such as improving efficiency, reducing manual errors, and ensuring consistency. Automation requirements are usually determined based on the nature of the task, execution frequency, rules, and standards. For example, automation requirements may include: automating a large number of repetitive data entry tasks, regularly monitoring system status, and processing capital flows according to preset rules. An automation process refers to a complete workflow designed based on automation requirements. It combines multiple tasks and operation steps into a coherent automated task flow. These processes define the execution order of tasks, input and output conditions, operation rules, and exception handling. Each automated process may involve different subtasks. The design of the automated process needs to ensure that each subtask can be seamlessly connected and meets the automation requirements. For example, when designing an automated process, considerations are given to how to extract information from the data source, how to make judgments based on rules, and how to perform related operations.

[0080] The suspect stop payment process is usually used to monitor financial transactions, identify suspicious transactions and execute stop payment operations. The process includes steps such as data collection, rule judgment, and stop payment operation. (1) Objective: Automatically monitor and identify suspicious financial transactions to prevent the outflow of funds from illegal or illegal transactions. (2) Specific content: a. Data collection: The process first collects all transaction data from relevant financial systems (such as bank trading platforms, payment systems, etc.), including transaction amount, transaction time, transaction parties and other information. b. Rule judgment: According to the preset rules (such as transaction amount exceeding the threshold, abnormal source, abnormal account behavior, etc.), determine whether there is a suspicious transaction. If the transaction meets the stop payment conditions, the stop payment operation is triggered. c. Stop payment operation: Automatically execute the stop payment operation to prevent further outflow of funds by freezing the relevant accounts or transactions. d. Notification and record: If the stop payment operation is successful, the system will automatically generate a log record and notify the relevant department for subsequent review or manual processing.

[0081] The fund control process involves regular review of account funds to ensure fund security and prevent non-compliant operations. The process includes steps such as checking account activities and verifying whether transactions are legal. (1) Objective: Regularly review account funds to ensure that all fund flows are legal and compliant and to prevent non-compliant activities such as money laundering and embezzlement. (2) Specific content: Account activity review: Regularly extract account transaction records from the financial system and review fund flows in the account. Rule verification: According to regulations or internal policies, check whether there are abnormal fund flows (such as large and frequent cross-border transfers) to ensure that all operations comply with regulations. Alert and report generation: If a transaction that does not comply with regulations is detected, the system automatically issues an alert and generates a report for subsequent processing. Compliance check: Ensure that all fund flows comply with regulatory requirements and generate compliance reports.

[0082] The task inspection process is used to regularly check the status of the system or platform to ensure its normal operation. This process usually includes system monitoring, log analysis, exception handling and other operations. (1) Objective: Regularly check the health of the system or platform to ensure the stable operation of the business system and promptly discover and solve potential problems. (2) Specific content: System monitoring: Automated tools regularly monitor the status of key components such as servers, applications, and networks to check whether there are any anomalies (such as downtime, excessive load, network interruption, etc.). Log analysis: The automated system analyzes various logs (such as operation logs, error logs, etc.) to identify potential system failures or security vulnerabilities. Health check: According to the preset checklist, check the key indicators of the system (such as CPU, memory usage, disk space, etc.) to ensure that the system is running normally. Report generation and notification: Generate an inspection report and automatically notify relevant personnel to handle if a problem is found.

[0083] The data distribution process refers to the periodic collection of data and its distribution to different business systems or departments. The process includes steps such as data extraction, conversion, transmission and reception. (1) Objective: Regularly collect and distribute data to relevant business departments or systems to ensure data fluidity and availability. (2) Specific content: Data collection: Collect relevant data from various business systems (such as customer management system, financial system, warehouse management system, etc.). These data may include order information, customer data, financial statements, etc. Data processing: Clean, format and convert the collected data to adapt to the needs of the target system or department. Data distribution: Distribute the processed data to the designated system, department or user as needed to ensure timely data delivery. Error handling and notification: If an error occurs during the data distribution process (such as data loss, format error, etc.), the system will automatically record and notify the relevant personnel to make corrections.

[0084] The suspect stop payment script is an automated script used to execute the suspect stop payment process. It contains instructions for steps such as transaction monitoring, identifying suspicious transactions, and stop payment operations, including: Transaction data capture: The script automatically extracts transaction data from the financial system to obtain detailed transaction records including transaction amount, time, account information, etc.; Rule determination: The script determines whether a transaction needs to be stopped based on preset rules (such as abnormal amounts, suspicious accounts, etc.); Stop payment operation: If the transaction meets the stop payment conditions, the script will automatically trigger the stop payment operation and freeze the relevant accounts or transactions; Log recording and notification: After the operation is completed, the script will automatically record the transaction and stop payment logs, and send the results to the relevant departments.

[0085] The funds checking and control script is a script used to automatically execute the funds checking and control process, including functions such as checking account activities, verifying fund flows, and triggering alarms, including: regular data extraction: the script regularly extracts account activity data from the financial system and organizes it; compliance verification: the script verifies the extracted data to determine whether there are any non-compliant or abnormal fund flows; alarm triggering and report generation: if any abnormal transactions are found, the script will automatically trigger an alarm and generate a detailed compliance report, which will be automatically sent to the compliance department.

[0086] The task inspection script is a script that implements the task inspection process, which automates the inspection of system status, log analysis, system operation health, etc., including system status check: the script regularly checks the health status of the system, such as the performance indicators of the server, network, and database; log analysis: the script automatically scans and analyzes log files to identify errors, abnormal events or potential risks; reporting and notification: the script will generate an inspection report and automatically notify relevant personnel when an abnormality is found.

[0087] The data distribution script is a script used to execute the data distribution process, automatically collecting, processing and distributing data to designated systems or departments, including: data extraction and conversion: the script extracts data from various business systems and performs format conversion, cleansing and other processing on the data; data transmission: the script transmits the cleaned data to the target system or department in the specified format and standards; error handling: if data distribution fails, the script will automatically record the error and notify relevant personnel to make corrections.

[0088] First, based on the identified repetitive and standardized tasks, the types of tasks that need to be automated are clarified, and the execution rules, frequency, and complexity of each task are analyzed to determine the automation requirements. This is done to ensure that automation can solve actual pain points, improve efficiency, and reduce human errors. Next, based on these requirements, the RPA orchestrator is used to design specific automation processes, which will include suspect payment suspension, fund control, task inspection, and data distribution, and set the execution order and conditional judgment according to the steps and rules of each task. The purpose of this step is to ensure that tasks can be automatically executed at different times and under different conditions through process design, while also avoiding the inconsistency caused by manual intervention. Then, according to the designed process, the corresponding automation scripts are written through the RPA orchestrator. These scripts specifically define how to obtain data, judge conditions, and perform corresponding operations in the system, such as payment suspension, fund flow review, and system status monitoring. The purpose of writing scripts is to convert each process into an operational automation instruction to ensure that tasks are executed as planned and improve execution efficiency. Finally, all the written scripts are used as target automation scripts, and are uniformly scheduled and managed through the RPA orchestrator to ensure that these scripts can be automatically executed according to the predetermined rules and timing. Through this approach, not only automation is achieved, but the execution of various tasks is also standardized and precise, thereby greatly improving the efficiency and consistency of business processes.

[0089] Please refer to Figure 2 , Figure 2 The schematic diagram of the robotic process automation system architecture provided in the first embodiment of the construction method of the RPA automated robot platform of this application shows a comprehensive robotic process automation (RPA) system architecture, which aims to improve the efficiency and accuracy of business processes through automation technology. In this architecture, "Shenzhu-RPA Orchestrator" is used as a writing tool to design and orchestrate automated processes, while "Lingbo-RPA Interpreter" is responsible for executing these orchestrated automated scripts. "An Xiaoyi-Robot Matrix" is the core of executing automated tasks, including suspect stop payment RPA, fund control RPA, task inspection RPA and data distribution RPA, etc. They interact with existing business systems through API integration and database connection to realize automatic data processing and automation of business processes. In addition, the RPA monitoring module is embedded in the business system, and the operating status of the RPA robot is monitored in real time through the "RPA operation and maintenance monitoring platform" to ensure the stability and reliability of the automated process. The entire system is closely linked with the existing business system through data interaction to form an efficient automated workflow, thereby improving enterprise operational efficiency, reducing human errors, and optimizing resource allocation.

[0090] Step S30, constructing a robot matrix according to the automation script;

[0091] It should be noted that in the construction of the RPA automation platform, the robot matrix refers to a group of RPA robots specially designed to perform various automation tasks.

[0092] It is understandable that, first, automation scripts are developed through the RPA orchestrator. These scripts define the specific tasks and operation processes that the robots need to perform. These scripts are customized according to business needs and data analysis results to ensure that they can efficiently complete tasks such as suspect payment suspension, fund control, task inspection and data distribution. Then, these scripts are converted into executable robot tasks using the RPA interpreter. These robots are given specific responsibilities and can run independently or work together to automate complex business processes. Finally, the built robots are integrated into the robot matrix, which serves as a centralized management platform responsible for scheduling and monitoring the execution of all RPA robots. Through this matrix, task coordination between robots and seamless integration with existing business systems can be ensured to achieve efficient flow and processing of data. Doing so enables enterprises to automate and optimize business processes, improve work efficiency, reduce human errors, and at the same time free up human resources so that employees can focus on more creative and strategic work. Through the centralized management and monitoring of the robot matrix, enterprises can also ensure the stability and reliability of automation processes and respond to changes in business needs in a timely manner.

[0093] Step S40, the robot matrix is ​​integrated with the business system through API and database connection through the RPA orchestrator, and the RPA monitoring module is embedded into the business system to complete the construction of the automated robot platform.

[0094] It should be noted that business systems refer to software systems used to handle daily business operations in enterprises, such as customer relationship management (CRM), enterprise resource planning (ERP), financial systems, human resource management systems, etc. These systems usually contain key business processes and data and are the core of enterprise operations. API (application programming interface) integration refers to the use of standardized interfaces to enable different software systems to communicate and exchange data with each other. In RPA, API integration allows RPA robots to interact with business systems. For example, through API calls, RPA robots can obtain data in business systems or perform specific operations in business systems. Database connection refers to the connection established between RPA robots and enterprise databases, allowing robots to read or write data directly from the database. This connection is usually implemented through database access interfaces, such as ODBC, JDBC, etc. Database connection enables RPA robots to process large amounts of data stored in the database and support more complex automation tasks. The RPA monitoring module is a component used to monitor and manage the operating status of the RPA robot. It is usually included in the RPA operation and maintenance monitoring platform and can monitor the execution of the robot in real time, including task progress, errors and exceptions. The monitoring module can also provide functions such as logging, performance analysis and report generation to help enterprises optimize automation processes and improve operational efficiency.

[0095] It is understandable that, first, multiple robots are formed into a robot matrix through the RPA orchestrator and integrated with the business system of the enterprise to ensure that the robots can interact seamlessly with each system. Through API integration, RPA robots can directly obtain business data from business systems (such as CRM, ERP, financial systems, etc.) or perform operations in the system. For example, the suspect stop payment robot connects to the financial system through API, obtains transaction data in real time, identifies suspicious transactions and triggers stop payment operations; the fund checking and control robot can connect to the bank system through API, regularly review the flow of account funds to ensure that there are no illegal operations. Then, through database connection, RPA robots can directly access the enterprise's database and perform more complex data processing tasks. For example, the data distribution robot can extract customer orders, financial records or inventory data from the database and distribute this data to different business systems or departments according to predetermined rules; the task inspection robot can access system logs or performance data through database connection, check the system operation status and discover potential problems in a timely manner. Through the connection with the database, these robots can directly process large amounts of data, perform tasks such as data query, update, and analysis, greatly improving the efficiency and accuracy of automation. Finally, the RPA monitoring module is embedded in the business system to monitor the robot's operating status in real time, ensure that there are no errors or exceptions in the robot's execution process, and provide logs, performance analysis and report generation in a timely manner to help optimize the automation process and ensure that various data processing tasks are completed smoothly. In this way, the automation platform can achieve efficient automation of tasks such as suspect payment suspension, fund control, task inspection and data distribution, and ensure the accuracy and consistency of data processing.

[0096] This embodiment provides a construction method based on an RPA automated robot platform, which obtains business process data, analyzes the business process data, identifies repetitive tasks and standardized tasks; writes a target automation script according to the repetitive tasks, the standardized tasks and the RPA orchestrator; constructs a robot matrix according to the automation script; integrates the robot matrix with the business system through API and database connection through the RPA orchestrator, and embeds the RPA monitoring module into the business system to complete the construction of the automated robot platform. In the process of building the RPA automated platform, first, by obtaining and analyzing business process data, the RPA system can identify repetitive and standardized tasks. By integrating with existing business systems (such as ERP, CRM, financial systems, etc.), the RPA robot can automatically obtain relevant data, such as transaction records, customer information, order details, etc., to provide support for subsequent automated tasks. Using data mining technology, the system analyzes the execution rules, frequency and standardization of tasks, identifies processes and operations suitable for automation, thereby improving work efficiency and reducing human errors. Secondly, based on the identified repetitive tasks and standardized tasks, the RPA orchestrator will automatically generate or edit the target automation script. Through the orchestrator, users can design and adjust automated processes to ensure that tasks are executed according to predetermined rules, such as suspect payment suspension, fund control, task inspection, and data distribution. These scripts can ensure efficient and stable execution of business processes. The orchestrator can not only automatically generate simple repetitive task scripts, but also handle complex business rules to ensure that each task is executed according to standards, avoiding inconsistencies caused by manual intervention. Then, based on these automated scripts, the RPA system builds a robot matrix, which brings together a group of robots designed specifically to perform these automated tasks. These robots can perform tasks independently or coordinate and cooperate to complete more complex business processes. Through the robot matrix, enterprises can centrally manage the execution of all automated tasks and ensure that the execution of each task is automatically executed according to process sequence, input and output conditions, thereby improving enterprise operational efficiency. Finally, the RPA orchestrator integrates the robot matrix with the business system through API and database connection to ensure that the robot can seamlessly interact with the existing system and perform tasks. Through API integration, RPA robots can directly obtain data and perform operations from the company's financial system, customer relationship management system, etc.; through database connection, robots can process large amounts of data stored in the database, perform operations such as query, update, and analysis, thereby improving the efficiency and accuracy of data processing. At the same time, the RPA monitoring module embedded in the business system can monitor the robot's operating status in real time to ensure the smooth completion of tasks, and provide timely feedback on error information to help companies optimize automation processes. Through this series of steps, the RPA system can achieve comprehensive automation of business processes, improve efficiency and accuracy, reduce error rates, and ensure standardized execution of processes.

[0097] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can refer to the above introduction, and will not be repeated later. Figure 3 , Figure 3 This is a flow chart of the second embodiment of the construction method based on the RPA automated robot platform of the present application. The robot matrix includes a suspect payment stop robot. After step S40 of the construction method based on the RPA automated robot platform, steps S50 to S80 are also included:

[0098] Step S50, running the suspect payment stop robot through the RPA interpreter;

[0099] It should be noted that the RPA interpreter refers to a software component that is responsible for converting the automation scripts generated by the RPA orchestrator into instructions that can be executed by the RPA robot. The RPA interpreter acts like a translator, which converts high-level business logic or scripts (usually defined through a graphical interface or script editor) into operation codes that can be executed by the machine. This means that when the automation scripts generated by the orchestrator (such as rules on how to monitor transactions, determine whether they are suspicious, etc.) are submitted to the RPA interpreter, the interpreter will interpret and execute these tasks according to the set rules. The core role of the interpreter is to pass task instructions to specific robots and control their execution process to ensure that the tasks are executed as planned. The suspect stop payment robot is an RPA robot specially designed to monitor and process financial transactions. Its main task is to automatically identify and stop suspicious transactions and prevent the outflow of funds from illegal or illegal transactions. Specifically, the suspect stop payment robot will obtain transaction data from relevant financial systems (such as bank trading platforms, payment systems, etc.), analyze whether the transaction complies with preset rules (for example, whether the transaction amount exceeds a certain threshold, whether the transaction comes from an abnormal area, whether there is suspicious activity in the account, etc.), and automatically trigger a stop payment operation when a suspicious transaction is found, freezing related accounts or transactions to prevent funds outflow.

[0100] It is understandable that, first, the Robotic Process Automation System (RPA System) uses the RPA orchestrator to design and generate an automated script based on business needs. The script clearly specifies the operation process of the suspect stop payment robot, including obtaining transaction data from the financial system, judging transactions by rules, and executing stop payment operations. Then, the RPA orchestrator converts these operation processes into instructions that the robot can execute, ensuring that each step of the operation meets business needs. Then, the RPA interpreter takes over these instructions and is responsible for translating the high-level scripts generated by the orchestrator into executable code for the robot, ensuring that the robot can understand and accurately execute tasks according to the preset rules. For example, the implementation of each step, such as transaction data capture, rule judgment, and stop payment operations, depends on the interpreter's accurate conversion of the script. Finally, the instructions processed by the interpreter are passed to the suspect stop payment robot, and the robot automatically performs tasks, including real-time monitoring of transactions, identifying anomalies, and automatically triggering stop payment measures. Through this process, the work of suspect stop payment is fully automated, which not only reduces manual intervention, but also improves the real-time, accuracy, and consistency of operations, significantly reduces compliance risks and manual operation errors, and improves the overall efficiency of business processes.

[0101] Step S60, determining the suspect account through the suspect stop payment robot;

[0102] It should be noted that suspect accounts refer to accounts that may be involved in illegal, abnormal or suspicious behavior during financial transactions or fund flows. Specifically, suspect accounts usually refer to accounts that need to be paid special attention and monitored because their transaction behavior, source of funds, destination of funds, transaction frequency and other characteristics conform to preset rules or algorithm models, and show abnormal or suspicious activity patterns. For example, suspect accounts may have the following characteristics: the transaction amount or frequency of the account exceeds the normal range, or there are frequent cross-border transfers; the source of the fund flow associated with the account is unknown, or it is related to known suspicious activities; the behavior of the account is consistent with the signs of financial crimes such as money laundering and fraud.

[0103] It is understandable that, firstly, the system connects with the financial system interface through the suspect stop payment robot to obtain account transaction data in real time, including information such as the amount, account, time and transaction type of each transaction. Secondly, the system uses the robot to screen according to the preset rules to determine whether there are abnormal transactions, such as transaction amounts exceeding the set threshold, frequent transactions, cross-border transfers, abnormal fund flows between accounts, etc. This rule is based on historical data analysis and industry standards to ensure that potential risks are captured as accurately as possible. Then, the system marks accounts that meet the suspicious transaction pattern as suspect accounts, and records these account information in the system log, generating a traceable report for subsequent manual verification. Finally, the system automatically triggers the stop payment operation through the robot according to the rules, freezes the funds of the relevant accounts through the financial system, prevents the continued outflow of suspicious funds, and promptly notifies the relevant departments for further investigation and processing. Through this series of automated operations, the system not only improves the screening efficiency and reduces the errors of manual intervention, but also responds to potential financial risks in real time, ensures the safety of funds and reduces the occurrence of financial crimes.

[0104] As an example, the step of determining the suspect account through the suspect stop payment robot includes: obtaining initial account data in the suspect stop payment robot; performing data cleaning and standardization on the account data to obtain target account data; extracting basic account information, transaction history records, account balance, transaction frequency, account geographic location, account historical abnormal behavior records, device information and account type from the target account data as clustering features; determining the minimum number of neighbors and the neighborhood radius based on the clustering features and at least one of the target account data; determining the number of accounts within the neighborhood radius of each account based on the distance matrix; and determining the target suspect account based on the number of accounts, the minimum number of neighbors and the neighborhood radius.

[0105] Initial account data refers to the original account information extracted from the financial system, usually including the basic information of the account, historical transaction records, etc., without any processing or cleaning. Data cleaning refers to the processing of incomplete, inaccurate, repeated or abnormal data in the initial account data to ensure the accuracy, completeness and consistency of the data, such as deleting or correcting duplicate data, filling missing values, correcting incorrect formats, etc. Standardization refers to converting account data into a unified format or scale for subsequent analysis, such as converting amounts in different units to the same monetary unit, unifying the date format, or normalizing numerical data (for example, converting account balances or transaction frequencies to a specific standard interval). Target account data refers to the set of account data after data cleaning and standardization, including all processed account information, which can be used for further analysis and processing. Basic account information refers to the basic information of the account, such as account ID, account opening time, account owner information, account status, etc. Transaction history refers to all historical transaction records of the account, usually including information such as transaction time, transaction amount, transaction object, transaction type, etc., which is used to analyze the transaction behavior and pattern of the account. Account balance refers to the total amount of funds in the current account, which is used to evaluate the fund flow of the account. Transaction frequency refers to the number of times an account conducts transactions within a certain period of time. Frequent transactions may indicate abnormal activity in the account. Account geographic location refers to the geographic location of the account when the transaction is conducted. It can be judged by IP address, GPS data, etc., and is used to detect whether the account frequently conducts transactions in different regions, which may be risky. Account historical abnormal behavior records refer to whether the account has ever had abnormal behavior in the past, including whether the account has been frozen, whether there have been abnormal fund transfers or suspicious operations, etc. Device information refers to the device information associated with account transactions, such as the device's IP address, device type (such as PC, mobile phone), device ID, etc., which is used to detect whether abnormal devices are involved in transactions. Account type refers to the classification of accounts, such as personal accounts, corporate accounts, trust accounts, etc. Different types of accounts may have different transaction patterns and risks. Clustering features refer to key data items used to perform cluster analysis on accounts (such as account balance, transaction frequency, account geographic location, etc.). These features can help robots distinguish between normal accounts and suspicious accounts. The minimum number of neighbors is a threshold defined in cluster analysis to determine whether an account is similar enough to other accounts. If the number of neighbors of an account is lower than the threshold, the account is considered a potential suspicious account. The neighborhood radius refers to the spatial range used to define the "neighbor" relationship in the clustering algorithm. Accounts that are closer are considered neighbors. This radius determines which accounts are considered similar accounts. The distance matrix is ​​a mathematical matrix in which each element represents the distance between two accounts (usually Euclidean distance or other distance measurement methods).For example, if there are multiple accounts, the clustering features of each account (such as account type, transaction history, etc.) will be mapped to a numerical vector, and each item in the distance matrix represents the similarity or difference between two accounts in the feature space. By calculating the distance between all accounts, a complete matrix is ​​formed for further analysis of the relationship between accounts. This embodiment uses the Euclidean distance formula to calculate the distance between accounts, and the formula is:

[0106]

[0107] Among them, d(A,B) represents the distance between point A and point B, x i Represents the coordinate value of point A in the i-th dimension, which may represent a certain feature of the account, such as transaction frequency, account balance, etc. i Represents the coordinate value of point B on the i-th dimension. Similarly, this may represent the corresponding feature of another account. n represents the total number of features or dimensions. In cluster analysis, each account may consist of multiple features, such as basic account information, transaction history, account balance, etc. n is the total number of these features.

[0108] The number of accounts refers to the number of accounts within the neighborhood radius of an account in cluster analysis, which is used to measure whether the account has similarities with other accounts. If the number of accounts in the neighborhood of an account is small, it may be considered an abnormal account. Target suspect accounts refer to those accounts that are ultimately determined to be suspicious accounts through cluster analysis and abnormal behavior identification. These accounts have certain risk characteristics and may be related to illegal activities or abnormal fund flows.

[0109] First, the system obtains initial account data through the suspect stop payment robot, including basic account information, transaction history, account balance, transaction frequency, etc. The purpose of this step is to collect as much account information as possible to ensure that there is sufficient data support for subsequent analysis. Secondly, the system uses the robot to clean the acquired account data and remove missing values, duplicate data or outliers, which can improve data quality and avoid inaccurate data affecting the analysis results. At the same time, the system uses the robot to standardize the data so that values ​​from different sources or units can be compared on the same scale, thereby ensuring the uniformity and operability of the data. Then, the system uses the robot to extract a series of clustering features from the standardized data, such as basic account information, transaction history, account balance, transaction frequency, etc. These features will be used to describe the behavior and characteristics of the account, and the clustering algorithm will be used to find the similarity between accounts. Then, based on these clustering features, the system uses the robot to calculate the minimum number of neighbors and neighborhood radius to determine which accounts are within the similarity range, so that abnormal behavior can be more accurately identified. Then, the system uses the robot to analyze the number of accounts within its neighborhood radius for each account based on the calculated distance matrix, and further determine which accounts have behavior patterns that are highly similar to other accounts. Finally, by integrating the information of the number of accounts, the minimum number of neighbors, and the neighborhood radius, the robot can identify target accounts similar to potential suspect accounts, thereby automatically identifying the suspect accounts and providing a basis for subsequent stop payment operations. This process not only improves the processing efficiency of the system, but also reduces human intervention, ensuring that data-driven judgments are more accurate and scientific.

[0110] As an example, the step of determining the target suspect account based on the number of accounts, the minimum number of neighbors and the neighborhood radius includes: marking the accounts whose number of accounts is greater than or equal to the minimum number of neighbors as normal accounts; marking the accounts whose number of accounts is less than the minimum number of neighbors as initial suspect accounts; and marking the accounts in the neighborhood radius of the initial suspect accounts that do not include the normal accounts as target suspect accounts.

[0111] Normal accounts are those accounts whose number of accounts within their neighborhood radius is greater than or equal to the minimum number of neighbors. In other words, normal accounts are those accounts with a sufficient number of similar accounts in cluster analysis, indicating that their behavior patterns are highly consistent with other accounts and conform to normal account behavior. Initial suspect accounts are those accounts whose number of accounts within their neighborhood radius is less than the minimum number of neighbors, which means that the behavior of these accounts is significantly different from that of other accounts, and therefore there may be abnormal risks. Finally, among the initial suspect accounts, if there are no normal accounts within the neighborhood radius of an account, it is further marked as a target suspect account, which is considered to be likely to involve higher risks and require further processing or monitoring.

[0112] First, the system will traverse all accounts and check the number of accounts within the neighborhood radius of each account. If the number of accounts in the neighborhood of an account is greater than or equal to the set minimum number of neighbors, it means that the behavior of the account is similar to that of most accounts and conforms to the normal pattern, so the account will be marked as a normal account. The purpose of this is to identify normal behavior patterns by comparing the number of accounts in the neighborhood and ensure that most accounts can be correctly classified. Secondly, the system will mark those accounts whose number of accounts in the neighborhood is less than the minimum number of neighbors as initial suspect accounts. These accounts have fewer accounts in the neighborhood and show different behavior patterns from most accounts. There may be abnormal situations or risks, so they are marked as suspect accounts. In this way, potential abnormal accounts can be screened out from a large number of accounts, narrowing the scope of further analysis. Finally, the system will further analyze all initial suspect accounts to see if there are any normal accounts in their neighborhood radius. If the neighborhood radius of an initial suspect account does not contain any normal accounts at all, it means that the behavior pattern of the account is completely inconsistent with that of a normal account and may be a high-risk account, so it is marked as a target suspect account. Through this screening step, the system can more accurately target high-risk accounts and ensure that appropriate review or stop payment measures are taken subsequently.

[0113] As an example, the step of determining the minimum number of neighbors and the neighborhood radius based on at least one of the clustering features and the target account data includes: determining the minimum number of neighbors based on the clustering features; calculating the distance matrix between all accounts based on the target account data; drawing a distance graph based on the distance matrix; and determining the neighborhood radius based on the inflection point on the distance graph.

[0114] A distance matrix is ​​a mathematical matrix in which each element represents the distance between two accounts (usually Euclidean distance or other distance measurement methods). For example, if there are multiple accounts, the clustering features of each account (such as account type, transaction history, etc.) will be mapped to a numerical vector, and each item in the distance matrix represents the similarity or difference between two accounts in the feature space. By calculating the distances between all accounts, a complete matrix is ​​formed for further analysis of the relationship between accounts. A distance graph is a conversion of the distance matrix into a graph, in which each account is regarded as a node in the graph, and the edges between the nodes represent the distance between the accounts. By converting the distance data in the matrix into a graphical representation, the system can more intuitively identify the relationship between accounts and draw the relative distance between each account. Usually, accounts with smaller distances will appear as nodes close to each other in the graph, while accounts with greater distances are distributed farther apart. An inflection point refers to a sharp turning point in the change of distance in the graph when drawing a distance graph, usually the "elbow" that appears in the distance graph. These inflection points represent a natural boundary of clustering features, indicating the turning point where the distance between accounts changes from being relatively close (indicating similar accounts) to rapidly increasing. By identifying the inflection points in the distance graph, the neighborhood radius can be effectively determined, which divides the accounts into closely connected groups and distant groups, which further helps determine whether the accounts belong to abnormal or suspicious categories.

[0115] First, the system determines a minimum number of neighbors based on clustering features (such as account transaction history, account type, geographic location, etc.), that is, it specifies how many other accounts an account must maintain a certain degree of similarity with in order to be considered a normal account. This step is to ensure that only sufficiently similar accounts can be classified into one category during cluster analysis to avoid over-division. Next, the system uses the data of the target account to calculate the distance matrix between all accounts, that is, to quantify the distance between each pair of accounts based on the differences between account features. The purpose of this process is to provide basic data for subsequent classification work and ensure that the relationship between accounts can be accurately represented in a numerical way. Then, the system draws a distance graph based on the calculated distance matrix, in which each account is connected by an edge, and the length of the edge reflects the distance between the accounts. By looking at the inflection points in this graph, that is, where the distance between accounts suddenly changes dramatically, the system can determine a reasonable neighborhood radius, that is, the maximum distance range that each account can accept during clustering, to ensure that only similar accounts are included. Finally, through these steps, the system can accurately classify which accounts have large deviations in similarity and may be abnormal accounts, thereby helping to identify potential suspect accounts and improve recognition accuracy.

[0116] Step S70, determining abnormal transactions in the suspect's account by the suspect's stop payment robot;

[0117] It should be noted that abnormal transactions refer to transactions that are significantly different from the account's historical transaction behavior or general transaction patterns. These transactions may be characterized by abnormal amounts, excessive frequency, irregular transaction times, accounts or devices involved as abnormal sources, or abnormal transaction locations, etc. Through these features, the system can identify potential fraud or illegal activities and help further confirm whether there are problems with suspected accounts.

[0118] It is understandable that, first, the system extracts transaction records from the target suspect's account through the suspect stop payment robot, and analyzes the amount, frequency, time, device information and other characteristics in these records. Secondly, by comparing with the historical transaction data of the account, it identifies abnormal transaction behaviors that do not conform to the regular transaction pattern, such as abnormally large amounts, excessively high frequencies, or transactions occurring during abnormal time periods. Finally, the system will mark these transactions as abnormal transactions through the robot, and further evaluate the risks of these transactions in order to decide whether to take stop payment measures, thereby reducing potential fraud risks or illegal transactions.

[0119] As an example, the step of determining abnormal transactions in the suspect's account through the suspect payment stop robot includes: in the suspect payment stop robot, obtaining initial transaction data, and normalizing the initial transaction data to obtain target transaction data; extracting transaction amount, transaction frequency, transaction time, transaction object, transaction location and account balance from the target transaction data as transaction features; determining local density parameters and abnormal factor thresholds according to the target transaction data, and calculating the proximity distance between each transaction; determining the neighboring transaction set of each transaction in the target transaction data according to the local density parameters and the proximity distance; calculating the reachable distance between each transaction and the corresponding neighboring transaction set; calculating the local reachable density according to the local density parameters and the reachable distance; calculating the local outlier value according to the local reachable density of each transaction and the local reachable density of each transaction in the corresponding neighboring transaction set; marking the transaction in the target transaction data whose local outlier value is greater than the abnormal factor threshold as an abnormal transaction.

[0120] Initial transaction data refers to the original transaction record data extracted from the target suspect's account, including information such as transaction amount, transaction time, and transaction object, and is a data set without any processing. Normalization refers to converting various data in the initial transaction data (such as amount, frequency, etc.) into a unified standard format so that the data can be compared within the same range to avoid deviations caused by different units or large data differences. For example, convert the amount into a standardized numerical range (such as between 0 and 1). Target transaction data refers to the standardized transaction data obtained after normalization. This data set can be directly used for further analysis and processing. Transaction amount refers to the specific amount value of each transaction. For example, one transaction may be 100 yuan, while another transaction may be 5,000 yuan. Transaction frequency refers to the number of times an account conducts transactions within a specific time period. A high frequency may mean abnormal behavior, especially when it is inconsistent with the account's regular behavior. Transaction time refers to the specific time when each transaction occurs. For example, an account conducts a large transaction at 10 pm, which is inconsistent with the time pattern of daily transactions and may be considered an abnormal transaction. The transaction object refers to the object or account involved in each transaction, usually the recipient of the transaction. For example, if account A transfers money to account B, account B is the object of the transaction. The transaction location refers to the geographical location where each transaction takes place or the place where the transaction takes place. If the geographical location of the account is inconsistent with the transaction location, it may be considered an abnormal behavior. For example, an account in Beijing suddenly conducts a transaction in New York. The account balance refers to the balance of the target account when the transaction is made. The behavior of conducting high-value transactions with a small balance may be considered abnormal. Transaction features refer to various indicators extracted from the target transaction data for analysis, such as transaction amount, transaction frequency, transaction time, transaction object, transaction location, account balance, etc. These features help determine whether the transaction is abnormal. Local density parameter: refers to a threshold set when calculating the density between transactions, usually about 10% of the sample size of the data set. It represents the number of neighboring transactions of a transaction in a specific area, which is used to evaluate the density of transactions. The anomaly factor threshold refers to a standard value set when evaluating whether a transaction is abnormal. If the local anomaly value of a transaction is greater than the threshold, the transaction is marked as abnormal. For example, if the anomaly factor threshold is set to 0.8, and the local anomaly value of a transaction is 0.9, then the transaction is considered an abnormal transaction. Neighborhood distance refers to a measure of the similarity between transactions, usually calculated based on the difference between features. Transactions with smaller distances are considered to be more similar in features, while transactions with larger distances are considered to be more different. For each transaction data point, calculate its k nearest neighbors, which involves distance calculation, usually using Euclidean distance:

[0121]

[0122] Where d represents the distance, x pm and xqm are the values ​​of transaction p and transaction q on the mth feature (such as transaction amount, transaction frequency, etc.).

[0123] The neighbor transaction set refers to the set of other transactions that are close to a transaction when calculating the outlier value of a transaction. The transactions in this set are similar to the target transaction in terms of characteristics and are used to help determine whether the target transaction is abnormal. The reachable distance refers to the distance from a transaction to other transactions in its neighbor transaction set. Transactions with a smaller reachable distance are more similar in characteristics, indicating that they belong to the same group; transactions with a larger reachable distance may be considered as abnormal transactions that are unrelated to other transactions. For point p and point q, the reachable distance of p is defined as:

[0124] Reachability Distance(p,q) = max(dist(p,q),k-distance(q))

[0125] Here, k-distance(q) is the kth nearest neighbor distance of point q.

[0126] The local reachability density refers to the density value of each transaction calculated based on the reachability distance, which is used to evaluate whether the transaction belongs to a part of the regular group. The higher the local reachability density of a transaction, the more normal its behavior is, and vice versa. The local reachability density of a point p is defined as:

[0127]

[0128] Among them, N k (p) is the set of k nearest neighbors of point p.

[0129] The local outlier refers to the degree of abnormality of each transaction relative to its neighboring transaction set, which is usually calculated by the local reachable density. If the local outlier is large, it means that the behavior of the transaction is very different from other transactions and is more likely to be an abnormal transaction. The calculation formula for the local outlier of point p is:

[0130]

[0131] Among them, N k (p) is the set of k nearest neighbors of point p, LRD(q) is the local reachability density of point q, and LRD(p) is the local reachability density of point p.

[0132] First, the system obtains the initial transaction data from the suspect's account through the suspect stop payment robot and normalizes the data. The purpose of normalization is to convert data of different dimensions into the same scale to avoid analytical deviations caused by differences in numerical values, so that subsequent calculations and comparisons can be more consistent. Secondly, multiple transaction features are extracted from the normalized target transaction data, such as transaction amount, transaction frequency, transaction time, transaction object, transaction location, and account balance. These features represent different aspects of the transaction and help distinguish normal transactions from abnormal transactions. Then, the local density parameter (usually about 10% of the sample size of the data set) and the anomaly factor threshold are set based on these features. The local density parameter is used to measure the density of each transaction with the surrounding transactions, and the anomaly factor threshold is used to determine which transactions behave unusually. Next, the proximity distance between each transaction is calculated to measure the similarity between transactions, and the neighboring transaction set of each transaction is determined by these distances. Based on these neighboring transactions, the reachable distance of each transaction is calculated, which is a measure of the proximity between a transaction and its neighboring transaction set. Then, combined with the local density parameter, the local reachable density of each transaction is calculated, which reflects the density of transactions in its neighboring area. According to the difference between the local reachable density of each transaction and the local reachable density of its neighboring transaction set, the local outlier is calculated to indicate the degree of abnormality of the transaction relative to its neighboring transactions. Finally, when the local outlier exceeds the preset anomaly factor threshold, the transaction is marked as an abnormal transaction, thereby identifying possible abnormal behaviors and providing a basis for subsequent stop payment operations.

[0133] Step S80, terminating the abnormal transaction through the suspect's stop payment robot.

[0134] It is understandable that, first, the RPA system determines the transactions that need to be terminated based on the abnormal transactions identified in the previous step through the suspect stop payment robot, and marks these abnormal transactions as pending items. Then, the system sends stop payment instructions to the business system through the interface with the bank or payment system. These instructions will immediately freeze the funds of the relevant accounts or suspend related transaction operations to prevent funds from continuing to flow to the suspected accounts or third-party accounts. Next, the system will record the relevant information of these transactions and generate a detailed stop payment operation report, including transaction amount, transaction object, account information, stop payment reason, etc., to ensure the transparency and traceability of the operation. Finally, the system will continue to monitor the subsequent transaction activities of the account to ensure that the stop payment measures are effective, and update the stop payment status in a timely manner to avoid the recurrence of abnormal transactions and ensure the safety of funds. In this way, the system can effectively curb potential illegal transactions and reduce financial risks.

[0135] In this embodiment, the suspect stop payment robot is run through the RPA interpreter; the suspect account is determined through the suspect stop payment robot; the abnormal transaction in the suspect account is determined through the suspect stop payment robot; and the abnormal transaction is terminated through the suspect stop payment robot. The RPA system first runs the suspect stop payment robot through the RPA interpreter, receives and executes the automation script designed by the orchestrator, so that the robot can complete a series of complex tasks, improves operational efficiency, and reduces manual intervention and errors. Next, the system analyzes account data through the suspect stop payment robot, automatically identifies and determines the suspect account, avoids the tedious process of manual review, and ensures accuracy and timeliness. Then, the transaction records in the suspect account are further analyzed, and abnormal transactions are quickly identified through automated analysis of transaction amounts, frequencies and other features, reducing errors and delays in manual judgment, and timely discovering potential risks. Finally, based on the identification of abnormal transactions, the RPA system automatically executes the stop payment operation, freezes related transactions or accounts, prevents funds from flowing to illegal channels, and effectively prevents financial losses. This process improves the efficiency and accuracy of risk prevention and control in a fully automated manner, reduces delays in manual operations, and ensures the security and controllability of the system.

[0136] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the construction method of the present application based on the RPA automated robot platform. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0137] This application also provides a construction device based on the RPA automated robot platform, please refer to Figure 4 , the construction device based on the RPA automated robot platform includes:

[0138] A task identification module 10 is used to obtain business process data, analyze the business process data, and identify repetitive tasks and standardized tasks;

[0139] A script writing module 20, used to write a target automation script according to the repetitive tasks, the standardized tasks and the RPA orchestrator;

[0140] A robot matrix construction module 30, for constructing a robot matrix according to the automation script;

[0141] The platform construction module 40 is used to integrate the robot matrix with the business system through the RPA orchestrator through API and database, and embed the RPA monitoring module into the business system to complete the construction of the automated robot platform.

[0142] In one embodiment, the script writing module 20 is also used to determine automation requirements based on the repetitive tasks and the standardized tasks; design an automation process based on the automation requirements and the RPA orchestrator, the automation process including a suspect stop payment process, a fund check and control process, a task inspection process and a data distribution process; write a suspect stop payment script, a fund check and control script, a task inspection script and a data distribution script based on the suspect stop payment process, the fund check and control process, the task inspection process, the data distribution process and the RPA orchestrator; and use the suspect stop payment script, the fund check and control script, the task inspection script and the data distribution script as target automation scripts.

[0143] In one embodiment, the platform construction module 40 is also used to run the suspect stop payment robot through the RPA interpreter; determine the suspect account through the suspect stop payment robot; determine the abnormal transaction in the suspect account through the suspect stop payment robot; and terminate the abnormal transaction through the suspect stop payment robot.

[0144] In one embodiment, the platform construction module 40 is also used to obtain initial account data in the suspect payment stop robot; perform data cleaning and standardization on the account data to obtain target account data; extract basic account information, transaction history, account balance, transaction frequency, account geographic location, account historical abnormal behavior records, device information and account type from the target account data as clustering features; determine the minimum number of neighbors and the neighborhood radius based on the clustering features and at least one of the target account data; determine the number of accounts within the neighborhood radius of each account based on the distance matrix; and determine the target suspect account based on the number of accounts, the minimum number of neighbors and the neighborhood radius.

[0145] In one embodiment, the platform construction module 40 is also used to mark the accounts whose number of accounts is greater than or equal to the minimum number of neighbors as normal accounts; mark the accounts whose number of accounts is less than the minimum number of neighbors as initial suspect accounts; and mark the accounts in the neighborhood radius of the initial suspect accounts that do not include the normal accounts as target suspect accounts.

[0146] In one embodiment, the platform construction module 40 is further used to determine the minimum number of neighbors based on the clustering characteristics; calculate the distance matrix between all accounts based on the target account data; draw a distance graph based on the distance matrix; and determine the neighborhood radius based on the inflection point on the distance graph.

[0147] In one embodiment, the platform construction module 40 is also used to obtain initial transaction data in the suspect payment stop robot, and normalize the initial transaction data to obtain target transaction data; extract transaction amount, transaction frequency, transaction time, transaction object, transaction location and account balance from the target transaction data as transaction features; determine local density parameters and abnormal factor thresholds based on the target transaction data, and calculate the proximity distance between each transaction; determine the neighboring transaction set of each transaction in the target transaction data based on the local density parameters and the proximity distance; calculate the reachable distance between each transaction and the corresponding neighboring transaction set; calculate the local reachable density based on the local density parameters and the reachable distance; calculate the local outlier value based on the local reachable density of each transaction and the local reachable density of each transaction in the corresponding neighboring transaction set; mark the transaction in the target transaction data whose local outlier value is greater than the abnormal factor threshold as an abnormal transaction.

[0148] The construction device based on the RPA automated robot platform provided in this application adopts the construction method based on the RPA automated robot platform in the above embodiment, which can solve the technical problem of how to improve the efficiency and accuracy of business processes through automated robots. Compared with the prior art, the beneficial effects of the construction device based on the RPA automated robot platform provided in this application are the same as the beneficial effects of the construction method based on the RPA automated robot platform provided in the above embodiment, and the other technical features in the construction device based on the RPA automated robot platform are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0149] The present application provides a construction device based on an RPA automated robot platform, and the construction device based on the RPA automated robot platform includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the construction method based on the RPA automated robot platform in the above-mentioned embodiment one.

[0150] Reference below Figure 5, which shows a schematic diagram of the structure of a construction device based on the RPA automated robot platform suitable for implementing the embodiment of the present application. The construction device based on the RPA automated robot platform in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 5 The construction device based on the RPA automated robot platform shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0151] like Figure 5 As shown, the construction device based on the RPA automated robot platform may include a processing device 1001 (such as a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM: Read Only Memory) 1002 or the program loaded from the storage device 1003 to the random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the construction device based on the RPA automated robot platform are also stored. The processing device 1001, ROM1002 and RAM1004 are connected to each other through a bus 1005. The input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the construction device based on the RPA automated robot platform to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a construction device based on the RPA automated robot platform with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have alternatively.

[0152] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0153] The construction device based on the RPA automated robot platform provided by this application adopts the construction method based on the RPA automated robot platform in the above embodiment, which can solve the technical problem of how to improve the efficiency and accuracy of business processes through automated robots. Compared with the prior art, the beneficial effects of the construction device based on the RPA automated robot platform provided by this application are the same as the beneficial effects of the construction method based on the RPA automated robot platform provided in the above embodiment, and the other technical features in the construction device based on the RPA automated robot platform are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0154] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0155] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0156] The present application provides a computer-readable storage medium having computer-readable program instructions (i.e., computer programs) stored thereon, and the computer-readable program instructions are used to execute the construction method based on the RPA automated robot platform in the above-mentioned embodiment.

[0157] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: Random Access Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0158] The above-mentioned computer-readable storage medium may be included in a construction device based on the RPA automated robot platform; or it may exist independently without being assembled into a construction device based on the RPA automated robot platform.

[0159] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by a construction device based on an RPA automated robot platform, the construction device based on the RPA automated robot platform: obtains business process data, analyzes the business process data, and identifies repetitive tasks and standardized tasks; writes target automation scripts according to the repetitive tasks, the standardized tasks and the RPA orchestrator; builds a robot matrix according to the automation script; integrates the robot matrix with the business system through the RPA orchestrator API and connects the database, and embeds the RPA monitoring module into the business system to complete the construction of the automated robot platform.

[0160] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through 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).

[0161] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that 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 a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0162] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0163] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned construction method based on the RPA automated robot platform, and can solve the technical problem of how to improve the efficiency and accuracy of business processes through automated robots. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the construction method based on the RPA automated robot platform provided in the above-mentioned embodiment, and will not be repeated here.

[0164] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the above-mentioned method for building a RPA automated robot platform.

[0165] The computer program product provided in this application can solve the technical problem of how to improve the efficiency and accuracy of business processes through automated robots. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the construction method based on the RPA automated robot platform provided in the above embodiment, which will not be repeated here.

[0166] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for constructing an RPA automated robot platform, characterized in that: The method comprises: Acquire business process data, and analyze the business process data to identify repetitive tasks and standardized tasks; Determining automation requirements based on the repetitive tasks and the standardized tasks; Designing an automated process according to the automation requirements and the RPA orchestrator, wherein the automated process includes a suspect payment stop process, a fund checking and control process, a task inspection process, and a data distribution process, and the RPA orchestrator designs, edits, and deploys the automated process through a graphical interface or a script editor; Compile a suspect payment stop script, a fund control script, a task inspection script, and a data distribution script according to the suspect payment stop process, the fund control process, the task inspection process, the data distribution process, and the RPA orchestrator; The suspect payment stop script, the fund checking and controlling script, the task inspection script and the data distribution script are used as target automation scripts; Building a robot matrix according to the target automation script, the robot matrix including suspect payment stop RPA, fund check and control RPA, task inspection RPA and data distribution RPA; The robot matrix is ​​integrated with the business system through API and database connection through the RPA orchestrator, and the RPA monitoring module is embedded into the business system to complete the construction of the automated robot platform; The method further comprises: Run the suspect stop payment robot through the RPA interpreter; Determining the suspect account through the suspect stop payment robot; Determining abnormal transactions in the suspect's account through the suspect's stop payment robot; terminating the abnormal transaction through the suspect's stop payment robot; The step of determining abnormal transactions in the suspect's account by the suspect's payment stop robot comprises: In the suspect payment stop robot, initial transaction data is obtained, and the initial transaction data is normalized to obtain target transaction data; Extracting transaction amount, transaction frequency, transaction time, transaction object, transaction location and account balance from the target transaction data as transaction features; Determine a local density parameter and an abnormal factor threshold according to the target transaction data, and calculate a proximity distance between each transaction; Determine a neighbor transaction set of each transaction in the target transaction data according to the local density parameter and the neighbor distance; Calculate the reachable distance between each transaction and the corresponding neighbor transaction set; Calculate the local reachable density according to the local density parameter and the reachable distance; Calculating a local outlier value according to the local reachable density of each transaction and the local reachable density of each transaction in the corresponding neighboring transaction set; Transactions in the target transaction data whose local abnormal value is greater than the abnormal factor threshold are marked as abnormal transactions.

2. The method according to claim 1, characterized in that The step of determining the suspect account by the suspect stop payment robot comprises: In the suspect's stop payment robot, obtaining initial account data; Cleaning and standardizing the account data to obtain target account data; Extracting basic account information, transaction history, account balance, transaction frequency, account geographic location, historical abnormal behavior records, device information, and account type from the target account data as clustering features; Determining a minimum number of neighbors and a neighborhood radius according to at least one of the clustering feature and the target account data; Determine the number of accounts within the neighborhood radius of each account according to the distance matrix; The target suspect account is determined according to the number of accounts, the minimum number of neighbors, and the neighborhood radius.

3. The method according to claim 2, characterized in that The step of determining the target suspect account according to the number of accounts, the minimum number of neighbors and the neighborhood radius comprises: Marking the accounts whose number of accounts is greater than or equal to the minimum number of neighbors as normal accounts; Marking the account whose number of accounts is less than the minimum number of neighbors as an initial suspect account; The accounts in the neighborhood radius of the initial suspect accounts that do not include the normal accounts are marked as target suspect accounts.

4. The method according to claim 2, characterized in that The step of determining the minimum number of neighbors and the neighborhood radius according to at least one of the clustering feature and the target account data comprises: Determining a minimum number of neighbors according to the clustering characteristics; Calculate the distance matrix between all accounts based on the target account data; Draw a distance map according to the distance matrix; The neighborhood radius is determined according to the inflection point on the distance graph.

5. A construction device based on the RPA automated robot platform, characterized in that: The device comprises: A task identification module, used to obtain business process data, analyze the business process data, and identify repetitive tasks and standardized tasks; A script writing module is used to determine automation requirements according to the repetitive tasks and the standardized tasks; design an automation process according to the automation requirements and the RPA orchestrator, the automation process includes a suspect stop payment process, a fund check and control process, a task inspection process and a data distribution process, and the RPA orchestrator designs, edits and deploys the automation process through a graphical interface or a script editor; write a suspect stop payment script, a fund check and control script, a task inspection script and a data distribution script according to the suspect stop payment process, the fund check and control process, the task inspection process, the data distribution process and the RPA orchestrator; use the suspect stop payment script, the fund check and control script, the task inspection script and the data distribution script as target automation scripts; A robot matrix construction module, used to construct a robot matrix according to the target automation script, wherein the robot matrix includes a suspect payment stop RPA, a fund check and control RPA, a task inspection RPA, and a data distribution RPA; A platform construction module, used to integrate the robot matrix with the business system through the RPA orchestrator through API and database, and embed the RPA monitoring module into the business system to complete the construction of the automated robot platform; The platform construction module is further used to run a suspect stop payment robot through an RPA interpreter; determine a suspect account through the suspect stop payment robot; determine abnormal transactions in the suspect account through the suspect stop payment robot; and terminate the abnormal transactions through the suspect stop payment robot; The platform construction module is also used to obtain initial transaction data in the suspect payment stop robot, and normalize the initial transaction data to obtain target transaction data; extract transaction amount, transaction frequency, transaction time, transaction object, transaction location and account balance from the target transaction data as transaction features; determine local density parameters and abnormal factor thresholds according to the target transaction data, and calculate the proximity distance between each transaction; determine the neighbor transaction set of each transaction in the target transaction data according to the local density parameters and the proximity distance; calculate the reachable distance between each transaction and the corresponding neighbor transaction set; calculate the local reachable density according to the local density parameters and the reachable distance; calculate the local outlier value according to the local reachable density of each transaction and the local reachable density of each transaction in the corresponding neighbor transaction set; mark the transaction whose local outlier value in the target transaction data is greater than the abnormal factor threshold as an abnormal transaction.

6. A construction device based on the RPA automated robot platform, characterized in that: The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the method for constructing an RPA automated robot platform as described in any one of claims 1 to 4.

7. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the method for building a RPA automated robot platform based on any one of claims 1 to 4 are implemented.

Images