A data processing method and apparatus for regulatory reporting

Abstract

This application provides a data processing method and apparatus for regulatory reporting, relating to the field of data processing technology. The method includes: parsing an acquired regulatory reporting requirement document to determine a set of requirement attributes, wherein the set of requirement attributes includes multiple requirement attributes; determining the source application system corresponding to each requirement attribute and obtaining a pre-established transaction log data table of the source application system, wherein the transaction log data table includes multiple transaction log records, and the transaction log data stores event numbers and multiple transaction attributes; performing an extraction operation on each source application system to obtain multiple regulatory reporting intermediate files; and summarizing the transaction attributes belonging to the same event number in each regulatory reporting intermediate file based on the event number to generate a regulatory reporting result file. This application can realize the correlation processing of data between different application systems on the same business chain, reduce the coupling of regulatory reporting business development, and shorten the regulatory reporting business launch cycle.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and can also be used in the financial field. Specifically, it relates to a data processing method and apparatus for regulatory reporting. Background Technology

[0002] The era of data-driven digital financial regulation has arrived. To further leverage the effective role of standardized regulatory data in preventing financial risks and promoting data governance and compliance development in banking institutions, regulatory agencies have raised higher requirements for the quality and refined management of regulatory reporting data provided to commercial banks. On the one hand, the reporting scope has shifted from statistical reporting to detailed reporting. On the other hand, the reported data information has expanded from single business data sources to reporting data from the entire business chain. Due to the long business process chains in the banking industry, the large amount of data generated, coupled with the differences in data records across application systems within the same chain, the design complexity and processing difficulty of the reported data have been greatly increased. Currently, commercial banks, based on regulatory reporting requirements, first define the relevant reporting application systems and the scope of relevant reporting data. When processing data based on the scope of reporting data, two methods are typically used:

[0003] Method 1: Reporting is completed by adding redundant storage to the data table of one application system to store the data information of another application system. However, if one party changes its data standards, the application system storing the redundant storage needs to adjust accordingly, increasing the coupling between applications in the development process. Method 2: Reporting is completed by establishing primary key relationships between the data tables of each application system. Due to the differences in the information recorded by different application systems, the relationship rules of the data tables reported by the relevant application systems need to be confirmed one by one. There is a lack of common language between application systems, resulting in high communication costs and an inability to quickly respond to the reporting needs of regulatory agencies. Summary of the Invention

[0004] To address the problems existing in the prior art, this application provides a data processing method and apparatus for regulatory reporting, which reduces the coupling of regulatory reporting business development and shortens the regulatory reporting business launch cycle.

[0005] According to a first aspect of this application, a data processing method for regulatory reporting is provided, the method comprising:

[0006] The obtained regulatory reporting requirement documents are parsed to determine the set of requirement attributes, wherein the set of requirement attributes includes multiple requirement attributes;

[0007] Identify the source application system corresponding to each requirement attribute, and obtain the pre-established transaction log data table of the source application system, wherein the transaction log data table includes multiple transaction log data, and the transaction log data stores event numbers and multiple transaction attributes;

[0008] An extraction operation is performed on each source application system to obtain multiple regulatory reporting intermediate files; wherein, the extraction operation includes: in each transaction log data, in response to the existence of a transaction attribute that matches the required attribute, extracting the event number of the transaction log data and the matching transaction attribute to generate a regulatory reporting intermediate file corresponding to each source application system;

[0009] Based on the event number, the transaction attributes belonging to the same event number in various regulatory reporting intermediate files are summarized to generate a regulatory reporting result file.

[0010] In some optional embodiments of this example, the step of establishing the transaction log data table includes:

[0011] Based on the received transaction request, determine the business scenario of the transaction request;

[0012] Based on the pre-set call chain, determine the front-end application system and back-end application system of the business scenario;

[0013] In response to the execution of the transaction request, the front-end application system initiates a service request to the back-end application system, generates an event number corresponding to the transaction request, and sends the event number to the back-end application system, wherein the event number remains unchanged during the transmission between the back-end application systems;

[0014] Using the event number as the primary key, the transaction log data generated by the front-end application system and the back-end application system are stored respectively to obtain the transaction log data table corresponding to each application system.

[0015] In some optional embodiments of this example, generating the event number corresponding to the transaction request includes:

