Credit investigation business data management system
By generating a read-only authorization object with scenario anchor code and unique constraint parameters, and combining it with hash chain traceability records, the problem of decoupling authorization from usage scenarios is solved, and the complete execution of authorization constraints and third-party trusted verification are realized.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JIANGXI PUHUI CREDIT INFORMATION CO LTD
- Filing Date
- 2026-04-20
- Publication Date
- 2026-05-19
AI Technical Summary
The existing credit data management system cannot effectively bind authorization to usage scenarios, the authorization constraints lack uniqueness, and third parties cannot independently verify the compliance of data retrieval behavior.
By generating scenario anchor codes, unique constraint parameters, and read-only authorized objects, combined with hash chain traceability records, a strong binding between authorization and usage scenarios and trusted traceability verification are achieved.
Ensure that authorized use is consistent with business agreements at the technical level, prevent cross-scenario access, and provide independent and reliable verification results.
Smart Images
Figure CN122065332A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of credit data management and authorization verification technology, specifically a credit business data management system. Background Technology
[0002] With the widespread application of credit data in financial business, it is becoming increasingly common for companies to authorize financial institutions to access their credit data. Ensuring that data access is strictly limited to the authorized scope and is traceable is of great significance for the compliant management of credit data.
[0003] Existing credit data management systems typically only verify the legitimacy of the authorizing entity's identity, failing to establish a technical binding relationship between authorization and specific business scenarios. This allows data-retrieving agencies to use authorization for purposes outside the agreed-upon scenarios, making it difficult to effectively enforce authorization constraints at the technical level. Furthermore, the lack of uniqueness constraints on the source of authorization parameters in existing systems poses a risk of internal interpretations that expand or narrow the scope of authorization constraints. Regarding post-event verification, existing systems typically rely on internal logs for traceability records. Third parties cannot possess the original agreement content to independently verify the compliance of data retrieval activities, and the reliability of verification results is limited by the system's own reliability. These deficiencies make it difficult for existing credit data management systems to technically guarantee the complete execution of authorization constraints and the reliable verification of retrieval activities. Summary of the Invention
[0004] This invention provides a credit information business data management system that enables strong binding between authorization and usage scenarios, as well as credible traceability and verification of data retrieval behavior.
[0005] To achieve the above objectives, the present invention provides the following technical solution: The present invention provides a credit information business data management system, comprising: The protocol parsing module is used to extract the business type field and the applicant organization identifier from the business agreement content carried in the authorization application, generate a scenario anchor code that uniquely corresponds to the business agreement through hash operation, extract the contract validity period field, the licensed data range field and the licensed query count field from the business agreement content, derive the effective time window parameter, data range parameter and query count limit parameter respectively, and perform a hash operation on the business agreement content to generate a protocol text digest. The authorization object construction module is used to construct the scenario anchor code, effective time window parameters, data range parameters, query count limit parameters and the protocol text digest into an authorization object, which is persistently stored in read-only mode and does not provide a modification interface; The verification execution module is used to verify the consistency between the scenario declaration parameters carried in the request and the scenario anchor code in the authorized object when a data retrieval request is received, and to verify the compliance of the authorization status and data range in turn. After all the verifications are successful, the data retrieval is executed. The protocol anchoring traceability module is used to generate a traceability record containing the scenario anchoring code after data retrieval and execution, and store it in a hash chain manner, as well as to receive third-party verification requests and perform verification on the traceability record.
[0006] As a preferred embodiment of the present invention, in the protocol parsing module, the step of generating the scenario anchor code is as follows: The business type field and the applicant organization identifier are concatenated in a preset order, a hash operation is performed on the concatenation result, and the resulting hash value is used as the scenario anchor code.
[0007] As a preferred technical solution of the present invention, the effective time window parameter, data range parameter and query count limit parameter are respectively derived from the extraction results of the contract validity period field, the permitted data range field and the permitted query count field.
[0008] As a preferred embodiment of the present invention, in the authorized object construction module, the step of constructing the authorized object further includes: Determine whether the entity submitting the authorization application is the legal representative of the enterprise; If not, extract the authorization document identifier from the authorization application, concatenate the authorization document identifier with the applicant organization identifier, perform a hash operation, and generate the authorization anchor code; The delegate anchor code and the authorization level field are written together into the authorization object.
[0009] As a preferred embodiment of the present invention, the verification execution module further includes the following steps before performing the consistency verification: Read the authorization level field from the authorization object; When the authorization level field indicates that the authorization is directly granted by a non-legal representative, the request is rejected if the data retrieval request does not carry the authorization document identifier. Otherwise, the authorization document identifier is concatenated with the applicant organization identifier and a hash operation is performed. The resulting hash value is compared with the authorization anchor code stored in the authorization object. If they do not match, the request is rejected.
[0010] As a preferred embodiment of the present invention, in the verification execution module, the consistency verification steps include: Extract the scene declaration parameters carried in the data retrieval request; compare the scene declaration parameters with the scene anchor code in the authorized object; If the comparison is inconsistent, the data retrieval request is rejected, and a scenario discrepancy record is generated. The scenario discrepancy record includes the applicant organization identifier, scenario declaration parameters, scenario anchor code and request timestamp, and the scenario discrepancy record is associated with the authorized object and stored.
[0011] As a preferred embodiment of the present invention, in the verification execution module, the consistency verification further includes the following after generating the scenario deviation record: The scenario deviation records are stored in the scenario deviation log database and the scenario deviation count of the applicant institution is updated. Within a preset statistical period, when the scenario deviation count exceeds a preset threshold, the status of all authorized objects corresponding to the applicant organization is set to pending review, and a review notification containing the applicant organization's identifier and the corresponding scenario deviation record list is pushed to the system administrator.
[0012] As a preferred embodiment of the present invention, in the verification execution module, the sequential verification steps include: Verify whether the state of the authorized object is valid; otherwise, reject the request. Verify that the data type and time range retrieved this time are within the constraints of the data range parameter; if they are outside the range, reject the request. Verify whether the current cumulative number of queries has reached the maximum number of queries for the authorized object. If it has, reject the request; otherwise, perform data retrieval and increment the cumulative number of queries.
[0013] As a preferred embodiment of the present invention, in the protocol anchoring tracing module, the step of generating the tracing record includes: Extract the caller's identity, call timestamp, data description, scenario anchor code of the authorized object it depends on, and corresponding business protocol identifier for this data retrieval. The following information is written into the traceability record: the identity of the requester, the timestamp of the request, the description of the requested data, the scenario anchor code, the business protocol identifier, the protocol text summary, the current cumulative number of queries, and the remaining number of queries after the request. The hash operation is performed by concatenating all field contents of the traceability record with the hash digest of the previous traceability record, and the resulting hash value is written into the link hash field of the traceability record and then stored.
[0014] As a preferred embodiment of the present invention, the steps for verifying the traceability record in the protocol anchoring traceability module include, in sequence: Receive a third-party verification request, the third-party verification request carrying the original business agreement content and the traceability record identifier to be verified; The business type field in the original business agreement content is concatenated with the applicant organization identifier in a preset order and then a hash operation is performed. The result is compared with the scenario anchor code in the traceability record. If they are inconsistent, the verification failure result and the inconsistency field are output. Perform a hash operation on the original business protocol content, compare the resulting digest with the protocol text digest stored in the traceability record, and output a verification failure result if they do not match. The continuity of the link hash field of the traceability record is verified. The concatenated hash value of all fields of the traceability record and the hash digest of the previous traceability record is recalculated and compared with the link hash field. If they are inconsistent, a tampering alarm is output. If they are consistent, a verification result is output.
[0015] The beneficial effects of this invention are: 1. This invention uses scenario anchor codes to uniquely bind the authorization to the specific business scenario of the applicant organization at the technical level, fundamentally eliminating the possibility of separation between authorization acquisition and authorization use in terms of scenario, so that the behavior of retrieving data across scenarios is identified and rejected in the verification process.
[0016] 2. This invention, through the synergistic effect of the unique source constraint of the authorization constraint parameters and the read-only authorization object mechanism, ensures that the constraint content cannot be changed by any module within the system after the authorization is generated, and that the authorization execution result is strictly consistent with the original agreement of the business protocol, thus providing technical guarantee for the complete execution of the authorization constraints.
[0017] 3. This invention incorporates the scenario anchor code and protocol text digest into the hash chain traceability record, enabling third parties to independently verify the scenario binding relationship of the retrieval behavior, the integrity of the protocol text, and the continuity of the traceability record by holding the original business protocol content. The verification results do not rely on internal system data and have strong credibility. Attached Figure Description
[0018] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a schematic diagram of the structure of the credit information business data management system of the present invention. Detailed Implementation
[0019] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.
[0020] Example 1: As Figure 1 As shown, the credit information business data management system of the present invention includes: The protocol parsing module is used to extract the business type field and the applicant organization identifier from the business agreement content carried in the authorization application, generate a scenario anchor code that uniquely corresponds to the business agreement through hash operation, extract the contract validity period field, the licensed data range field and the licensed query count field from the business agreement content, derive the effective time window parameter, data range parameter and query count limit parameter respectively, and perform a hash operation on the business agreement content to generate a protocol text digest. Furthermore, in the protocol parsing module, the steps for generating the scenario anchor code are as follows: The business type field and the applicant organization identifier are concatenated in a preset order, a hash operation is performed on the concatenation result, and the resulting hash value is used as the scenario anchor code.
[0021] Furthermore, the effective time window parameter, data range parameter, and query count limit parameter are all derived solely from the extraction results of the contract validity period field, the permitted data range field, and the permitted query count field.
[0022] Specifically, the protocol parsing module is the entry point for this system to process authorization applications. Its core task is to extract key fields from the business protocol content carried in the authorization application and complete two types of calculations: generating scenario anchor codes and generating protocol text digests, while deriving the constraint parameters required for subsequent verification.
[0023] The business agreement is submitted along with the authorization application in structured text format. The agreement parsing module extracts the following fields: business type, applicant organization identifier, contract validity period, permitted data scope, and permitted query count. The business type field identifies the specific business scenario corresponding to this authorization, and the applicant organization identifier identifies the organization that initiated the authorization application and is unique within the system. All of these fields are directly derived from the business agreement content itself and do not incorporate external parameters.
[0024] Existing credit reporting systems typically only verify the authorizing entity without binding the authorization to the intended use case. This allows data-retrieving agencies to use the data for purposes other than those agreed upon in the agreement, creating a risk of authorization abuse. This module addresses this issue from a technical perspective through a scenario-anchoring code mechanism.
[0025] The protocol parsing module records the extracted business type field as follows: The applicant organization identifier is recorded as The two fields are concatenated into a string according to the preset order of business type field first and applicant organization identifier last. ,in This indicates a sequential string concatenation operation, followed by... Perform a hash operation, and the resulting hash value is the scene anchor code. : ; The preferred hash algorithm is SHA-256. Scenario anchor code. Encoding both the business type and the applicant organization dimensions simultaneously ensures that when either dimension changes... All of these will change accordingly, thereby achieving a unique binding between authorization and the specific organization's usage behavior in a specific scenario. When a subsequent data retrieval request declares a usage scenario that is different from... In case of inconsistency, the system can directly reject the authorization during the verification process to ensure that the authorization is not used across different scenarios.
[0026] The protocol parsing module extracts the start and end times from the contract validity period field and uses them as the valid time window parameter; it extracts the data type and time range from the permitted data range field and uses them as the data range parameter; and it extracts the number of queries from the permitted query count field and uses it as the maximum number of queries parameter. , The values are positive integers. The above three parameters are based solely on the extraction results of the corresponding protocol fields and cannot be independently set or overridden by other modules in the system. This eliminates the possibility of the system internally expanding or narrowing the interpretation of the authorization constraint parameters, ensuring that the actual constraints are strictly consistent with the protocol agreement.
[0027] The protocol parsing module records the complete text of the business protocol content as A hash operation is then performed, and the resulting hash value is used as a protocol text digest. : ; The preferred hash algorithm is SHA-256. Protocol text digest. With scene anchor code Valid time window parameters, data range parameters, and maximum number of queries parameters Both are passed to the authorization object construction module for constructing the authorization object. This is used for subsequent third-party verification to compare with the digest obtained by recalculating the original agreement content, in order to verify whether the agreement text has been tampered with after authorization was generated.
[0028] The authorization object construction module is used to construct the scenario anchor code, effective time window parameters, data range parameters, query count limit parameters and the protocol text digest into an authorization object, which is persistently stored in read-only mode and does not provide a modification interface; Furthermore, in the authorization object construction module, the construction step of the authorization object also includes: Determine whether the entity submitting the authorization application is the legal representative of the enterprise; If not, extract the authorization document identifier from the authorization application, concatenate the authorization document identifier with the applicant organization identifier, perform a hash operation, and generate the authorization anchor code; The delegate anchor code and the authorization level field are written together into the authorization object.
[0029] Specifically, after the protocol parsing module completes field extraction and parameter derivation, it sets the scene anchor code. Valid time window parameter, data range parameter, maximum number of queries parameter and protocol text summary The application is then passed to the authorization object construction module. The authorization object construction module constructs the authorization object based on the above five items and decides whether to include fields related to delegated authorization, depending on the submitting entity of the authorization request.
[0030] The authorization object construction module first determines whether the submitting entity of the authorization application is the legal representative of the enterprise. This determination is achieved by comparing the identity information of the submitting entity with the pre-registered legal representative information of the enterprise in the system, using conventional identity verification methods in this field.
[0031] If the submitting entity is the legal representative of the enterprise, proceed directly to the step of writing the authorized object.
[0032] If the submitting entity is not the legal representative of the enterprise, then extract the power of attorney document identifier from the authorization application and record the power of attorney document identifier as follows: The applicant organization identifier is recorded as The authorization document identifier is concatenated into a string according to the preset order of first the applicant organization identifier and then the applicant organization identifier. ,symbol This indicates a sequential string concatenation operation, followed by... Perform a hash operation, and the resulting hash value is the delegation anchor key. ,Right now: ; The preferred hash algorithm is SHA-256. Delegation anchor code. Encoding both the authorization document and the applicant organization simultaneously ensures that if either dimension changes... All of these will change accordingly, thereby uniquely binding the entrusted authorization to a specific institution, so that the legality of the entrusted authorization can be verified in subsequent verification stages.
[0033] After completing the above judgment and calculation, the authorization object construction module writes the following content into the authorization object: scene anchor code. Valid time window parameter, data range parameter, maximum number of queries parameter Protocol text summary The authorization level field identifies the type of entity submitting this authorization, and its value can be either direct authorization by the legal representative or authorization by proxy. If the submitting entity is not the legal representative of the enterprise, a proxy anchor code will also be included. Write it into the authorization object as well.
[0034] Once the authorized object is constructed, it is persistently stored in read-only mode, and the system does not provide any modification interface. Simultaneously, the system establishes a cumulative query count counter with an initial value of zero for each authorized object. This counter is stored independently of the read-only authorized object and can only be incremented after the verification execution module confirms successful data retrieval; no other module may modify or reset it. The technical significance of this read-only storage mechanism is that once the authorized object is generated, it forms a fixed correspondence with the business agreement content. During system operation, no module can change the field content of the authorized object, thus ensuring that the authorization constraints read by the subsequent verification execution module are strictly consistent with the original agreement, while providing an immutable comparison benchmark for third-party verification.
[0035] The verification execution module is used to verify the consistency between the scenario declaration parameters carried in the request and the scenario anchor code in the authorized object when a data retrieval request is received, and to verify the compliance of the authorization status and data range in turn. After all the verifications are successful, the data retrieval is executed. Specifically, after receiving a data retrieval request, the verification execution module sequentially performs delegated authorization verification, scenario consistency verification, authorization status verification, data range compliance verification, and query count compliance verification. Only after all verifications are passed can the data retrieval be performed.
[0036] Furthermore, the verification execution module includes the following steps before performing the consistency verification: Read the authorization level field from the authorization object; When the authorization level field indicates that the authorization is directly granted by a non-legal representative, the request is rejected if the data retrieval request does not carry the authorization document identifier. Otherwise, the authorization document identifier is concatenated with the applicant organization identifier and a hash operation is performed. The resulting hash value is compared with the authorization anchor code stored in the authorization object. If they do not match, the request is rejected.
[0037] Specifically, the verification execution module first reads the authorization level field from the authorization object. If the authorization level field indicates direct authorization by the legal representative, this step is skipped, and the module proceeds directly to scenario consistency verification. If the authorization level field indicates direct authorization by a non-legal representative, the verification execution module checks whether the data retrieval request carries a power of attorney document identifier. If not, the request is rejected. If the power of attorney document identifier is carried, the power of attorney document identifier in the request is combined with the applicant organization identifier in the same concatenation order and hash method as the authorization object construction module to calculate the request-side power of attorney anchor code. ,Will Delegation anchor key stored in the authorized object The system performs a comparison; if the two are inconsistent, the request is rejected; if they are consistent, the system proceeds to scenario consistency verification.
[0038] Furthermore, in the verification execution module, the consistency verification steps include: Extract the scene declaration parameters carried in the data retrieval request; compare the scene declaration parameters with the scene anchor code in the authorized object; If the comparison is inconsistent, the data retrieval request is rejected, and a scenario discrepancy record is generated. The scenario discrepancy record includes the applicant organization identifier, scenario declaration parameters, scenario anchor code and request timestamp, and the scenario discrepancy record is associated with the authorized object and stored.
[0039] Furthermore, in the verification execution module, the consistency verification, after generating the scenario deviation record, also includes: The scenario deviation records are stored in the scenario deviation log database and the scenario deviation count of the applicant institution is updated. Within a preset statistical period, when the scenario deviation count exceeds a preset threshold, the status of all authorized objects corresponding to the applicant organization is set to pending review, and a review notification containing the applicant organization's identifier and the corresponding scenario deviation record list is pushed to the system administrator.
[0040] Specifically, the verification execution module extracts the scenario declaration parameters from the data retrieval request and records them as follows: The scene anchor code stored in the authorized object is recorded as ,right and Compare them.
[0041] like and If they match, proceed to the next verification step.
[0042] like and If there is a discrepancy, the data retrieval request will be rejected, and a scenario deviation record will be generated.
[0043] The scenario deviation record includes the applicant organization identifier and scenario declaration parameters. Scene anchor code The request timestamp is recorded and associated with the corresponding authorized object for storage. After a scenario deviation record is generated, the verification execution module stores it in the scenario deviation log database and increments the scenario deviation count for the applicant organization. Within a preset statistical period, when the scenario deviation count exceeds a preset threshold, the verification execution module sets the status of all authorized objects corresponding to the applicant organization to "pending review" and pushes a review notification to the system administrator. The review notification includes the applicant organization's identifier and the corresponding list of scenario deviation records.
[0044] The aforementioned mechanism of deviating from the target scenario and automatically setting the status to pending review can continuously monitor the abnormal authorized use behavior of the applicant organization. When the organization repeatedly attempts to retrieve data across scenarios, it can trigger system-level intervention without the need for manual review each time, effectively reducing the risk of authorization abuse.
[0045] Furthermore, in the verification execution module, the sequential verification steps include: Verify whether the state of the authorized object is valid; otherwise, reject the request. Verify that the data type and time range retrieved this time are within the constraints of the data range parameter; if they are outside the range, reject the request. Verify whether the current cumulative number of queries has reached the maximum number of queries for the authorized object. If it has, reject the request; otherwise, perform data retrieval and increment the cumulative number of queries.
[0046] Specifically, the system first verifies whether the authorized object is in a valid state; otherwise, the request is rejected. The authorized object's state may become invalid due to exceeding the valid time window parameter, being set to a pending review state, or other system management operations.
[0047] Then, it is verified whether the data type and time range retrieved are within the data range parameters of the authorized object. If they are outside the range, the request is rejected.
[0048] Finally, the current value is read from the cumulative query count counter associated with the authorized object and recorded as follows. The maximum number of queries stored in the authorized object is denoted as... ,verify Has it been achieved? .like Then reject the request; if Then execute the data retrieval, and after the data retrieval is complete, update the cumulative query count to [data missing]. This update operation only applies to the standalone counter and does not involve any fields of the read-only authorized object.
[0049] The protocol anchoring traceability module is used to generate a traceability record containing the scenario anchoring code after data retrieval and execution, and store it in a hash chain manner, as well as to receive third-party verification requests and perform verification on the traceability record.
[0050] Specifically, after the data retrieval is completed, the protocol anchoring and tracing module extracts the caller's identity, retrieval timestamp, retrieval data description, and the scenario anchoring code of the authorized object it depends on. Corresponding business protocol identifier and protocol text summary Together with the current cumulative query count updated by the verification execution module and the remaining number of times after retrieval They are all written into the traceability record, among which This is the maximum number of queries stored in the authorized object.
[0051] After the traceability record is written, the protocol-anchored traceability module concatenates all fields of the current traceability record with the hash digest of the previous traceability record, performs a hash operation, and writes the resulting hash value into the link hash field of the current traceability record before storing it. For the first traceability record, the hash digest of the previous traceability record is replaced with a preset fixed value. This hash chain storage method ensures that if any traceability record is tampered with, its link hash field and the link hash fields of all subsequent records will become invalid, thus achieving continuous protection of the integrity of all traceability records.
[0052] In existing credit reporting systems, post-event verification of data retrieval typically relies on internal system logs, making it impossible for third parties to independently verify whether the retrieval behavior is consistent with the original agreement. This module incorporates scenario anchor codes and agreement text summaries into the traceability record, enabling third parties to independently verify retrieval behavior using the original business agreement content, without relying on internal system data.
[0053] The protocol anchoring and tracing module receives a third-party verification request, which carries the original business protocol content and the identifier of the tracing record to be verified. The verification steps are as follows.
[0054] First, the scenario anchor code is recalculated by combining the business type field and the applicant organization identifier in the original business agreement content with the same concatenation order and hashing method as the protocol parsing module. The result is then compared with the scenario anchor code stored in the traceability record. Comparison is performed; the scene anchor code in the traceability record is among them. The traceability record is directly taken from the authorized object during generation, ensuring consistency between the two. If discrepancies are found, the verification failure result and the inconsistent fields are output.
[0055] Subsequently, a hash operation is performed on the complete text of the original business agreement content, and the resulting digest is compared with the protocol text digest stored in the traceability record. Perform a comparison; if there is a discrepancy, output a verification failure result.
[0056] Finally, the link hash field of the traceability record to be verified is continuously verified. The concatenated hash value of all fields of the traceability record and the hash digest of the previous traceability record is recalculated and compared with the link hash field. If they are inconsistent, a tampering alarm is output; if they are consistent, a verification pass result is output.
[0057] The above three verification steps correspond to scenario binding relationship verification, protocol text integrity verification, and traceability record continuity verification, respectively. Together, they constitute a complete closed-loop verification mechanism, enabling third parties to independently verify the consistency between data retrieval behavior and the original protocol agreement without relying on internal system data.
[0058] In summary, in this embodiment, the protocol parsing module uniquely binds authorization to the usage behavior of a specific institution in a specific business scenario through a scenario anchor code. The authorization object construction module constructs a read-only authorization object based on relevant parameters and the protocol text digest and stores it persistently. The verification execution module sequentially performs delegated authorization verification, scenario consistency verification, authorization status verification, data range compliance verification, and query count compliance verification, and triggers system-level intervention for abnormal scenario deviations. The protocol anchoring traceability module records each retrieval behavior in a hash chain and supports independent closed-loop verification by third parties. The four modules work together to form a complete technical closed loop from authorization generation and constraint execution to post-event verification, effectively solving the technical problems in the existing credit reporting system such as the decoupling of authorization and usage scenarios, the tampering of authorization constraints, and the inability of third parties to independently verify the compliance of retrieval behavior.
[0059] Example 2: A credit reporting agency faces the following practical problems when providing financial data authorization services to micro and small enterprises in a region: After obtaining authorization from an enterprise, the authorizing agency risks using the authorization for purposes outside the agreed-upon scenarios; the authorization constraint parameters lack uniqueness guarantees, and there is a possibility of expanded interpretation within the system; furthermore, in the event of a data retrieval dispute, a third party cannot independently verify whether the retrieval behavior is consistent with the original agreement. To solve these problems from a technical perspective, the agency uses the Credit Reporting Commercial Data Management System of this invention to manage the entire process of authorization generation, constraint execution, and post-verification.
[0060] The organization provides an authorization portal to enterprises via its WeChat official account. After the enterprise's legal representative completes real-person authentication, they select the authorizing institution and authorization type as "operating loan income and expenditure flow query," confirm the authorization letter content, and submit the authorization application. The agreement parsing module extracts the business type field and the applicant institution identifier from the business agreement content, generates a scenario anchor code uniquely corresponding to this agreement through hash operation, and technically binds the authorization to the institution's usage behavior in the operating loan scenario. Simultaneously, it extracts three constraint parameters: a 90-day contract validity period, a permitted data range of the past 12 months of income and expenditure flow, and a maximum of 3 permitted queries. These three constraints are uniquely derived from the extraction results of the corresponding agreement fields, eliminating the possibility of internal system interpretations that expand or narrow the scope of authorization. Furthermore, it performs a hash operation on the complete text of the business agreement to generate an agreement text digest. The authorization object construction module persistently stores the above content in read-only mode, without providing any modification interface, and establishes an independent cumulative query count counter with an initial value of zero.
[0061] When a data retrieval request arrives, the verification execution module verifies the consistency between the scenario declaration parameters and the scenario anchor code. Upon confirmation of consistency, it sequentially verifies the authorization status, data range, and query count. Once all verifications pass, the data retrieval is executed, and the counter is incremented to 1. Subsequently, if the authorizing institution initiates a second request using the credit card application scenario declaration parameters due to a system configuration error, the verification execution module identifies the scenario deviation and rejects it. It generates a scenario deviation record containing the applicant institution identifier, scenario declaration parameters, scenario anchor code, and request timestamp, stores it in the log database, and updates the deviation count, effectively preventing authorization from being used outside the agreed-upon scenario.
[0062] The authorization expires automatically after 90 days. If a company subsequently objects to the compliance of the data retrieval, it submits a verification request to the agreement anchoring and tracing module, possessing only the original business agreement content. The module performs three verifications sequentially: scenario binding relationship, agreement text integrity, and continuity of tracing records. All verifications pass, proving that the retrieval was consistent with the agreement and that the records were not tampered with. The entire process requires no access to any internal system data, ensuring independent and reliable verification results and effectively resolving disputes.
[0063] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.
Claims
1. A credit information business data management system, characterized in that, include: The protocol parsing module is used to extract the business type field and the applicant organization identifier from the business agreement content carried in the authorization application, generate a scenario anchor code that uniquely corresponds to the business agreement through hash operation, extract the contract validity period field, the licensed data range field and the licensed query count field from the business agreement content, derive the effective time window parameter, data range parameter and query count limit parameter respectively, and perform a hash operation on the business agreement content to generate a protocol text digest. The authorization object construction module is used to construct the scenario anchor code, effective time window parameters, data range parameters, query count limit parameters and the protocol text digest into an authorization object, which is persistently stored in read-only mode and does not provide a modification interface; The verification execution module is used to verify the consistency between the scenario declaration parameters carried in the request and the scenario anchor code in the authorized object when a data retrieval request is received, and to verify the compliance of the authorization status and data range in turn. After all the verifications are successful, the data retrieval is executed. The protocol anchoring traceability module is used to generate a traceability record containing the scenario anchoring code after data retrieval and execution, and store it in a hash chain manner, as well as to receive third-party verification requests and perform verification on the traceability record.
2. The credit reporting business data management system according to claim 1, characterized in that, In the protocol parsing module, the steps for generating the scenario anchor code are as follows: The business type field and the applicant organization identifier are concatenated in a preset order, a hash operation is performed on the concatenation result, and the resulting hash value is used as the scenario anchor code.
3. The credit reporting business data management system according to claim 1, characterized in that, The effective time window parameter, data range parameter, and query count limit parameter are all derived solely from the extraction results of the contract validity period field, the permitted data range field, and the permitted query count field.
4. The credit reporting business data management system according to claim 1, characterized in that, In the authorization object construction module, the construction step of the authorization object further includes: Determine whether the entity submitting the authorization application is the legal representative of the enterprise; If not, extract the authorization document identifier from the authorization application, concatenate the authorization document identifier with the applicant organization identifier, perform a hash operation, and generate the authorization anchor code; The delegate anchor code and the authorization level field are written together into the authorization object.
5. The credit reporting business data management system according to claim 4, characterized in that, The verification execution module further includes the following steps before performing the consistency verification: Read the authorization level field from the authorization object; When the authorization level field indicates that the authorization is directly granted by a non-legal representative, the request is rejected if the data retrieval request does not carry the authorization document identifier. Otherwise, the authorization document identifier is concatenated with the applicant organization identifier and a hash operation is performed. The resulting hash value is compared with the authorization anchor code stored in the authorization object. If they do not match, the request is rejected.
6. The credit reporting business data management system according to claim 1, characterized in that, In the verification execution module, the consistency verification steps include: Extract the scene declaration parameters carried in the data retrieval request; compare the scene declaration parameters with the scene anchor code in the authorized object; If the comparison is inconsistent, the data retrieval request is rejected, and a scenario discrepancy record is generated. The scenario discrepancy record includes the applicant organization identifier, scenario declaration parameters, scenario anchor code and request timestamp, and the scenario discrepancy record is associated with the authorized object and stored.
7. The credit reporting business data management system according to claim 6, characterized in that, In the verification execution module, the consistency verification, after generating the scenario deviation record, further includes: The scenario deviation records are stored in the scenario deviation log database and the scenario deviation count of the applicant institution is updated. Within a preset statistical period, when the scenario deviation count exceeds a preset threshold, the status of all authorized objects corresponding to the applicant organization is set to pending review, and a review notification containing the applicant organization's identifier and the corresponding scenario deviation record list is pushed to the system administrator.
8. The credit reporting business data management system according to claim 1, characterized in that, In the verification execution module, the sequential verification steps include: Verify whether the state of the authorized object is valid; otherwise, reject the request. Verify that the data type and time range retrieved this time are within the constraints of the data range parameter; if they are outside the range, reject the request. Verify whether the current cumulative number of queries has reached the maximum number of queries for the authorized object. If it has, reject the request; otherwise, perform data retrieval and increment the cumulative number of queries.
9. The credit reporting business data management system according to claim 1, characterized in that, In the protocol anchoring tracing module, the steps for generating the tracing record include: Extract the caller's identity, call timestamp, data description, scenario anchor code of the authorized object it depends on, and corresponding business protocol identifier for this data retrieval. The following information is written into the traceability record: the identity of the requester, the timestamp of the request, the description of the requested data, the scenario anchor code, the business protocol identifier, the protocol text summary, the current cumulative number of queries, and the remaining number of queries after the request. The hash operation is performed by concatenating all field contents of the traceability record with the hash digest of the previous traceability record, and the resulting hash value is written into the link hash field of the traceability record and then stored.
10. The credit reporting business data management system according to claim 9, characterized in that, In the protocol anchoring and tracing module, the steps for verifying the tracing record include, in sequence: Receive a third-party verification request, the third-party verification request carrying the original business agreement content and the traceability record identifier to be verified; The business type field in the original business agreement content is concatenated with the applicant organization identifier in a preset order and then a hash operation is performed. The result is compared with the scenario anchor code in the traceability record. If they are inconsistent, the verification failure result and the inconsistency field are output. Perform a hash operation on the original business protocol content, compare the resulting digest with the protocol text digest stored in the traceability record, and output a verification failure result if they do not match. The continuity of the link hash field of the traceability record is verified. The concatenated hash value of all fields of the traceability record and the hash digest of the previous traceability record is recalculated and compared with the link hash field. If they are inconsistent, a tampering alarm is output. If they are consistent, a verification result is output.