Anti-money laundering submission form generation method and related device
By generating anti-money laundering reporting forms through nested traversal structures and recursive association techniques, the problem of rigid form generation logic in existing technologies is solved, achieving efficient and accurate form generation and a user-friendly experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-10
- Publication Date
- 2026-04-07
AI Technical Summary
The existing anti-money laundering reporting form generation logic is rigid and makes it difficult to effectively organize complex business information, resulting in unclear form logic structure and poor user experience.
An anti-money laundering reporting form is set up using a nested traversal structure. The composite field type and its associated subfields are recursively associated through a tree-like recursive method to generate a nested anti-money laundering reporting form. The corresponding form components are set according to the field type to realize recursive association filling and data verification.
It improves form generation efficiency, generates more accurate forms, and enhances the user experience.
Smart Images
Figure CN121807906A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of financial data, and in particular to a method and related apparatus for generating anti-money laundering reporting forms. Background Technology
[0002] With increasingly stringent financial regulations, compliance reporting in the anti-money laundering field has become increasingly burdensome and complex for financial institutions and enterprises. Currently, anti-money laundering reporting typically relies on various electronic forms, which need to cover a large number of variable business data items to meet the reporting requirements under different regulatory scenarios.
[0003] In existing technical implementations, the generation logic of anti-money laundering reporting forms is often quite rigid. A common practice is for the front-end page to request a predefined data structure from the back-end based on a fixed business type, and then render a static form accordingly. In this approach, the form's fields, layout, and validation rules are usually hard-coded in the front-end code. Furthermore, because anti-money laundering operations involve various heterogeneous data such as customer information, transaction records, and risk ratings, and their field attributes (such as text, numbers, dates, and options) are complex and diverse, generating reporting forms using existing methods is slow. Traditional flat form structures struggle to effectively organize this type of hierarchical and interconnected business information, resulting in unclear form logic and a poor user experience. Summary of the Invention
[0004] To address the aforementioned technical problems, this application provides a method and related apparatus for generating anti-money laundering reporting forms.
[0005] The first aspect of this application provides a method for generating an anti-money laundering reporting form, including: Obtain the user's data entry request on the anti-money laundering reporting page; Based on the filling request, obtain configuration information related to the anti-money laundering reporting business from the backend. The configuration information includes field types of different attributes. The field types of the configuration information are set up using a nested traversal structure according to a preset method; Generate a nested anti-money laundering reporting form based on the set field types.
[0006] Optionally, the field types of the different attributes include basic field types and composite field types.
[0007] Optionally, the nested traversal structure setting of the field types of the configuration information according to a preset method includes: The composite field type and its associated subfields are recursively associated in a tree-like recursive manner. The composite field type is the upper-level field of the nested anti-money laundering reporting form to be generated, and its associated subfields are the lower-level fields.
[0008] Optionally, setting recursive associations for fields of composite field type and their associated subfields in a tree-like recursive manner includes: The hierarchy of the fields in the composite field type is determined based on the field ID of the composite field type; The IDs of the associated subfields and the hierarchy of the subfields are determined based on the field ID of the composite field type. The hierarchical relationships of the fields and subfields of the composite field type are set in a tree-like recursive manner.
[0009] Optionally, after generating the nested anti-money laundering reporting form based on the set field types, the method further includes: Set the corresponding form components according to the message requirements of different attribute field types; Display the nested anti-money laundering reporting form output after the form components are set.
[0010] Optionally, the method further includes: Obtain the user's input from the embedded anti-money laundering reporting form and perform recursive associative filling.
[0011] Optionally, the method further includes: When a user is detected entering a value on the embedded anti-money laundering reporting form, the entered value is validated according to data validation rules, which include the format and numerical range corresponding to all field types.
[0012] A second aspect of this application provides a system for generating anti-money laundering reporting forms, comprising: The acquisition unit is used to acquire users' data entry requests on the anti-money laundering reporting page; The acquisition unit is also used to acquire configuration information related to anti-money laundering reporting from the backend according to the filling request, the configuration information including field types of different attributes; The setting unit is used to set the nested traversal structure of the field types of the configuration information according to a preset method; The generation unit is used to generate nested anti-money laundering reporting forms based on the set field types.
[0013] A third aspect of this application provides an apparatus for generating anti-money laundering reporting forms, the system comprising: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to execute methods such as the first aspect and any of the optional methods of the first aspect.
[0014] A fourth aspect of this application provides a computer-readable storage medium on which a program is stored, and when the program is executed on a computer, it performs the method of the first aspect and any optional method of the first aspect.
[0015] As can be seen from the above technical solutions, this application has the following advantages: When a user enters the anti-money laundering reporting page to fill out a form, the system retrieves the user's request and then obtains the relevant configuration information for the anti-money laundering reporting business from the backend. This configuration information includes field types with different attributes, allowing the system to quickly identify the field types in the report content requested by the user. The system then sets a nested traversal structure for the field types in the configuration information according to a preset method, and finally generates a nested anti-money laundering reporting form based on the set field types. Because the anti-money laundering related field information is relatively fixed, the frontend can quickly execute the configuration as long as the traversal structure is set in advance, improving development efficiency. Furthermore, due to the nested settings of related field types, the generated reporting form is more accurate, improving the user experience. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 A schematic flowchart of an embodiment of the method for generating anti-money laundering reporting forms provided in this application; Figure 2 A flowchart illustrating an embodiment of the method for generating anti-money laundering reporting forms provided in this application, which involves setting a nested traversal structure for the field types of configuration information; Figure 3 A flowchart illustrating another embodiment of the method for generating anti-money laundering reporting forms provided in this application; Figure 4 A schematic diagram of an embodiment of the system for generating anti-money laundering reporting forms provided in this application; Figure 5 A schematic diagram of an embodiment of the apparatus for generating anti-money laundering reporting forms provided in this application. Detailed Implementation
[0018] This application provides a method for generating anti-money laundering reporting forms, which can improve form generation efficiency and enhance user experience.
[0019] It should be noted that the method and related apparatus for generating anti-money laundering reporting forms provided in this application can be applied to terminals, systems, and servers. For example, a terminal can be a smartphone, computer, tablet, smart TV, smartwatch, portable computer terminal, or a desktop computer, etc. For ease of explanation, this application uses a terminal as the executing entity for illustrative purposes.
[0020] Please see Figure 1 This application first provides an embodiment of a method for generating anti-money laundering reporting forms, which includes: S101. Obtain the user's data entry request on the anti-money laundering reporting page; When this method for generating anti-money laundering reporting forms is applied to the browser on the terminal, the user logs into the anti-money laundering system with their account and enters the reporting workbench. The workbench lists various report types that can be created. When the user clicks the "Create XX Form" button, the browser captures this click event, generates a "report request" with a report type identifier, and prepares to send it to the backend server.
[0021] Here, "reporting request" refers to an action triggered by a user on the front-end interface of the anti-money laundering system, indicating that the user intends to start creating a new form report, such as a "suspicious transaction report" or a "large transaction report".
[0022] It should be noted that if the user clicks on a form to modify an already generated anti-money laundering report, the front-end browser can directly retrieve the report from the back-end server for display and editing.
[0023] S102. Obtain configuration information related to the anti-money laundering reporting business from the backend based on the reporting request. The configuration information includes field types of different attributes. Field types are the basic units in configuration information, used to describe the attributes of a data item. They not only define the form of input controls displayed on the front end (such as text boxes and dropdown menus), but can also contain validation rules. For example, "Customer Name" is a text attribute field, and "Transaction Amount" is a numeric attribute field.
[0024] The frontend sends the data entry request (including the report type identifier) generated in step 101 to the backend server. Upon receiving the request, the backend server retrieves the corresponding form configuration information from the configuration database or configuration center based on the report type identifier. This form configuration information is a structured data set describing all the elements required to construct the entire form.
[0025] For example, the element content includes field 1 (report number), field 2 (merchant information), field 3 (transaction object information), field 4 (transaction information), etc.
[0026] Optionally, the field types for different attributes include basic field types and composite field types.
[0027] Basic field types are those that are not reusable or have no relation to other fields, such as indicator fields used only to display table area divisions, like "Basic Information Area" or "Specific Event Area". Composite field types, on the other hand, are those that can be reused or are related to other fields, such as "Merchant Information" being related to "Document Type, Document Number, Transaction Information", etc.
[0028] S103. Set the nested traversal structure of the field types of the configuration information according to the preset method; Setting up a nested traversal structure is a method of organizing data. Some fields in the configuration information are themselves containers that can contain a group of subfields. These subfields can then contain their own subfields, forming a tree-like or hierarchical parent-child relationship. Traversal refers to the process by which the system parses and renders each field layer by layer according to this hierarchical relationship.
[0029] In this embodiment, after receiving the configuration information returned by the backend, the frontend needs to parse it and construct a clear, nested tree structure with parent-child relationships according to a preset method. This process is called "nested traversal structure setting". The system will start from the root node, identify which fields are container fields (such as "transaction information" and "counterpartner information"), and then include their child fields inside them. For example, the parent field is set to "merchant information", and "document type and document number" are set as child fields of this parent field.
[0030] It should be noted that the preset method for setting nested traversal structures for field types can be stored in the front end or the back end. When the front end needs to set nested traversal structures using this preset method, it is then called from the back end.
[0031] It should also be noted that this preset method is for setting a nested traversal structure for composite field types, while basic field types are set to empty or not set.
[0032] It should also be noted that the nested traversal structure illustrated in this application is a tree-like recursive method. In practical applications, other recursive methods can also be used to implement traversal, such as loop recursion, conditional recursion, etc. This application does not limit the specific methods used.
[0033] S104. Generate a nested anti-money laundering reporting form based on the set field types.
[0034] Once the nested traversal structure is set up, the user interface is rendered. During rendering, the entire structure is traversed. Taking a tree structure as an example, for each "leaf node" (i.e., the final data field), a corresponding HTML input control is generated based on its "field type." For each "branch node" (i.e., container field), a corresponding UI container is generated, such as a field grouping panel or a collapsible card area. Especially for structures marked as "repeatable" (such as a "transaction information list"), an "Add Entry" button is rendered, allowing users to dynamically add multiple sets of transaction information. Finally, an editable anti-money laundering reporting form is generated and displayed.
[0035] In this application, when a user enters the anti-money laundering reporting page to fill out a form, the system obtains the user's reporting request and then retrieves the relevant configuration information for the anti-money laundering reporting business from the backend based on the request. This configuration information includes field types with different attributes, allowing for quick identification of the field types in the report content required by the user. The system then sets a nested traversal structure for the field types in the configuration information according to a preset method, and finally generates a nested anti-money laundering reporting form based on the set field types. Because the anti-money laundering related field information is relatively fixed, the frontend can quickly execute the configuration as long as the traversal structure is set first, improving development efficiency. Furthermore, due to the nested setting of related field types, the generated reporting form is more accurate, improving the user experience.
[0036] The following section provides a detailed explanation of how to set up a nested traversal structure for the field types of configuration information according to a preset method. Please refer to [link / reference]. Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of setting a nested traversal structure for field types in configuration information. In this embodiment, a recursive association is set for fields of composite field types and their associated subfields in a tree-like recursive manner. The fields of the composite field type are the upper-level fields of the nested anti-money laundering reporting form to be generated, and their associated subfields are the lower-level fields. Specifically, it includes: S201. Determine the hierarchy of fields in a composite field type based on the field ID of the composite field type; After obtaining the configuration information from the backend, the frontend first determines the level of the composite field type that needs to be recursively associated in the final tree structure.
[0037] Taking a tree-like hierarchical structure as an example, the front-end first identifies the root node, then traverses the entire configuration list, searching for all fields without a parent field. These fields are determined to be level 1, and they are usually the top-level parts or groups of the form. For example, "Report Summary Information" and "Transaction Information List" might be two parallel level 1 composite fields.
[0038] Determining the hierarchy of a composite field: When processing a specific composite field (such as "transaction object information"), the system locates it in the configuration list by its field ID. Then, by querying the field's parent_id attribute and tracing back through its parent field's parent field until a root node of level 1 is found, the system calculates its absolute hierarchy.
[0039] S202. Determine the ID of the associated subfield and the hierarchy of the subfield based on the field ID of the composite field type; After determining the hierarchy of a composite field (parent field), it is necessary to identify all the "child fields" directly governed by it.
[0040] The front-end uses the field ID of the current composite field as the query condition, traverses the entire configuration list, and searches for all fields whose parent field ID is equal to the current field ID. These found fields are the direct child fields of the composite field.
[0041] Furthermore, according to the hierarchy rules, the hierarchy of a child field is the hierarchy of its parent field plus one. For example, if the hierarchy of the parent field is 2, then the hierarchy of all its direct child fields is automatically determined to be 3.
[0042] S203. Set recursive associations for the hierarchy of fields and subfields of composite field types in a tree-like recursive manner.
[0043] After obtaining the IDs and levels of all composite fields and subfields through the above steps, the information can be integrated to construct a complete tree model. In this embodiment, a depth-first recursive algorithm is used for traversal and construction.
[0044] For example, a recursive function receives a field ID as input, assuming the field's hierarchy is known. The recursive function first creates a node in memory representing the current field, recording its field ID and hierarchy. Then, the recursive function calls the logic in step 202 to find all child fields of the current field. For each found child field, the function recursively calls itself, taking the child field's field ID and hierarchy (current hierarchy + 1) as new input parameters. This recursive call goes deeper into the next level, repeating the call to process the child field and its possible descendant fields. Finally, when the recursive processing of all child fields is complete (i.e., all branches have reached the leaf nodes and returned), the recursive function associates these child nodes with the current parent node and then returns to the previous level. In this way, a single recursive call starting from the root node eventually constructs a complete form structure tree containing all levels and relationships.
[0045] The following details the further processing performed in this application after generating a nested anti-money laundering reporting form based on the set field types, in conjunction with... Figure 1 and see Figure 3 , Figure 3 A flowchart illustrating another embodiment of a method for generating anti-money laundering reporting forms, the embodiment including: S301. Set the corresponding form components according to the message requirements of different attribute field types; Message requirements refer to the mandatory technical specifications that financial regulatory agencies establish for each data item when receiving anti-money laundering reports. These specifications define the data type, format, length, precision, and set of possible values (code tables), among other things. Form components must ensure that the input data conforms to these specifications to guarantee message compliance.
[0046] Form components are the basic elements on a user interface (UI) that interact with the user. Their type is determined by the "message requirements" of the field. For example, a field that requires a "date" input has a date picker as its component; a field that requires selection from a fixed code has a drop-down menu as its component.
[0047] In this embodiment, after constructing the nested structure tree, each "leaf node" (i.e., the basic field that ultimately requires user input) is traversed. Based on the "message requirements" defined for that field in the configuration information, a suitable UI component is assigned. The purpose is to internally maintain a mapping table of "message requirements - form components." This allows for component instantiation; that is, when traversing each field, the corresponding component type can be found in the mapping table based on its message requirements, and an instance of that component can be created at the appropriate location in the form.
[0048] S302. Output and display the nested anti-money laundering reporting form with form components set; After all fields have been assigned to their corresponding form components, the terminal... Figure 1 The nested tree structure constructed in step 103 of the embodiment renders components onto the browser page according to their hierarchical relationship. This includes: structural rendering, where composite fields are used as containers and rendered as group boxes, collapsible panels, or cards, with their child field components rendered inside these containers; and list rendering, where for composite fields marked as "reusable" (such as "transaction information list"), a "Add Item" button is rendered. When the user clicks this button, the entire component subtree under that composite field is dynamically copied, forming a new record.
[0049] The effect is that users no longer see a series of flat input boxes, but a clearly structured and hierarchical form. For example, "Main Information" is in a separate panel, while "Transaction Information" is a list of items that can be dynamically added and deleted. Each list item contains a complete transaction serial number, amount, and an embedded "Counterpartner Information" sub-panel.
[0050] S303. Obtain the user's input operation in the embedded anti-money laundering reporting form and perform recursive related filling; Recursive associative fill is an intelligent input assistance function based on the data relationships within a form. When a user enters a value in a field (source field), the system automatically detects other fields (target fields) associated with that field and automatically fills in or suggests values based on business rules. Because the form structure is nested, the process of finding associated fields needs to follow a recursive path in a tree structure.
[0051] Specifically, the process can be as follows: The front-end binds event listeners to form components. When a user completes input in a field, the associated data filling logic is triggered. First, source field identification is performed: the field ID and value of the currently entered field are obtained. Then, the associated target is recursively searched: based on preset association rules (e.g., "automatically fill in transaction time and amount when transaction serial number changes"), starting from the source field, a recursive traversal is performed throughout its nested subtree to find all associated target fields that need to be filled. Next, data is retrieved and filled: the system sends the value of the source field (e.g., serial number) to a dedicated backend data service interface. This interface returns associated data (e.g., transaction details). Finally, recursive assignment: after receiving the returned associated data, the target field path found recursively is followed again to automatically fill the data into the corresponding form component. This process may involve field updates within multiple nested structures.
[0052] S304. When it is detected that a user is entering a value on the embedded anti-money laundering reporting form, the entered value is validated according to the data validation rules, which include the format and value range corresponding to all field types.
[0053] It should be noted that data validation is performed in real time, typically triggered in the input or blur events of each field.
[0054] Data validation rules are a set of rules defined at the field level to check the validity of user input in real time. They are derived directly from "message requirements" to ensure that data meets the correctness of format and business logic before it enters the system.
[0055] For example: Based on the user's currently input field ID, load its corresponding data validation rules. These include: format validation: checking if the input conforms to a predefined format (e.g., regular expressions matching ID numbers, email addresses, etc.); range validation: checking if numbers are within the minimum / maximum range, and if dates are within a reasonable range; required field validation: checking if fields marked as required have been entered; and code validation: checking if the input value in a dropdown selection box is within a predefined code table.
[0056] Optionally, if validation fails, the front-end can immediately display a clear error message next to the field (e.g., "Please enter a valid ID number") and change the component style to an error state (e.g., with a red border). The "Submit" button will only become clickable after all fields in a form have passed validation.
[0057] The following provides a detailed description of the system for generating anti-money laundering reporting forms provided in this application. Please refer to [link / reference]. Figure 4 , Figure 4 A schematic diagram of an embodiment of the system for generating anti-money laundering reporting forms provided in this application, the system comprising: The acquisition unit 401 is used to acquire the user's data entry request on the anti-money laundering reporting page; The acquisition unit 401 is further configured to acquire configuration information related to anti-money laundering reporting from the backend according to the filling request, wherein the configuration information includes field types of different attributes; Setting unit 402 is used to set the nested traversal structure of the field types of the configuration information according to a preset method; Generation unit 403 is used to generate nested anti-money laundering reporting forms based on the set field types.
[0058] For a detailed implementation guide of this system, please refer to... Figures 1-3 The specific implementation examples are not described here.
[0059] This application also provides an apparatus for generating anti-money laundering reporting forms, participating in... Figure 5 As shown, the device includes: Processor 501, memory 502, input / output unit 503, and bus 504; The processor 501 is connected to the memory 502, the input / output unit 503 and the bus 504; The memory 502 stores a program, which the processor calls to execute the method for generating any of the above anti-money laundering reporting forms.
[0060] This application also relates to a computer-readable storage medium storing a program that, when run on a computer, causes the computer to execute any of the above-described methods for generating anti-money laundering reporting forms. For detailed embodiments, please refer to... Figures 1-3 The specific implementation examples are not described here.
[0061] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0062] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.
[0063] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0064] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.
[0065] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
Claims
1. A method for generating an anti-money laundering reporting form, characterized in that, include: Obtain the user's data entry request on the anti-money laundering reporting page; Based on the filling request, obtain configuration information related to the anti-money laundering reporting business from the backend. The configuration information includes field types of different attributes. The field types of the configuration information are set up using a nested traversal structure according to a preset method; Generate a nested anti-money laundering reporting form based on the set field types.
2. The method according to claim 1, characterized in that, The field types of the different attributes include basic field types and composite field types.
3. The method according to claim 2, characterized in that, The nested traversal structure setting of the field types of the configuration information according to a preset method includes: The composite field type and its associated subfields are recursively associated in a tree-like recursive manner. The composite field type is the upper-level field of the nested anti-money laundering reporting form to be generated, and its associated subfields are the lower-level fields.
4. The method according to claim 3, characterized in that, The method of setting recursive associations for composite field types and their associated subfields in a tree-like recursive manner includes: The hierarchy of the fields in the composite field type is determined based on the field ID of the composite field type; The IDs of the associated subfields and the hierarchy of the subfields are determined based on the field ID of the composite field type. The hierarchical relationships of the fields and subfields of the composite field type are set in a tree-like recursive manner.
5. The method according to any one of claims 1 to 4, characterized in that, After generating the nested anti-money laundering reporting form based on the set field types, the method further includes: Set the corresponding form components according to the message requirements of different attribute field types; Display the nested anti-money laundering reporting form output after the form components are set.
6. The method according to claim 5, characterized in that, The method further includes: Obtain the user's input from the embedded anti-money laundering reporting form and perform recursive associative filling.
7. The method according to claim 6, characterized in that, The method further includes: When a user is detected entering a value on the embedded anti-money laundering reporting form, the entered value is validated according to data validation rules, which include the format and numerical range corresponding to all field types.
8. A system for generating anti-money laundering reporting forms, characterized in that, include: The acquisition unit is used to acquire users' data entry requests on the anti-money laundering reporting page; The acquisition unit is further configured to acquire configuration information related to anti-money laundering reporting from the backend according to the filling request, wherein the configuration information includes field types of different attributes; The setting unit is used to set the nested traversal structure of the field types of the configuration information according to a preset method; The generation unit is used to generate nested anti-money laundering reporting forms based on the set field types.
9. An apparatus for generating anti-money laundering reporting forms, characterized in that, The system includes: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to execute the method as described in claims 1-7.
10. A computer-readable storage medium having a program stored thereon, the program performing the method as claimed in any one of claims 1 to 7 when executed on a computer.