[0016] The business source, transaction channel, transaction region, transaction time, and front-end application system of the transaction request are determined, and the sequence number and check digit of the transaction request are generated.

[0017] Based on the business source, transaction channel, transaction region, transaction time, and front-end application system, determine the head office and branch business identifier, channel code, region code, Julian date, and application system identifier respectively;

[0018] Based on the head office / branch business identifier, channel code, region code, Julian date, application system identifier, serial number, and check digit, generate the event number corresponding to the transaction request.

[0019] In some optional embodiments of this example, the step of determining the application system identifier includes:

[0020] In response to the front-end application system's request for an application system identifier, the channel code corresponding to the front-end application system is determined;

[0021] Under this channel code, an application system identifier is generated based on the current serial number's occupancy status to ensure that the application system identifier is unique under this channel code.

[0022] In some optional embodiments of this example, generating the intermediate regulatory reporting files corresponding to each source application system includes:

[0023] After extracting the event number and matching transaction attributes from each transaction log data, transaction log extraction data is generated, wherein the transaction log extraction data includes the event number and the matching transaction attributes;

[0024] All transaction log data is extracted and aggregated to generate intermediate regulatory reporting files corresponding to the source application system.

[0025] In some optional embodiments of this example, the step of summarizing transaction attributes belonging to the same event number in various regulatory reporting intermediate files based on event number to generate a regulatory reporting result file includes:

[0026] In response to the determination that there are identical event numbers among the regulatory reporting intermediate files of each source application system, an aggregation operation is performed on the transaction attributes under each event number to obtain multiple transaction log summary data, and the multiple transaction log summary data is used as the regulatory reporting result file;

[0027] The aggregation operation includes: aggregating transaction attributes belonging to the same event number into a single transaction log summary data, wherein the transaction attributes of the transaction log summary data cover the set of required attributes.

[0028] According to a second aspect of this application, a data processing apparatus for regulatory reporting is also provided, the apparatus comprising:

[0029] The requirement parsing module is configured to parse the obtained regulatory reporting requirement documents and determine the requirement attribute set, wherein the requirement attribute set includes multiple requirement attributes.

[0030] The source application system determination module is configured to determine the source application system corresponding to each requirement attribute and obtain a pre-established transaction log data table of the source application system, wherein the transaction log data table includes multiple transaction log data entries, and the transaction log data stores event numbers and multiple transaction attributes;

[0031] The regulatory reporting intermediate document generation module is configured to perform the following operations for each source application system: in each transaction log data, in response to the existence of a transaction attribute that matches the required attribute, extract the event number and the matching transaction attribute of the transaction log data to generate the regulatory reporting intermediate document corresponding to each source application system;

[0032] The regulatory reporting result file generation module is configured to aggregate transaction attributes belonging to the same event number from various regulatory reporting intermediate files based on the event number, and generate a regulatory reporting result file.

[0033] According to a third aspect of this application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the data processing method for regulatory reporting.

[0034] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the data processing method for regulatory reporting.

[0035] According to a fifth aspect of this application, a computer program product is also provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the data processing method for regulatory reporting.

[0036] This application provides a data processing method and apparatus for regulatory reporting, which realizes the correlation and processing of data between different application systems on the same business link based on the event number of the transaction log data stored in each application system, reduces the coupling of regulatory reporting business development, and shortens the regulatory reporting business launch cycle. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 This is a flowchart of a data processing method for regulatory reporting according to an embodiment of this application;

[0039] Figure 2 This is a schematic diagram of the source application system according to an embodiment of this application;

[0040] Figure 3This is a flowchart illustrating a method for obtaining a transaction log data record table according to an embodiment of this application.

[0041] Figure 4 This is a schematic diagram illustrating the transmission of event numbers between the front-end application system and the back-end application system according to an embodiment of this application;

[0042] Figure 5 This is a flowchart of a method for generating event numbers according to an embodiment of this application;

[0043] Figure 6 This is a flowchart of a method for determining an application system identifier according to an embodiment of this application;

[0044] Figure 7 This is a flowchart illustrating a method for generating intermediate regulatory reporting documents according to an embodiment of this application.

[0045] Figure 8 This is a schematic diagram of a data processing apparatus for regulatory reporting according to an embodiment of this application;

[0046] Figure 9 This is a block diagram of an electronic device used to implement a data processing method for regulatory reporting according to an embodiment of this application. Detailed Implementation

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

[0048] This application proposes a data processing method for regulatory reporting, such as... Figure 1 As shown, the method includes:

[0049] Step 101: Parse the obtained regulatory reporting requirement document to determine the requirement attribute set, wherein the requirement attribute set includes multiple requirement attributes;

[0050] Step 102: Determine the source application system corresponding to each requirement attribute, and obtain the pre-established transaction log data table of the source application system, wherein the transaction log data table includes multiple transaction log data, and the transaction log data stores event numbers and multiple transaction attributes;

[0051] Step 103: Perform an extraction operation on each source application system to obtain multiple regulatory reporting intermediate files; wherein, the extraction operation includes: in each transaction log data, in response to the existence of a transaction attribute that matches the required attribute, extracting the event number and the matching transaction attribute of the transaction log data to generate regulatory reporting intermediate files corresponding to each source application system;

[0052] Step 104: Based on the event number, summarize the transaction attributes belonging to the same event number in each regulatory reporting intermediate file and generate a regulatory reporting result file.

[0053] This application provides a data processing method for regulatory reporting, which, based on the event number of transaction log data stored in each application system, enables the correlation and processing of data between different application systems on the same business link, reduces the coupling of regulatory reporting business development, and shortens the regulatory reporting business launch cycle.

[0054] The following is about Figure 1 Each step is explained in detail:

[0055] Step 101: Parse the obtained regulatory reporting requirement document to determine the requirement attribute set, wherein the requirement attribute set includes multiple requirement attributes.

[0056] In this embodiment, the regulatory reporting requirement document issued by the regulatory agency is obtained. It should be understood that the regulatory reporting requirement document contains regulatory information from the regulatory agency regarding various business operations of the commercial bank. Furthermore, the obtained regulatory reporting requirement document is parsed to determine the set of requirement attributes. It should be understood that the set of requirement attributes includes multiple requirement attributes.

[0057] In one example, taking credit card repayment business as an example, the regulatory agency issues regulatory reporting requirement documents for this business to various commercial banks. The set of requirement attributes after parsing includes requirement attributes such as transaction card number, transaction amount, loan identifier, transaction date, transaction channel, transaction type, IP address, MAC address and counterparty information.

[0058] Step 102: Determine the source application system corresponding to each requirement attribute, and obtain the pre-established transaction log data table of the source application system. The transaction log data table includes multiple transaction log data entries, and the transaction log data stores event numbers and multiple transaction attributes.

[0059] After parsing the set of demand attributes, in this embodiment, it is also necessary to determine the source application system corresponding to each demand attribute. It should be understood that an application system is a set of business or technical functions implemented by technical means, serving a specific range of business or technical objectives. The transaction card number, transaction amount, and other attributes in the aforementioned example are generated by a specific application system when executing a transaction request. This is prior art, and this application will not elaborate on it further.

[0060] This allows us to identify the source application system corresponding to each requirement attribute, where the source application system can also serve as the data source for reporting. In one example, such as... Figure 2 As shown, the set of requirement attributes includes requirement attribute 1 to requirement attribute 5. It can be determined that the data source for reporting requirement attribute 1 to requirement attribute 2 is source application system 1; the data source for reporting requirement attribute 3 to requirement attribute 4 is source application system 2; and the data source for reporting requirement attribute 5 is source application system 3.

[0061] Furthermore, after identifying the source application system corresponding to each requirement attribute, it is also necessary to obtain the transaction log data table pre-established by the source application system. Taking the credit card application system as an example, as shown in Table 1 below, it is the transaction log data table of the credit card application system. It should be noted that this table is exemplary.

[0062] Table 1

[0063]

[0064] As shown in Table 1, the transaction log data table includes multiple transaction log data entries. The transaction log data stores different event numbers and multiple transaction attributes. For example, transaction attributes include credit card number, transaction amount, loan identifier, product agreement number, and transaction date. These attributes are all existing technologies and will not be described in detail in this application.

[0065] Each transaction in the application system should have a unique event identifier, namely the event number. Each event source can define itself and its mapping in messages, files, or databases as a specific rule string. An event is something that the bank wants to retain for the achievement of business objectives or the execution of business.

[0066] In some optional embodiments of this example, the method for establishing the transaction log data table as shown in Table 1 will be described, such as... Figure 3 As shown, it includes:

[0067] Step 301: Determine the business scenario of the received transaction request.

[0068] Step 302: Determine the front-end application system and back-end application system of the business scenario based on the pre-set call chain.

[0069] In this embodiment, it should be understood that each transaction request corresponds to a business scenario, such as a transfer, payment, or deposit transaction request, corresponding to the transfer business scenario, payment business scenario, and deposit business scenario, respectively. Furthermore, in these business scenarios, executing the transaction request obviously requires cooperation between various application systems. Therefore, based on the pre-set call chain, the front-end service and back-end service can be divided, that is, the front-end application system and back-end application system of the business scenario can be determined. Further, based on the service division result, the uploading, transmission, recording, and storage of event numbers in each application system end-to-end are clarified.

[0070] Step 303: In response to the execution of the transaction request, the front-end application system initiates a service request to the back-end application system, generates an event number corresponding to the transaction request, and sends the event number to the back-end application system, wherein the event number remains unchanged during the transmission between the back-end application systems.

[0071] Step 304: Using the event number as the primary key, store the transaction log data generated by the front-end application system and the back-end application system respectively to obtain the transaction log data table corresponding to each application system.

[0072] In this embodiment, during the execution of a transaction request, such as Figure 4 As shown, each time the front-end application system initiates a service request to the back-end application system, it generates an event number. The back-end service systems pass-through the event numbers, and these event numbers cannot be modified during transmission. Both the front-end and back-end application systems must record the event number and transaction details in their respective local transaction log data tables. Unlike existing technologies where transaction logs only have transaction attributes, this application adds an event number, which is stored as the primary key. Based on the aforementioned event number transmission method, the association between the transaction log data tables of the front-end and back-end application systems can be achieved.

[0073] It should be understood that under different transaction requests and business scenarios, the service division results will be different depending on the call chain. That is, different transaction requests will result in different front-end application systems and back-end application systems. A front-end application system can become a back-end application system in the next transaction request, and similarly, a back-end application system can become a front-end application system in the next transaction request.

[0074] In some optional embodiments of this example, such as Figure 5 As shown, the event number corresponding to this transaction request is generated, including:

[0075] Step 501: Determine the business source, transaction channel, transaction region, transaction time, and front-end application system of the transaction request, and generate the sequence number and check digit of the transaction request.

[0076] In this embodiment, the business sources include head office business and branch business; the transaction channel is the way that a bank or third-party institution wants to retain its information and directly or indirectly conduct product services, customer communication, marketing, and product sales, such as: counter channels, ATM channels, and third-party direct connection channels, where third-party direct connection channels include mobile payment; the transaction area is the geographical location where the transaction occurs; the transaction time is the time when the transaction request is executed; the front-end application system refers to the aforementioned example, and will not be described in detail here.

[0077] In addition, the sequence number of the transaction request follows the maximum business volume of the commercial bank's application system and is generated using the database SQEUENCE sequence, which must be unique within the same day; to prevent the event number from being tampered with, a check digit is set, which is calculated and generated based on the elements such as business source, transaction channel, transaction region, transaction time and front-end application system, according to a check algorithm such as 2121.

[0078] Step 502: Based on the business source, transaction channel, transaction region, transaction time, and front-end application system, determine the head office / branch business identifier, channel code, region code, Julian date, and application system identifier, respectively. In this embodiment:

[0079] The business source can be used to determine the head office and branch business identifiers. The head office and branch business identifiers are 1 bit. For example, when the business source is the head office, it is represented by "1" and when the business source is a branch, it is represented by "0".

[0080] The channel code can be determined based on the transaction channel, and its length and generation follow the commercial bank's own channel information management method. The area code can be determined based on the transaction region, and its length and generation follow the commercial bank's own area information management method. The Julian date is determined based on the transaction time, which is usually 4 digits and is calculated according to the timekeeping method for calculating time within the Julian cycle.

[0081] The application system identifier can be determined based on the channel code and the front-end application system. Specifically, its length follows the maximum number of application systems of a commercial bank and is uniformly allocated and managed based on the channel code (or transaction channel) to ensure uniqueness under that channel code.

[0082] In some optional embodiments of this example, such as Figure 6 As shown, the steps to determine the application system identifier include:

[0083] Step 601: In response to the application system's request for an application system identifier, determine the channel code corresponding to the front-end application system.

[0084] Step 602: Under this channel code, based on the current serial number's occupancy status, generate an application system identifier that is distinct from the current serial number to ensure that the application system identifier is unique under this channel code.

[0085] In one example, a commercial bank's metadata asset management system can be used to establish an application and allocation management mechanism for application system identifiers. Specifically, each application system development department, as the application department, completes the application serial number application through the data asset management system. The asset administrator completes the allocation of serial numbers based on the current serial number occupancy. If there is no relevant system, management and maintenance can also be carried out by manually creating a list to ensure the uniqueness of event numbers generated between different application systems. At the same time, attention should be paid to backing up relevant data assets.

[0086] Table 2 shows an example of the management structure of application system identifiers. As can be seen from Table 2, the application system identifier under each channel code (or transaction channel) is unique.

[0087] Table 2

[0088]

[0089] Step 503: Generate the event number corresponding to the transaction request based on the head office / branch business identifier, channel code, region code, Julian date, application system identifier, serial number, and check digit.

[0090] Having determined the head office and branch business identifiers, channel codes, region codes, Julian dates, application system identifiers, serial numbers, and check digits, a unified event numbering rule can be established across the entire bank by arranging these identifiers in a specific order. The event number can be entirely numeric, such as "00200360030100100000103", or entirely alphanumeric, or a combination of numbers and letters; this application does not impose any limitations on this. Furthermore, the order of the head office and branch business identifiers, channel codes, region codes, Julian dates, application system identifiers, serial numbers, and check digits is set according to actual circumstances; this application also does not impose any limitations on this, as long as it ensures that the event number is unique within a certain timeframe within the commercial bank system.

[0091] Step 103: Perform an extraction operation on each source application system to obtain multiple regulatory reporting intermediate files; wherein, the extraction operation includes: in each transaction log data, in response to the existence of a transaction attribute that matches the required attribute, extracting the event number of the transaction log data and the matching transaction attribute to generate a regulatory reporting intermediate file corresponding to each source application system.

[0092] In some optional embodiments of this example, such as Figure 7 As shown, intermediate regulatory reporting files are generated for each source application system, specifically including:

[0093] Step 701: After extracting the event number and the matching transaction attribute from each transaction log data, generate transaction log extraction data, wherein the transaction log extraction data includes the event number and the matching transaction attribute.

[0094] Step 702: Extract and summarize all transaction log data to generate an intermediate regulatory reporting file corresponding to the source application system.

[0095] In this embodiment, after determining the source application system and its corresponding transaction log data table, it is also necessary to extract the transaction log data table. Taking the aforementioned example where the required attribute set includes transaction card number, transaction amount, loan identifier, transaction date, transaction channel, transaction type, IP address, MAC address, and counterparty information, the extraction operation is explained based on Table 1:

[0096] As shown in Table 1, the transaction attributes include credit card number, transaction amount, loan identifier, product agreement number, and transaction date. Among them, the transaction attributes that match the requirements are credit card number, transaction amount, loan identifier, and transaction date. Therefore, the event number and matching transaction attributes of the transaction log data are extracted to obtain the regulatory reporting intermediate document shown in Table 3.

[0097] Table 3

[0098] Event Number Credit card number Transaction amount Loan Identifier Transaction date 00200360030100100000103 1202XXX13 5000 loan 2023.04.10 10200360030100100000104 1203XXX13 6000 borrow 2023.04.11 …… …… …… …… …… 00200360030100100000105 1204XXX13 8000 loan 2023.04.23

[0099] It should be understood that the aforementioned extraction operation can be performed on each source application system to obtain multiple regulatory reporting intermediate files as shown in Table 3.

[0100] Step 104: Based on the event number, summarize the transaction attributes belonging to the same event number in each regulatory reporting intermediate file and generate a regulatory reporting result file.

[0101] In this embodiment, the regulatory reporting requirements described above will still be used for explanation. The set of requirements attributes includes transaction card number, transaction amount, loan identifier, transaction date, transaction channel, transaction type, IP address, MAC address, and counterparty information. Among them, the source application system corresponding to the transaction card number, transaction amount, loan identifier, and transaction date is a credit card application, and its regulatory reporting intermediate documents are shown in Table 3.

[0102] The source application system corresponding to the transaction channel, transaction type, IP address, and MAC address is a personal online banking application. The regulatory reporting intermediate documents for the personal online banking application can also be obtained by following the method in the previous example, as shown in Table 4, which will not be described in detail here.

[0103] Table 4

[0104]

[0105] The source application system corresponding to the counterparty information is a personal account application. The regulatory reporting intermediate documents for the personal account application can also be obtained by following the method in the previous example, as shown in Table 5, which will not be described in detail here.

[0106] Table 5

[0107] Event Number Counterparty information 00200360030100100000103 58311XX2 10200360030100100000104 58321XX3 …… …… 00200360030100100000105 58331XX4

[0108] Furthermore, the transaction attributes belonging to the same event number in various regulatory reporting intermediate documents, such as Tables 3, 4, and 5, are summarized to generate a regulatory reporting result file.

[0109] In some optional embodiments of this example, in response to determining that there are identical event numbers among the regulatory reporting intermediate files of various source application systems, a summary operation is performed on the transaction attributes under each event number to obtain multiple transaction log summary data. These multiple transaction log summary data are then used as the regulatory reporting result file. The summary operation includes: summarizing transaction attributes belonging to the same event number into a single transaction log summary data. For example, for the same event number "00200360030100100000103" in Tables 3-5, summarizing the transaction attributes corresponding to this event number in Tables 3-5 yields a single transaction log summary data. The same summary operation is performed on other identical event numbers, ultimately resulting in the regulatory reporting result file shown in Table 6. Clearly, the transaction attributes of the transaction log summary data cover the required attribute set.

[0110] Table 6

[0111]

[0112] In this embodiment, relevant application data table information files are received according to regulatory reporting requirements, and relevant reporting data source association processing is completed based on event numbers to form regulatory reporting result files, thus completing the reporting process.

[0113] Under the trend of digital financial regulation and facing increasingly stringent and diverse regulatory requirements, the technical solution proposed in this application can help commercial banks further enrich the data processing methods of the regulatory reporting system, improve the standardization and refinement of their regulatory reporting services, reduce the processing costs and complexity of related data in the regulatory reporting system, effectively shorten the launch cycle of related businesses, and strengthen the external service capabilities of the regulatory reporting system. Furthermore, this method can also be applied to scenarios involving cross-system business data reconciliation within banks (such as accounting and partner reconciliation).

[0114] It should also be noted that the acquisition, storage, use and processing of data involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0115] Based on the same inventive concept, this application also provides a data processing apparatus for regulatory reporting, which can be used to implement the methods described in the above embodiments, as described in the following embodiments. Since the principle by which this data processing apparatus for regulatory reporting solves the problem is similar to that of the data processing method for regulatory reporting, the implementation of the data processing apparatus for regulatory reporting can refer to the implementation of the data processing method for regulatory reporting, and repeated details will not be elaborated further. As used below, the terms "unit" or "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the system described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0116] like Figure 8 As shown, the data processing device for regulatory reporting includes:

[0117] The requirement parsing module 801 is configured to parse the obtained regulatory reporting requirement document and determine the requirement attribute set, wherein the requirement attribute set includes multiple requirement attributes.

[0118] The source application system determination module 802 is configured to determine the source application system corresponding to each requirement attribute and obtain a pre-established transaction log data table of the source application system, wherein the transaction log data table includes multiple transaction log data, and the transaction log data stores an event number and multiple transaction attributes;

[0119] The regulatory reporting intermediate document generation module 803 is configured to perform the following operations for each source application system: in each transaction log data, in response to the existence of a transaction attribute that matches the required attribute, extract the event number and the matching transaction attribute of the transaction log data, and generate a regulatory reporting intermediate document corresponding to each source application system;

[0120] The regulatory reporting result file generation module 804 is configured to aggregate transaction attributes belonging to the same event number in various regulatory reporting intermediate files based on the event number, and generate a regulatory reporting result file.

[0121] In some optional embodiments of this example, the step of establishing the transaction log data table includes:

[0122] Based on the received transaction request, determine the business scenario of the transaction request;

[0123] Based on the pre-set call chain, determine the front-end application system and back-end application system of the business scenario;

[0124] In response to the execution of the transaction request, the front-end application system initiates a service request to the back-end application system, generates an event number corresponding to the transaction request, and sends the event number to the back-end application system, wherein the event number remains unchanged during the transmission between the back-end application systems;

[0125] Using the event number as the primary key, the transaction log data generated by the front-end application system and the back-end application system are stored respectively to obtain the transaction log data table corresponding to each application system.

[0126] In some optional embodiments of this example, generating the event number corresponding to the transaction request includes:

[0127] The business source, transaction channel, transaction region, transaction time, and front-end application system of the transaction request are determined, and the sequence number and check digit of the transaction request are generated.

[0128] Based on the business source, transaction channel, transaction region, transaction time, and front-end application system, determine the head office and branch business identifier, channel code, region code, Julian date, and application system identifier respectively;

[0129] Based on the head office / branch business identifier, channel code, region code, Julian date, application system identifier, serial number, and check digit, generate the event number corresponding to the transaction request.

[0130] In some optional embodiments of this example, the step of determining the application system identifier includes:

[0131] In response to the front-end application system's request for an application system identifier, the channel code corresponding to the front-end application system is determined;

[0132] Under this channel code, an application system identifier is generated based on the current serial number's occupancy status to ensure that the application system identifier is unique under this channel code.

[0133] In some optional embodiments of this example, the regulatory reporting intermediate document generation module is further configured as follows:

[0134] After extracting the event number and matching transaction attributes from each transaction log data, transaction log extraction data is generated, wherein the transaction log extraction data includes the event number and the matching transaction attributes;

[0135] All transaction log data is extracted and aggregated to generate intermediate regulatory reporting files corresponding to the source application system.

[0136] In some optional embodiments of this example, the regulatory reporting result file generation module is further configured as follows:

[0137] In response to the determination that there are identical event numbers among the regulatory reporting intermediate files of each source application system, an aggregation operation is performed on the transaction attributes under each event number to obtain multiple transaction log summary data, and the multiple transaction log summary data is used as the regulatory reporting result file;

[0138] The aggregation operation includes: aggregating transaction attributes belonging to the same event number into a single transaction log summary data, wherein the transaction attributes of the transaction log summary data cover the set of requirement attributes.

[0139] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0140] An electronic device 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, the instructions being executed by the at least one processor to enable the at least one processor to perform the steps of a data processing method for monitoring reporting according to the foregoing embodiments.

[0141] A non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause a computer to perform steps of a data processing method for monitoring reporting according to the foregoing embodiments.

[0142] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of a data processing method for regulatory reporting as described in the foregoing embodiments.

[0143] Figure 9 A schematic block diagram of an example electronic device 900 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0144] like Figure 9 As shown, device 900 includes a computing unit 901, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 902 or a computer program loaded from storage unit 908 into random access memory (RAM) 903. RAM 903 may also store various programs and data required for the operation of device 900. The computing unit 901, ROM 902, and RAM 903 are interconnected via bus 904. Input / output (I / O) interface 905 is also connected to bus 904.

[0145] Multiple components in device 900 are connected to I / O interface 905, including: input unit 906, such as keyboard, mouse, etc.; output unit 907, such as various types of monitors, speakers, etc.; storage unit 908, such as disk, optical disk, etc.; and communication unit 909, such as network card, modem, wireless transceiver, etc. Communication unit 909 allows device 900 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0146] The computing unit 901 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 901 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 901 performs the various methods and processes described above, such as a data processing method for regulatory reporting.

[0147] For example, in some embodiments, a data processing method for regulatory reporting can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 908. In some embodiments, part or all of the computer program can be loaded and / or installed on device 900 via ROM 902 and / or communication unit 909. When the computer program is loaded into RAM 903 and executed by computing unit 901, one or more steps of the data processing method for regulatory reporting described above can be performed. Alternatively, in other embodiments, computing unit 901 can be configured to perform a data processing method for regulatory reporting by any other suitable means (e.g., by means of firmware).

[0148] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0149] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0150] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0151] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0152] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0153] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0154] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this disclosure can be achieved, and this is not limited herein.

[0155] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A data processing method for regulatory reporting, characterized by, The method comprises the following steps: parsing the obtained regulatory reporting requirement document to determine a requirement attribute set, wherein the requirement attribute set comprises a plurality of requirement attributes; determining a source application system corresponding to each requirement attribute and obtaining a pre-established transaction log data table of the source application system, wherein the transaction log data table comprises a plurality of transaction log data, and the transaction log data stores an event number and a plurality of transaction attributes; performing an extraction operation on each source application system to obtain a plurality of regulatory reporting intermediate files; wherein the extraction operation comprises: in each transaction log data, in response to the presence of a transaction attribute matching the requirement attribute, extracting the event number and the matching transaction attribute of the transaction log data to generate a regulatory reporting intermediate file corresponding to each source application system; based on the event number, summarizing the transaction attributes belonging to the same event number in each regulatory reporting intermediate file to generate a regulatory reporting result file; The step of establishing the transaction log data table comprises: determining the business scenario of the transaction request according to the received transaction request; determining the front-end application system and the back-end application system of the business scenario according to the pre-set call link; in response to the execution of the transaction request, the front-end application system initiates a service request to the back-end application system, generates an event number corresponding to the transaction request, and sends the event number to the back-end application system, wherein the event number remains unchanged during the transmission between the back-end application systems; store the transaction log data generated in the front-end application system and the back-end application system respectively by taking the event number as the primary key, to obtain the transaction log data table corresponding to each application system.

2. The method of claim 1, wherein, The step of generating the event number corresponding to the transaction request comprises: determining the business source, transaction channel, transaction area, transaction time and front-end application system of the transaction request, and generating the serial number and check digit of the transaction request; determining the total and partial business flag, channel code, area number, Julian date and application system identifier according to the business source, transaction channel, transaction area, transaction time and front-end application system, respectively; generating the event number corresponding to the transaction request according to the total and partial business flag, channel code, area number, Julian date, application system identifier, serial number and check digit.

3. The method of claim 2, wherein, The step of determining the application system identifier comprises: in response to the front-end application system applying for allocation of an application system identifier, determining the channel code corresponding to the front-end application system; under the channel code, generating an application system identifier different from the current serial number according to the occupation situation of the current serial number, to ensure that the application system identifier is unique under the channel code.

4. The method of claim 1, wherein, The step of generating the regulatory reporting intermediate file corresponding to each source application system comprises: after extracting the event number and the matching transaction attribute from each transaction log data, generating transaction log extraction data, wherein the transaction log extraction data comprises the event number and the matching transaction attribute; summarizing all transaction log extraction data to generate a regulatory reporting intermediate file corresponding to the source application system.

5. The method of claim 1, wherein, The event number-based, the transaction attributes belonging to the same event number in each regulatory reporting intermediate file are summarized to generate a regulatory reporting result file, including: In response to determining that there are same event numbers between the regulatory reporting intermediate files of each source application system, performing a summary operation on the transaction attributes under each event number to obtain a plurality of transaction log summary data, and taking the plurality of transaction log summary data as the regulatory reporting result file; The summary operation includes: summarizing the transaction attributes belonging to the same event number into one transaction log summary data, wherein the transaction attributes of the transaction log summary data cover the demand attribute set.

6. A data processing apparatus for regulatory reporting, the data processing apparatus comprising: A data processing method for regulatory reporting for performing any one of claims 1 to 5, the device comprises: A demand analysis module configured to parse the obtained regulatory reporting demand file and determine a demand attribute set, wherein the demand attribute set includes a plurality of demand attributes; A source application system determination module configured to determine a source application system corresponding to each demand attribute and obtain a pre-established transaction log data table of the source application system, wherein the transaction log data table includes a plurality of transaction log data, and the transaction log data stores an event number and a plurality of transaction attributes; A regulatory reporting intermediate file generation module configured to perform the following operation on each source application system: in each transaction log data, in response to the presence of a transaction attribute matching the demand attribute, extracting the event number and the matching transaction attribute of the transaction log data to generate a regulatory reporting intermediate file corresponding to each source application system; A regulatory reporting result file generation module configured to summarize the transaction attributes belonging to the same event number in each regulatory reporting intermediate file based on the event number to generate a regulatory reporting result file.

7. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to realize the steps of the data processing method for regulatory reporting according to any one of claims 1 to 5.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that The computer program is executed by the processor to realize the steps of the data processing method for regulatory reporting according to any one of claims 1 to 5.

9. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instruction is executed by the processor to realize the steps of the data processing method for regulatory reporting according to any one of claims 1 to 5.

Images