A financial application control method and system based on trusted image offset verification

Abstract

The application discloses a financial application control method and system based on credit image offset verification. The credit image sequence including the data image and the credit support image is formed by obtaining the credit flow data of the target financial application and according to the approval node bit sequence; the image reference pair is constructed by positioning the supplement image and triggering the previous image; the associated support data items are replaced and decomposed to form the image offset section and the support condition data; the forward support anchoring and the reverse coverage cause are executed based on the support condition data to generate the support closed data; the support breakpoint items are extracted and the boundary is reshaped to generate the previous support locking data and the offset control distribution data; the application control is executed to rewrite the supplement closed data, so that the subsequent application control and the supplement closed rewriting can keep the process chain of the same credit image sequence to be locatable, traceable and controllable.

Description

Technical Field

[0001] This application relates to the field of financial technology data processing technology, and in particular to a financial application control method and system based on credit mirror offset verification. Background Technology

[0002] Financial applications typically involve multiple processing stages during the credit approval process, including application document submission, document supplementation, external verification, credit limit calculation, risk assessment, review and approval, and loan disbursement control. The income documents, business statements, contracts, guarantees, credit reports, or external verification receipts submitted by the applicant are referenced at different approval stages and form the basis of credit support. As financial institutions increase their online and automated approval processes, the system not only needs to record whether documents have been submitted, but also needs to identify the supporting role of these documents in credit assessment, and maintain the traceability of previous supporting relationships and the accuracy of subsequent application control even after documents are supplemented, replaced, or reviewed.

[0003] In relevant financial business systems, document management systems typically record the submission status, version status, and supplementary document status of application materials. Approval workflow systems typically record approval nodes, approval opinions, credit limit calculation results, and risk review results. External verification systems typically record receipt data such as credit verification, income verification, business transaction verification, business registration verification, or contract authenticity verification. Supplementary document processing generally revolves around the creation of supplementary document tasks, uploading of supplementary documents, completion of supplementary document tasks, document version updates, and approval node transitions. Approving personnel or system rules continue to perform review, re-examination, or loan disbursement control based on the status of the supplemented documents.

[0004] The above-mentioned processing method has basic recording capabilities regarding whether the data is complete, whether the nodes are transferred, and whether the approval opinion is formed. However, it lacks a traceable sequence association and continuity verification mechanism between the supplementary financial application data and the supporting data of the previous approval. This makes it difficult for the system to accurately identify the breakpoint of the support relationship, lock the replaced previous supporting data, and execute subsequent application control when the credit support relationship is continued, replaced, or covered after the supplementary data is submitted. Especially in scenarios where the same data object is submitted multiple times, multiple data items jointly replace a previous supporting data item, or a comprehensive supplementary data item covers multiple previous supporting data items, it is difficult to support the continuous traceability, closure judgment, and write-back control of the credit support relationship by simply relying on the data version status and the completion status of the supplementary data. Summary of the Invention

[0005] In view of the above-mentioned actual situation, this application proposes a financial application control method and system based on credit mirror offset verification, in order to solve the problem that the existing technology lacks a traceable positional association and continuity verification mechanism between the supplementary financial application materials and the previous approval supporting materials, which makes it difficult for the system to accurately identify the breakpoint of the support relationship, lock the replaced previous supporting materials and execute subsequent application control when the credit support relationship is continued, replaced or covered after the supplementary materials are submitted.

[0006] A financial application control method based on credit mirror offset verification includes:

[0007] Obtain the credit transfer data of the target financial application, the credit transfer data including document version status, supplementary document trigger status and approval trace data; based on the approval node sequence corresponding to the approval trace data, mirror the credit transfer data to form a credit mirror sequence arranged according to the approval node sequence, the credit mirror sequence including the document mirror corresponding to the document version status and the credit support mirror associated with the document mirror;

[0008] In the data mirror of the credit mirror sequence, a supplementary mirror and a triggering pre-sequence mirror pointed to by the supplementary triggering state are determined. The credit support mirrors associated with the supplementary mirror and the triggering pre-sequence mirror are constructed as mirror reference pairs. The support data items associated with the mirror reference pairs are decomposed by acceptance and replacement to form a mirror offset section with intra-item acceptance components, inter-item replacement components and offset item indexes. Based on the association status of the intra-item acceptance components, the inter-item replacement components and the offset item indexes in the mirror offset section, acceptance condition data is generated.

[0009] A bidirectional coverage verification is performed based on the coverage condition data. The bidirectional coverage verification includes forward coverage anchoring of the intra-item coverage component corresponding to the coverage condition data, and reverse coverage tracing of the inter-item substitution component corresponding to the coverage condition data, forming a forward coverage anchoring result and a reverse coverage tracing result; coverage closure data is generated from the forward coverage anchoring result and the reverse coverage tracing result.

[0010] The bearing breakpoint items are extracted from the bearing closure data, and the bearing breakpoint items are reshaped and delimited along the mirror node position of the credit mirror sequence to determine the reshaping starting mirror, the replaced preceding support mirror, and the replacement support data items, forming reshaping and delimitation data; based on the reshaping and delimitation data, preceding support locking data for the replaced preceding support mirror is generated in the credit mirror sequence.

[0011] Using the preceding support locking data and the reshaping delimitation data as control generation inputs, offset control allocation data is generated; based on the offset control allocation data, application control of the target financial application is executed to form an application control result; and the supplementary closure data corresponding to the application control result is written back to the credit mirror sequence.

[0012] This application proposes a financial application control method and system based on credit mirror offset verification. It realizes the positional mirror arrangement of the document version status, supplementary document trigger status, and approval trace data in the target financial application. Through mirror reference pairs, mirror offset sections, and bidirectional coverage verification, it identifies the connection, replacement, and coverage causal relationships between supplementary document data and the preceding credit support data. When the coverage closure is abnormal, it forms a coverage breakpoint item and performs reshaping and delimitation and locking of the preceding support. This enables subsequent application control and supplementary document closure write-back to maintain a locationable, traceable, and controllable processing chain along the same credit mirror sequence. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a financial application control method based on credit mirror offset verification.

[0014] Figure 2 This is a schematic diagram of mirror reference pair positioning under the supplementary trigger association in the embodiments of this application;

[0015] Figure 3 This is a schematic diagram of the mirrored embedding of the credit support record in the embodiments of this application;

[0016] Figure 4 This is a schematic diagram of the mirror offset section structure of the supporting data item in the embodiments of this application;

[0017] Figure 5 This is a schematic diagram of the opposition and merging of bidirectional bearing verification in the embodiments of this application;

[0018] Figure 6 This is a schematic diagram of the positional reshaping and delimitation of the bearing breakpoint item and the locking of the preceding support in the embodiments of this application;

[0019] Figure 7 This is a schematic diagram of the function curves of bearing imbalance and preceding locking response in the embodiments of this application.

[0020] Figure 8 This is a schematic diagram of a financial application control system structure based on credit mirror offset verification, provided for an embodiment of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and technical effects of this application clearer, the embodiments of this application are described in further detail below with reference to the accompanying drawings. The following embodiments illustrate how this application is implemented in financial application credit transfer, document supplementation, approval record keeping, verification of credit support relationships, and application control.

[0022] During the acquisition, retrieval, mirroring, verification, and write-back of data related to the target financial application, the financial institution's business system executes data processing under the constraints of applicant authorization, business authorization, internal approval authority, interface call authorization, or compliance processing rules. When the data involves applicant identity information, income information, business transaction records, contract documents, guarantee documents, credit information, external verification results, approval opinions, and supplementary documents, the system creates authorization traces through business agreement confirmation, electronic signature records, authorization confirmation interfaces, business handling confirmation records, internal approval records, or interface call credentials. These authorization traces are then linked to the application identifier, business transaction number, document version identifier, and processing timestamp of the target financial application. The financial institution's business system also performs access control, data anonymization, transmission encryption, field-level permission verification, call log recording, hash identifier mapping, internal business number mapping, and processing result traceability on data involving applicant personal information and business-sensitive information. This ensures that the credit transfer data has source identifiers, version identifiers, authorization identifiers, and processing traces before entering the mirroring and orchestration process.

[0023] In this application, Target Financial Application encompasses loan applications, credit line applications, installment applications, credit product applications, micro and small business loan applications, consumer loan applications, and other financial applications requiring document review and credit assessment. Target Financial Application generates credit flow data during the processes of business acceptance, document submission, document supplementation, external verification, credit line calculation, risk assessment, review and approval, and loan disbursement control.

[0024] The credit granting flow data refers to the data set generated during the credit approval process of a target financial application, which can characterize changes in document version, supplementary document triggers, approval traces, and credit support relationships. The credit granting flow data originates from the application document management system, credit approval workflow system, supplementary document management system, external verification system, approval log system, or the financial institution's business middle platform. The credit granting flow data includes application identifiers, document version identifiers, document object identifiers, document submission node identifiers, approval node identifiers, approval node sequence, supplementary document trigger identifiers, document citation identifiers, verification receipt identifiers, approval opinion identifiers, supporting role type, business serial number, and timestamps. This data exists internally within the system in the form of fields, records, indexes, logs, or message events, and is organized into a mirror sequence unfolding along the approval node sequence during subsequent processing.

[0025] The document version status refers to the version status of application documents at different processing stages, such as initial submission, supplementary document submission, external verification, approval modification, and review confirmation. Document version status includes document version identifier, document object identifier, document submission time, document source, document validity status, the approval node to which the document belongs, and the document version association. The supplementary document trigger status refers to the supplementary document status formed during the approval process due to document gaps, document inconsistencies, insufficient support, abnormal external verification, approval opinion requirements, or risk control rules. Supplementary document trigger status is manifested as supplementary document tasks, supplementary document notifications, supplementary document requirements in approval opinions, document gap markers, external verification inconsistency markers, or supplementary document process events.

[0026] The approval trace data refers to the node records, approval opinions, document citation records, credit limit calculation records, risk review records, external verification receipts, review records, or supplementary document triggering opinions generated during the approval process of the target financial application. The approval node sequence refers to the sequential identifier of each approval node during the approval process of the target financial application. The approval node sequence is determined based on the node order in the financial institution's approval workflow configuration, the time of the approval event, the approval task flow sequence number, the node sequence number in the approval log, or the business flow sequence. When multiple trace records exist for the same approval node, they are further sorted according to the document version identifier, approval timestamp, business flow number, or trace record identifier. The approval node sequence is used for subsequent mirroring, sequence placement determination, and boundary reshaping.

[0027] The credit mirror offset verification refers to a verification mechanism that processes the continuation, replacement, cause tracing, closure, and write-back of the credit support relationship between the supplementary document mirror and the preceding mirror, based on the document version status, supplementary document triggering status, and approval trace data of the target financial application, according to the order of approval nodes. The credit mirror offset verification uses the credit mirror sequence as the positional basis, the mirror reference pair as the source of objects on both sides, the mirror offset section as the carrier for replacement and decomposition, bidirectional coverage verification as the closure judgment method, and reshaping boundaries and preceding support locking to form the basis of application control.

[0028] The mirror orchestration refers to the process of transforming the document version status, approval trace data, and credit support records in the credit granting flow data into a credit granting mirror sequence based on the approval node sequence. The document mirror is a document version data object formed based on the document version status. The credit support mirror is a data object associated with the document mirror, used to characterize the supporting document items in the document mirror that provide credit support. The credit granting mirror sequence is a serialized data structure formed by document mirrors and credit support mirrors arranged according to the approval node sequence. The mirror node is a serialized data unit in the credit granting mirror sequence, used to carry the document mirror and the credit support mirror associated with it. Here, the mirror node belongs to the serialized node representation in data processing.

[0029] Combination Figure 2 The credit mirror sequence forms a mirror carrying domain along the positional order of the approval node. Figure 2 The data mirror and the support mirror are shown in a two-layer sequence diagram. The upper layer is the data mirror, and the lower layer is the support mirror. The bottom shows the direction of the mirror node sequence. The trigger sequence corresponds to the preceding mirror, and the complement sequence corresponds to the complement mirror. The preceding mirror and the complement mirror are linked by the complement trigger to form a mirror reference pair. Figure 2 Used to express the positional relationship in the trusted mirror sequence.

[0030] The credit support records refer to the records in the approval trace data that provide credit support for the application materials. The credit support function refers to the supporting judgment role played by the application materials, verification receipts, review records, or approval opinions in the calculation of the target financial application's credit limit, access judgment, risk assessment, determination of fund usage, confirmation of guarantee conditions, triggering of supplementary documents, or review processing. The credit support function is jointly determined by the trace records in the approval trace data, document citation relationships, and node positions, and is linked to the document version status through support function markers.

[0031] The traceability records are those extracted from the approval traceability data and used to form credit support records. Traceability records include node traceability records formed at each approval process node, as well as verification traceability records formed by external verification receipts. The document reference relationship refers to the reference relationship between the approval node, verification receipt, supplementary document triggering opinion, or review record and the specific document object. The supporting role marker is a data marker generated from the node position and document reference relationship corresponding to the traceability record, which includes node position, document object identifier, document version identifier, supporting role type, reference direction, verification source, and traceability record identifier.

[0032] Combination Figure 3The node traces and verification receipts in the approval trace data are extracted by the support function to form a support function mark. This support function mark is associated with the data version status and embedded in the support data item in the data mirror, thereby forming a credit support record and a credit support mirror. Figure 3 The credit support record is used to express that the data is extracted from the approval trace data, associated with the data version status, and embedded with the supporting data items before entering the credit support mirror.

[0033] The supporting data items are the data objects in the data mirror that correspond to the supporting role markers. Supporting data items include income verification data items, business transaction data items, contract data items, fund usage data items, guarantee data items, external verification data items, and other data items used for credit assessment. The supporting data item identifier is used to identify the supporting data item and is generated from the data object number, field number, internal business identifier, hash identifier, or a combination thereof.

[0034] The supplementary document mirror is the data mirror corresponding to the supplementary document submission node. The supplementary document submission node is the business node corresponding to when supplementary document data is submitted or the supplementary document task is completed. The triggering pre-processing mirror is the data mirror corresponding to the triggering approval node that generates the supplementary document triggering status. The triggering approval node is the approval node that generates supplementary document requirements, data gap markers, external verification inconsistency markers, or supplementary document triggering opinions. The mirror reference pair is a reference object composed of the credit support mirrors associated with the supplementary document mirror and the triggering pre-processing mirror respectively. In other words, the supplementary document mirror and the triggering pre-processing mirror correspond to different nodes in terms of data version status, but in terms of credit support relationship, they enter the same reference relationship through their respective associated credit support mirrors.

[0035] The "bearing purpose marker" refers to a data marker used to characterize the supporting purpose undertaken by a supporting document item in credit assessment. The bearing purpose marker is determined by at least one of the following: supporting role type, document citation purpose, supplementary document triggering status, or approval node sequence. The bearing purpose marker is used to limit the entry of preceding supporting document items and supplementary supporting document items into the same acceptance replacement decomposition processing group, and serves as the purpose benchmark for generating intra-item acceptance components, inter-item replacement components, and offset item indices. For example, the same business transaction data item is used for revenue authenticity assessment and also for business stability assessment; the same contract data item is used for fund usage assessment and also for transaction background assessment. The system identifies the bearing purpose before comparing data items, ensuring that the supporting relationships formed by the same data object under different credit assessment purposes are processed separately.

[0036] The aforementioned replacement decomposition refers to the process of comparing the supporting data item identifiers, carrying purpose markers, and identifying the supporting carrying relationships of the mirror reference to form intra-item replacement components and inter-item replacement components. The intra-item replacement component is a support carrying continuation component formed when the supporting data item in the supplementary mirror corresponds to the same supporting data item identifier and the carrying purpose markers of the two are consistent. The inter-item replacement component is a support carrying transfer component formed when the supporting data item in the supplementary mirror corresponds to different supporting data item identifiers and the carrying purpose markers of the two are consistent.

[0037] The offset item is a verification object formed by the preceding mirror-side support data item and the supplementary mirror-side support data item in the mirror reference pair, all revolving around the same carrying purpose. The offset item characterizes the succession or replacement relationship between the supplementary data and the preceding credit support data in terms of support data item identifier, carrying purpose, and mirror node position. The offset item index is a data index used to calibrate the offset item in the mirror offset section, and it includes at least the offset item identifier and the mirror node position identifier. The mirror offset section is a data section formed by the succession and replacement decomposition of the support data items associated with the mirror reference pair. The mirror offset section includes the offset item index and the intra-item succession components and inter-item replacement components that are indexed and associated with the offset item index.

[0038] Combination Figure 4 The relationship between the support data items between the preceding support mirror and the supplementary support mirror is cut into the mirror offset section. Figure 4 The left side shows the mirror image of the preceding support, the right side shows the mirror image of the supplementary support, and the middle shows the mirror offset section. The mirror offset section contains a three-layer structure: intra-item bearing components, inter-item replacement components, and offset item indexes. Figure 4 The right side outputs bearing condition data, which is used to explain that the mirror offset section is the data condition basis for subsequent bidirectional bearing verification.

[0039] The term "continuation and coverage" refers to the joint judgment made on the continuation of prior credit support relationships and the coverage of replacement relationships under the same offset item index. Here, "continuation" corresponds to the positive anchoring of the continuation component within an item, and "coverage" corresponds to the reverse coverage of the replacement component between items. The continuation and coverage condition data is generated from the association status of the continuation component within an item, the replacement component between items, and the offset item index in the mirrored offset section, and is used to trigger bidirectional continuation and coverage verification. The continuation and coverage condition data includes positive anchoring conditions, reverse coverage conditions, and offset item indexes.

[0040] The bidirectional bearing verification includes forward bearing anchoring and reverse coverage tracing. Forward bearing anchoring is the process of confirming that the same support data item maintains the continuity of the trusted support bearing in the supplementary mirror image along the supplementary direction. Reverse coverage tracing is the process of confirming that the replacement support data item traces back to the replaced preceding support data item under the same bearing purpose along the preceding direction. The bearing closure data is the closed state data formed by merging the forward bearing anchoring results and the reverse coverage tracing results with the offset item index as the merging reference. The bearing closure data includes bearing closure state, coverage attribution state, coverage closure state, and bearing imbalance state. The bearing breakpoint item is the offset item determined when neither the bearing closure state nor the coverage closure state has been formed.

[0041] Combination Figure 5 After the coverage condition data enters the merging ridge corresponding to the offset item index, the intra-item coverage component enters the forward coverage anchoring verification cavity and outputs the coverage closure status; the inter-item replacement component enters the reverse coverage cause verification cavity and outputs the coverage closure status. Figure 5 The fold lines inside the reverse coverage cause-finding verification cavity are used to indicate the cause-finding direction. Both the coverage closure state and the receiving closure state are merged into the receiving closure data. Figure 5 The merging structure shown is used to express that the overlay closure data is formed by merging the forward overlay anchoring results and the reverse overlay causation results under the same offset index.

[0042] The reshaping and delimitation process involves redefining the boundaries of the preceding support relationships and replacement relationships corresponding to the support breakpoint item along the positional sequence of the mirror nodes in the credit mirror sequence. The reshaping and delimitation uses the positional endpoint of the support breakpoint item as the delimitation reference to determine the reshaping starting mirror, the replaced preceding support mirror, and the replacement support data item, and generates reshaping and delimitation data. The reshaping starting mirror is either the data mirror carried by the mirror node where the positional endpoint of the support breakpoint item is located, or the data mirror associated with the support breakpoint item in the replacement mirror, used to determine the starting position for subsequent application control to re-examine the credit support relationship.

[0043] The replaced preceding support image refers to the trusted support image that carries the preceding support data item that is replaced or overwritten by the supplementary data in the triggering preceding image or its preceding image node. The replaced support data item refers to the support data item in the supplementary image used to replace or overwrite the replaced preceding support data item. The reshaping and delimitation data includes the overwrite breakpoint item identifier, the positional landing point, the reshaping starting image identifier, the replaced preceding support image identifier, the replaced support data item identifier, and the locked positional sequence.

[0044] The preceding support locking data is generated based on the remodeling and delimitation data and is formed specifically for the replaced preceding support mirror image. The preceding support locking data includes the mirror image identifier, locking reference status, locking sequence, corresponding offset item identifier, and bearer destination marker of the replaced preceding support mirror image. The locking reference status refers to the state in which the replaced preceding support mirror image is maintained as a locking reference object during the application control, closure update, and supplementary closure write-back processes. The locking reference status is used to indicate that subsequent credit mirror offset verification still traces along the credit support record corresponding to the replaced preceding support mirror image.

[0045] Combination Figure 6 The bearing breakpoint item has a positional landing point on the mirror node, which is indicated by the breakpoint delimiter. The mirror node where the bearing breakpoint item is located is used to determine the remodeling starting mirror; the remodeling delimiter region is formed in the forward direction from the remodeling starting mirror and hits the replaced preceding supporting mirror. Figure 6 The replaced preceding support mirror image is indicated by the clamping boundary, signifying the preceding support lock. The replacement support data item is marked on the replacement part sequence side. The remodeling boundary area and the preceding support lock area jointly output offset control assignment data, which is used to indicate that the offset control assignment data is generated jointly by the remodeling boundary data and the preceding support lock data.

[0046] The offset control assignment data is application control data formed by using preceding support lock data and reshaping delimitation data as control generation inputs. The offset control assignment data includes a control object field, a lock reference field, a control action field, and a write-back field. The control object field is used to define the offset control object in the target financial application; the lock reference field is used to define the lock reference status of the replaced preceding support mirror; the control action field is used to define the application control action corresponding to the reshaping delimitation data; and the write-back field is used to define the write-back mirror node of the supplementary closure data in the credit mirror sequence.

[0047] The application control involves performing control processes such as review, blocking, re-verification, external verification calls, closure write-back, or maintaining locked references on the target financial application according to the offset control allocation data. The application control result is the resulting data formed after the application control action is executed. The supplementary closure data is formed by updating the coverage closure data with the application control result and writing it back to the credit mirror sequence. The supplementary closure data includes the supplementary closure status, offset item identifier, locked reference status, write-back mirror node identifier, and application control result identifier. After the supplementary closure data is written back, it is associated with the credit support record and used to update the data basis for subsequent credit mirror offset verification.

[0048] Combination Figure 7 The states of cover closure, cover imbalance, and lock response change sequentially along the mirror node sequence. Figure 7The horizontal axis represents the mirror node sequence, the left vertical axis represents the bearing state value, and the right vertical axis represents the locking response value. The trigger sequence, replacement sequence, and breakpoint sequence are marked on the horizontal axis. The bearing closure curve decreases near the breakpoint sequence, the bearing imbalance curve forms a blockage near the breakpoint sequence, and the locking response curve rises after the breakpoint sequence and remains on a plateau. Figure 7 This is used to explain that after insufficient support closure and the formation of a support breakpoint, the preceding support locking response is triggered and maintained to support the write-back of the replacement component closure and subsequent state consistency verification.

[0049] In this application, data anonymization, access control, logging, encrypted transmission, hash identification, internal business number mapping, database sorting, timestamp storage, field mapping, message event transmission, interface calls, caching, distributed storage, relational database storage, and non-relational database storage are all implementations well known to those skilled in the art, and their underlying deployment details will not be further elaborated here. The above implementations do not affect the understanding and implementation of the embodiments of this application.

[0050] This application addresses the processing needs of continuing, replacing, tracing, and writing back prior credit support relationships in financial application supplementary document control. In financial application supplementary document control, after income data, business transaction records, contract data, guarantee data, or external verification receipts are replaced by supplementary documents, the system needs to confirm the continuation, replacement, tracing, and subsequent reference relationships formed by the prior support data that previously participated in the credit assessment after the supplementary documents. This application verifies and controls the credit support offset caused by supplementary documents through credit mirroring sequences, mirror offset sections, bidirectional coverage verification, reshaping and delimitation, and prior support locking, ensuring that supplementary documents form a processing chain of interconnected positioning, verification, tracing, delimitation, and writing back during the credit transfer process.

[0051] Reference Figure 1The financial application control method based on credit mirror offset verification includes the following processing: acquiring credit transfer data of the target financial application, the credit transfer data including document version status, supplementary document trigger status, and approval trace data; mirroring the credit transfer data based on the approval node sequence corresponding to the approval trace data to form a credit mirror sequence arranged according to the approval node sequence, the credit mirror sequence including document mirror corresponding to the document version status and credit support mirror associated with the document mirror; determining the supplementary document mirror and the triggering pre-sequence mirror pointed to by the supplementary document trigger status in the document mirror of the credit mirror sequence, and constructing the credit support mirrors associated with the supplementary document mirror and the triggering pre-sequence mirror respectively as mirror reference pairs; performing acceptance and replacement decomposition on the supporting document items associated with the mirror reference pairs to form a mirror offset section with intra-item acceptance components, inter-item replacement components, and offset item index, and generating acceptance condition data based on the association status of intra-item acceptance components, inter-item replacement components, and offset item index in the mirror offset section; and generating acceptance condition data according to the acceptance conditions. The document data undergoes bidirectional acceptance verification, which includes forward acceptance anchoring of the intra-item acceptance components corresponding to the acceptance condition data, and reverse coverage and causal analysis of the inter-item replacement components corresponding to the acceptance condition data. This generates forward acceptance anchoring results and reverse coverage and causal analysis results, which in turn generate acceptance closure data. Acceptance breakpoint items are extracted from the acceptance closure data, and the acceptance breakpoint items are reshaped and delimited along the mirror node position sequence of the credit mirror sequence. This determines the reshaping starting mirror, the replaced preceding support mirror, and the replaced support data items, forming reshaping and delimitation data. Based on the reshaping and delimitation data, preceding support locking data for the replaced preceding support mirror is generated in the credit mirror sequence. Preceding support locking data and reshaping and delimitation data are used as control generation inputs to generate offset control allocation data. Application control for the target financial application is executed based on the offset control allocation data, forming application control results. The supplementary document closure data corresponding to the application control results is written back to the credit mirror sequence.

[0052] S101, acquire credit transfer data and form a credit mirror sequence.

[0053] The server or financial institution's business platform obtains the credit transfer data for the target financial application. The target financial application has an application identifier, and the credit transfer data includes at least the document version status, supplementary document trigger status, and approval log data. The document version status indicates changes in the application documents during initial submission, supplementary document submission, external verification, approval modification, and review confirmation. The supplementary document trigger status indicates supplementary document tasks, document gap markers, external verification inconsistency markers, or supplementary document trigger opinions generated during the approval process. The approval log data indicates the credit transfer process, including approval nodes, approval opinions, document citations, external verification receipts, review records, and credit limit calculation records.

[0054] The server mirrors and orchestrates the credit granting data based on the approval node sequence corresponding to the approval trace data. The approval node sequence is determined by the approval process configuration, the time of the approval event, the approval task flow sequence number, the approval log node sequence number, or the business flow sequence. For multiple trace records under the same approval node, the server refines the sequence according to the document version identifier, approval timestamp, business flow number, or trace record identifier, ensuring that changes in document version and approval support within the same target financial application are included in the same sequence system.

[0055] During the image orchestration process, the server generates image data based on the image data version status. Each image data carries the image data version identifier, image data object identifier, image data source, image data submission node, image data validity status, and image data version associations. The server also generates a credit support image based on the credit support record corresponding to the image data version status in the approval log data. This credit support image carries the support function marker, support data item identifier, support function type, image data reference relationship, support source, and support purpose marker. The server configures the image data to the corresponding image node according to the approval node sequence and configures the associated credit support image to the same image node, forming a credit image sequence.

[0056] Reference Figure 2 The credit mirror sequence is arranged along the positional direction of the mirror node. Figure 2 The upper and middle layers are data mirrors, and the lower layer is a support mirror. Together, these two layers constitute the data carrying relationship under the same mirror node sequence. The data mirror is responsible for expressing the data version status, while the support mirror is responsible for expressing the supporting data items in the data mirror that have already formed a trust support function. Figure 2 The bottom sequence of positions—preceding position, triggering position, supplementary position, and subsequent position—is used to express the sequential relationship of the credit mirror sequence in the approval process. This two-layer mirror structure ensures that subsequent supplementary mirrors, triggering pre-sequence mirrors, mirror node positions, position landing points, refactoring starting mirrors, and write-back mirror nodes all fall on the same positional basis.

[0057] In this step, the authorized mirror sequence serves as the foundational data structure for subsequent processing. When constructing mirror reference pairs, the server locates the complement mirror and triggers the preceding mirror within this authorized mirror sequence. When forming mirror offset sections, the server extracts supporting data items from the corresponding authorized support mirror. During reshaping and boundary determination and complement closure write-back, the server still determines the landing point, locked object, and write-back node according to the mirror node position sequence of this authorized mirror sequence. Through this positional reference, subsequent mirror reference pair construction, mirror offset section generation, reshaping and boundary determination, and closure write-back all have a unified reference.

[0058] S102, determine the complement mirror and the trigger preceding mirror, and construct the mirror reference pair.

[0059] The server determines the supplementary document submission node and the triggering approval node that generated the supplementary document triggering status based on the supplementary document triggering status. The supplementary document submission node is the business node corresponding to the submission of supplementary documents, completion of the supplementary document task, or entry of supplementary document documents into the database. The triggering approval node is the approval node that generates supplementary document requirements, document gap markers, external verification inconsistency markers, supplementary document trigger comments, or supplementary document review comments. Both the supplementary document submission node and the triggering approval node are mapped to the mirror node position in the credit mirror sequence.

[0060] The server locates the data image corresponding to the supplementary document submission node in the authorized image sequence and identifies this data image as the supplementary document image. The server also locates the data image corresponding to the trigger approval node in the authorized image sequence and identifies this data image as the trigger preceding image. The supplementary document image carries the data version state formed after the supplementary document submission; the trigger preceding image carries the preceding data version state upon which the supplementary document trigger state is based. Both are within the same authorized image sequence and are linked through the supplementary document trigger state.

[0061] The server then extracts the trust support image associated with the supplementary image and the trust support image associated with the triggering preceding image. The trust support image associated with the supplementary image represents the supporting data items in the supplementary data that enter the trust judgment; the trust support image associated with the triggering preceding image represents the supporting data items that have already participated in the trust judgment before the supplementary triggering state is generated. The server constructs a mirror reference pair by associating the supplementary image and the trust support images associated with the triggering preceding image respectively.

[0062] Reference Figure 2 The pre-triggered image is located in the trigger position, and the complement image is located in the complement position. Figure 2 In the middle, the arched line above represents the component trigger association, which incorporates the trigger sequence and component sequence into the reference relationship under the same component trigger state. Figure 2 The dotted area below represents a mirror reference pair. The objects on both sides of the mirror reference pair originate from the trusted support mirror associated with the preceding mirror and the trusted support mirror associated with the supplementary mirror, respectively. In this way, the objects that subsequently undergo replacement decomposition are limited to the supplementary data and the preceding support data that triggered the supplementary data, making the processing scope and source clear.

[0063] After the mirror reference pair is formed, the server configures a reference pair identifier for the mirror reference pair and records the supplementary mirror identifier, the triggering preceding mirror identifier, the supplementary submission node identifier, the triggering approval node identifier, the supplementary trigger identifier, and the mirror node position identifier. This reference pair identifier is used to maintain consistency of source among the mirror offset section, bearing condition data, bearing closure data, and supplementary closure data in the future.

[0064] S103, forming mirror offset section and bearing condition data.

[0065] The server performs a replacement and decomposition process on the mirror references and their associated supporting data items. This process targets supporting data items from both the supplementary mirror side and the preceding mirror side. Supporting data items originate from the supporting function markers in their respective trusted supporting mirrors. These markers indicate the data object, data version, supporting function type, and carrying purpose marker. The server compares the supporting data item identifiers and carrying purpose markers between the supplementary mirror side and the preceding mirror side, identifying the supporting carrying relationship between them.

[0066] When a supporting data item in the supplementary image corresponds to the same supporting data item identifier as a supporting data item in the preceding image, and both have the same bearer destination marker, the server establishes a supporting bearer continuation relationship and generates an intra-item carryover component from this relationship. The intra-item carryover component is used to characterize the continuation of the preceding supporting data item along the same supporting data item identifier in the supplementary image.

[0067] When supporting data items in the supplementary document image correspond to different supporting data item identifiers than those in the preceding triggering document image, and both have the same bearing destination marker, the server establishes a supporting bearing transfer relationship and generates an inter-item substitution component based on this relationship. The inter-item substitution component represents the supporting bearing transfer formed by the substituted supporting data item in the supplementary document image to the replaced preceding supporting data item in the preceding triggering document image. In actual approval processes, replacing income certificates with business transaction records, contract documents with external verification receipts, and guarantee documents with review confirmation records all involve this type of inter-item substitution processing.

[0068] For one-to-many, many-to-one, and multiple supplementary data scenarios, the server generates candidate offsets based on the same supplementary trigger state, the same bearer destination marker, and the same mirror node position identifier. In scenarios where a preceding support data item is replaced by multiple supplementary support data items, the server merges the candidate offsets corresponding to the multiple supplementary support data items into the same offset identifier. In scenarios where multiple preceding support data items are replaced by one supplementary support data item, the server generates candidate offsets for each replaced preceding support data item, and then merges them based on the supplementary support data item identifier and the bearer destination marker. The merged offsets generate an offset index. The offset index includes an offset identifier and a mirror node position identifier. The offset identifier identifies the offset formed by an intra-item carryover component or an inter-item replacement component, and the mirror node position identifier indicates the mirror node position of the offset in the trusted mirror sequence.

[0069] The server establishes an index association between the offset item index and the intra-item inheriting component, and also establishes an index association between the offset item index and the inter-item substitution component. The mirrored offset section is composed of the offset item index and the intra-item inheriting component and inter-item substitution component that are indexed and associated with the offset item index. The mirrored offset section records the reference pair identifier, offset item identifier, mirror node position identifier, supporting data item identifier, bearing target mark, intra-item inheriting component, inter-item substitution component, and supporting bearing relationship identifier.

[0070] Reference Figure 4 The preceding support mirror is located in Figure 4 On the left, the replacement support is mirrored. Figure 4 On the right, the supporting data item relationship between the two enters the central mirror offset section. Figure 4 The mirror offset section has a three-layer structure: the upper layer is the intra-item continuity component, the middle layer is the inter-item substitution component, and the lower layer is the offset item index. The intra-item continuity component expresses the support bearing continuity relationship under the same support data item identifier, the inter-item substitution component expresses the support bearing transfer relationship under different support data item identifiers, and the offset item index merges the above two types of components into the corresponding offset item. Figure 4 The right-hand side outputs bearing condition data, indicating that the bearing condition data originates from the associated state within the mirror offset section.

[0071] The server generates bearing condition data based on the association status of intra-item bearing components, inter-item substitution components, and offset item indices in the mirror offset section. Bearing condition data includes forward anchoring conditions, reverse tracing conditions, and offset item indices. Forward anchoring conditions are generated from intra-item bearing components aggregated by offset item identifiers according to the offset item index, and point to the bearing object field corresponding to the forward anchoring. Reverse tracing conditions are generated from inter-item substitution components aggregated by offset item identifiers according to the offset item index, and point to the tracing object field corresponding to the reverse overlay tracing. Bearing object fields include supporting data items in the complement mirror and original supporting data items in the triggering preceding mirror; tracing object fields include replacement supporting data items and the replaced preceding supporting data items.

[0072] S104, perform bidirectional bearing verification and reshape boundary.

[0073] The server performs bidirectional coverage verification based on the coverage condition data. Bidirectional coverage verification includes forward coverage anchoring and reverse coverage tracing. Forward coverage anchoring targets the intra-item coverage component corresponding to the coverage condition data, confirming along the supplementary image whether the supporting data items maintain the trusted support continuity of the original supporting data items in the preceding image. Reverse coverage tracing targets the inter-item replacement component corresponding to the coverage condition data, confirming along the preceding image whether the replacement supporting data items in the supplementary image can be traced back to the replaced preceding supporting data items in the preceding image under the same coverage purpose.

[0074] Forward acceptance anchoring results in forward acceptance anchoring outcomes. These outcomes include acceptance anchoring relationships constructed from the acceptance components within the acceptance object domain, and acceptance closure states configured within these relationships. The acceptance closure state characterizes the closure formed in the support bearing continuity relationship between the preceding support data items and the supplementary support data items corresponding to the acceptance components within the item.

[0075] Reverse coverage tracing generates reverse coverage tracing results. These results include a coverage tracing relationship constructed from inter-item substitution components in the tracing object domain, and a coverage attribution state and a coverage closure state configured within that relationship. The coverage attribution state characterizes the formation of a support bearer transfer source between the substituted supporting data item and its preceding supporting data item; the coverage closure state characterizes the closure of this support bearer transfer source in terms of credit support function and mirror node order.

[0076] The server uses the offset index as the merging benchmark to merge forward anchoring results and reverse coverage tracing results into the same offset, forming closure data. This closure data includes the offset identifier, anchoring relationship, closure status, coverage tracing relationship, coverage attribution status, coverage closure status, and closure imbalance status. The offset index runs through both the closure condition data and the closure data, ensuring that forward and reverse verification results under the same offset are aggregated within the same data object.

[0077] Reference Figure 5 The data on bearing conditions is located at Figure 5 On the left, the offset index is located at Figure 5 A vertical ridge line is formed in the middle. Intra-item acceptance components enter the upper positive acceptance anchoring verification chamber and output the acceptance closed state; inter-item substitution components enter the lower reverse coverage tracing verification chamber and output the coverage closed state. The fold line inside the reverse coverage tracing verification chamber indicates that the tracing direction is inside the verification chamber. Both the coverage closed state and the acceptance closed state are merged towards the right side to cover the closed data. Figure 5 The structure shown in the diagram uses forward anchoring and reverse overlay to form a unified closure judgment under the same offset index.

[0078] When both the connection closure and coverage closure states of a certain offset item in the coverage closure data characterization are unclosed, the server establishes a coverage imbalance state and identifies the offset item associated with the coverage imbalance state as a coverage breakpoint item. The coverage breakpoint item indicates that the offset item requires further delimitation processing in both the intra-item connection direction and the inter-item replacement direction.

[0079] The server reshapes and delimits the support breakpoint items along the mirror node sequence of the authorized mirror sequence. Based on the mirror node sequence identifier in the offset index corresponding to the support breakpoint item, the server determines the position of the support breakpoint item in the authorized mirror sequence and the mirror node where the support breakpoint item is located. The server determines the reshaping starting mirror based on the mirror node where the support breakpoint item is located. Subsequently, the server determines the replacement preceding support mirror and the replacement support data item corresponding to the support breakpoint item along the mirror node sequence, using the position sequence as the delimitation reference, forming the reshaping delimitation data. The reshaping delimitation data includes the support breakpoint item identifier, position sequence, reshaping starting mirror identifier, replacement preceding support mirror identifier, replacement support data item identifier, and locked position sequence.

[0080] Based on the redefined delimitation data, the server generates prior support lock data for the replaced prior support image within the trusted image sequence. This prior support lock data includes the image identifier and lock reference status of the replaced prior support image, and configures the replaced prior support image as a lock reference object in subsequent application control. This lock reference object serves as the reference basis for maintaining the prior trusted support relationship during subsequent application control processes.

[0081] Reference Figure 6 , Figure 6 The bottom is a mirror node sequence axis, showing the preceding support area, trigger sequence, supplementary part sequence, and subsequent sequence. Figure 6 The middle section is a mirrored slice sequence. The bearing breakpoint item falls on the remodeling starting mirror near the position of the supplementary part through the vertical delimiting pin. The bearing breakpoint item forms a remodeling delimiting wedge region in the forward direction. This wedge region hits the replaced preceding support mirror. The replaced preceding support mirror forms a preceding support lock through the thickened boundary and clamping line. The replacement support data item is marked on the supplementary part side. Figure 6 The structure shown places the positional relationships between the breakpoint item, the remodeling starting image, the replaced predecessor support image, the replacement support data item, and the predecessor support lock.

[0082] S105, generate offset control assignment data and perform filler closure writeback.

[0083] The server uses preceding support lock data and reshaping delimitation data as inputs to generate offset control assignment data. Offset control assignment data includes control object fields, lock reference fields, control action fields, and write-back fields. The control object field identifies the control object, offset item identifier, and breakpoint item in the target financial application; the lock reference field identifies the replaced preceding support mirror, lock reference status, and lock reference object; the control action field is determined by the reshaping starting mirror, the replaced preceding support mirror, and the replaced support data item in the reshaping delimitation data; the write-back field points to the write-back mirror node of the supplementary closure data in the credit mirror sequence.

[0084] Reference Figure 6 Offset control assignment data is jointly exported from the remodeling boundary region and the preceding support locking region. The remodeling boundary region provides the remodeling starting image, the replaced preceding support image, and the replacement support data item, while the preceding support locking region provides the locked reference object and the locked reference status. Both types of data are entered into the offset control assignment data, so that the requested control actions revolve around the boundary results of the bearing breakpoint item and the preceding support locking results.

[0085] The server executes the corresponding application control actions based on the offset control dispatch data and the reshaping and delimitation data, forming the application control result. Application control actions include review, blocking, re-verification, external verification call, closure write-back, locked reference maintenance, approval node transfer, and supplementary document closure confirmation. The application control result includes control action identifier, execution status, review result, external verification call result, closure update result, locked reference status, and write-back mirror node identifier.

[0086] The server updates the cover closure data based on the application control results, forming supplementary closure data. Supplementary closure data includes the supplementary closure status, the corresponding offset identifier, the locked reference status, and the write-back mirror node identifier. The supplementary closure status characterizes the closure result of the cover breakpoint item after application control action; the offset identifier ensures that the supplementary closure data maintains the same index source as the mirror offset section, cover condition data, and cover closure data; the locked reference status characterizes the reference maintenance status of the replaced preceding support mirror after write-back; and the write-back mirror node identifier locates the write-back position of the supplementary closure data in the authorized mirror sequence.

[0087] The server locates the write-back mirror node based on the write-back field and writes the supplementary document closure data back to the credit mirror sequence. The write-back mirror node is the mirror node where the supplementary document mirror is located, the mirror node where the application control action was completed, or the mirror node corresponding to the review node. When writing back the supplementary document closure data, the server maintains the lock reference state corresponding to the previous support lock data and updates the credit support record used for subsequent credit mirror offset verification. Subsequent approval nodes continue to perform credit mirror offset verification based on the updated credit support record, supplementary document closure state, and lock reference state.

[0088] Reference Figure 7 , Figure 7The graph uses the mirror node sequence as the horizontal axis and the bearing status value and lock response value as the two vertical axes, marking the trigger sequence, supplementary sequence, and breakpoint sequence. The bearing closure curve declines near the breakpoint sequence, the bearing imbalance curve forms a peak near the breakpoint sequence, and the lock response curve rises after the breakpoint sequence and remains flat. This graphical logic indicates that after bearing imbalance occurs due to bearing closure data, the bearing breakpoint item triggers reshaping and delimitation, and locking of preceding support. Subsequently, the application control result is written back to the credit mirror sequence through supplementary closure data, and the lock reference state continues to support subsequent verification. This state transition process is very similar to the review process in business operations. The system processes the current supplement while stabilizing the preceding support relationship, and subsequent nodes continue to use the same support chain for judgment.

[0089] Through steps S101 to S105, the credit transfer data in the target financial application is organized into a credit mirror sequence. The supplementary document triggering state is transformed into a mirror reference pair. The connection and replacement relationships between supporting document items are organized into a mirror offset section. Forward connection anchoring and reverse coverage tracing form closed-loop data. The closed-loop breakpoint item further triggers reshaping and delimitation, and locking of preceding support. The application control result is finally written back to the credit mirror sequence in the form of supplementary document closed-loop data. This processing chain enables the supplementary document data to form a closed-loop processing process that is locatable, verifiable, traceable, delimitable, controllable, and rewritable during the credit transfer process.

[0090] In one embodiment, determining the credit support record includes: extracting the audit log data that provides credit support for the application materials, determining the node position of the audit log record in the approval node sequence, and the document reference relationship pointed to by the audit log record; generating a support role marker from the node position and document reference relationship, and associating the support role marker with the corresponding document version status to form a credit support record. The audit log records include node audit log records formed at approval process nodes or verification audit log records formed from external verification receipts, and the credit support mirror is determined by the credit support record corresponding to the document version status.

[0091] Furthermore, the mirror orchestration includes: associating credit support records with corresponding data mirrors, and mapping the support function markers in the credit support records to supporting data items in the data mirrors, forming a credit support mirror; configuring data mirrors with corresponding data version statuses as mirror nodes according to the approval node sequence, and associating the credit support mirrors with the corresponding mirror nodes, forming a credit mirror sequence. A supporting data item is a data object in a data mirror corresponding to a support function marker. Each supporting data item inherits the credit support relationship corresponding to a credit support record and is configured with a corresponding supporting data item identifier.

[0092] Furthermore, when determining the supplementary image and the pre-trigger image pointed to by the supplementary triggering state in the data image of the credit mirror sequence, the supplementary triggering state corresponds to the supplementary submission node and the triggering approval node that generates the supplementary triggering state; the supplementary image is determined by the supplementary submission node, the pre-trigger image is determined by the triggering approval node, and the credit support images associated with the supplementary image and the pre-trigger image are constructed as image reference pairs.

[0093] The server uses the application identifier of the target financial application as the primary key to collect approval trace data from the approval workflow system, document management system, external verification system, supplementary document management system, and approval log system. This approval trace data is represented in the system as approval node records, approval opinion records, credit limit calculation records, risk review records, document citation records, external verification receipts, review records, supplementary document trigger opinions, and supplementary document task records. The server aggregates the approval trace data according to the application identifier, business serial number, approval node identifier, document version identifier, and processing timestamp to form a set of trace records corresponding to the target financial application.

[0094] The server identifies records from the record set that support the credit granting of application materials. When a record contains a document citation identifier, verification receipt identifier, approval opinion field, credit limit calculation field, risk review field, admission judgment field, guarantee condition field, fund usage field, supplementary document trigger field, or review opinion field, the server writes the record into the support candidate record set. Records in the support candidate record set represent that a specific approval node, verification receipt, or review opinion has influenced the credit granting judgment of the specific application materials. Here, process traces and credit support traces are processed separately so that subsequent support mirroring has a clear source.

[0095] The supporting record set includes node record records and verification record records. Node record records originate from approval opinions, credit limit calculation records, access judgment records, risk review opinions, supplementary document triggering opinions, manual review opinions, and pre-loan review records. Verification record records originate from credit verification, income verification, business transaction verification, business registration information verification, invoice verification, contract authenticity verification, guarantee information verification, and fund usage verification. Node record records are used to express the internal approval nodes of financial institutions' references and judgments regarding the data objects, while verification record records are used to express the external verification system's verification source, verification conclusion, and receipt source for the data objects.

[0096] The server determines the node position for each trace record in the supporting candidate record set. The node position includes the approval node identifier, approval node sequence number, intra-node sequence number, business transaction number, processing timestamp, and trace record identifier. The approval node sequence number indicates the sequential position of the trace record within the target financial application approval flow, while the intra-node sequence number indicates the order of multiple trace records within the same approval node. The server uses both the approval node sequence number and the intra-node sequence number to form the node position, ensuring that the supporting role marker has a clear endpoint in the subsequent credit granting mirror sequence.

[0097] The server also determines the data reference relationships based on the log record. Data reference relationships include the log record identifier, data object identifier, data version identifier, data reference direction, data reference purpose, verification source identifier, and supporting role type. The data reference direction expresses the reference relationship between the approval node, verification receipt, or review record and the data object; the data reference purpose expresses the use of the data object in credit limit calculation, income authenticity assessment, operational stability assessment, fund usage assessment, guarantee condition confirmation, access rule assessment, or supplementary document trigger assessment. The data version identifier binds the data reference relationship to a specific data version status. After the same data object is submitted as supplementary document to form a new data version, the server distinguishes between the previous data version and the supplementary document version based on the data version identifier.

[0098] The server generates support role markers based on node locations and data reference relationships. These support role markers include application identifier, approval node identifier, approval node sequence, node sequence number, log record identifier, data object identifier, data version identifier, supporting data item identifier, support role type, reference direction, reference purpose, verification source identifier, and business serial number. The support role marker indicates that a specific data object, at a specific data version level, receives credit support through a specific approval node, a specific verification receipt, or a specific review record. This marker acts as a reference point for subsequent support mirroring; subsequent acceptance, replacement, and tracing all trace back to the source along this reference point.

[0099] The server associates the supporting role marker with the corresponding document version status to form a credit support record. The credit support record includes the application identifier, document version identifier, document object identifier, supporting document item identifier, supporting role marker, node location, document reference relationship, supporting role type, carrying purpose marker, and record tracking identifier. The association between the document version status and the supporting role marker indicates that a specific supporting document item in this document version has formed a credit support role in a designated approval node or verification source. Therefore, the credit support record simultaneously retains the document version source, approval node source, and credit support purpose source.

[0100] Reference Figure 3 Approval data is located in Figure 3On the left, node traces and verification receipts serve as two types of source records entering the supporting function extraction layer in the middle. The supporting function extraction layer uses node location and data citation as extraction entry points to generate supporting function markers. Figure 3 The data version status is located between the supporting role marker and the right-side mirrored embedded structure, and is used to express the binding relationship between the supporting role marker and the specific data version status. Figure 3 The data mirror, supporting data items, and credit support mirror on the right are used to represent the carrying position of the credit support record after it enters the mirror system. After this processing, the approval trace data becomes the structured support relationship data in the subsequent mirror offset verification.

[0101] When the server generates a credit support record, it simultaneously generates a support purpose marker. The support purpose marker is generated from at least one of the following: support function type, document citation purpose, supplementary document triggering status, and approval node sequence. It is used to characterize the specific support purpose undertaken by the supporting document item in the credit assessment. For example, income verification documents form the income authenticity support purpose in income authenticity assessment and the repayment ability support purpose in repayment ability calculation; operating cash flow documents form the operating stability support purpose in operating stability assessment and the cash flow coverage support purpose in cash flow coverage assessment; and contract documents form the fund usage support purpose in fund usage assessment and the transaction background support purpose in transaction background assessment.

[0102] The server writes the bearing purpose tag into the credit support record and associates the bearing purpose tag with the supporting data item identifier, data version identifier, and approval node sequence. When the same data object is referenced by multiple approval purposes, the server forms multiple sets of support relationship units according to the bearing purpose tag. Each set of support relationship units corresponds to one support function tag and one bearing purpose tag. In this way, the support relationships formed for the same data object under different credit judgment purposes are separated at the data level, and subsequent acceptance, replacement, and decomposition can be processed according to the same bearing purpose.

[0103] The server generates a data image based on the data version status. The data image includes a data image identifier, application identifier, data version identifier, data object identifier, data submission node identifier, data status, data source, data version association, approval node sequence, and business serial number. When a data version status is converted to a data image, the server retains the data version's node position in the approval workflow and maintains the correspondence between the data object and the data submission node, approval node, and verification source. The data image serves as the data version carrier object within the image node and is subsequently used to locate supplementary image nodes, trigger preceding image nodes, reshape the initial image node, and write back the image node.

[0104] The server associates the credit support record with the corresponding data image. The association process is based on the application identifier, data version identifier, data object identifier, supporting data item identifier, and approval node sequence. The supporting role marker in the credit support record is mapped to the supporting data item in the data image. The supporting data item is the data object in the data image corresponding to the supporting role marker. The supporting data item inherits the credit support relationship corresponding to the credit support record and is configured with the corresponding supporting data item identifier. The supporting data item identifier is formed by the data object number, field number, internal business identifier, hash identifier, or a combination thereof.

[0105] Within the same data mirror, a supporting data item carries one or more sets of supporting role markers. When a supporting data item is referenced by multiple approval nodes, the server retains multiple sets of supporting role markers according to the order of the approval nodes; when a supporting data item corresponds to multiple carrying purposes, the server forms multiple supporting relationship units according to the carrying purpose markers. A supporting relationship unit includes a supporting data item identifier, supporting role markers, carrying purpose markers, node positions, and data reference relationships. After entering the credit support mirror, the supporting relationship unit becomes the basic object for subsequent intra-item carrying components, inter-item replacement components, and offset item indexes.

[0106] The server is composed of supporting data items and supporting relationship units in the data mirror to form a trust support mirror. The trust support mirror includes a trust support mirror identifier, a data mirror identifier, a set of supporting data item identifiers, a set of supporting function markers, a set of trust support records, a set of carrier destination markers, a set of node locations, and a set of data reference relationships. The trust support mirror is used to represent the supporting data items within a data mirror, the trust support records corresponding to each supporting data item, and the trust support relationships formed by each supporting data item under its corresponding carrier destination.

[0107] Reference Figure 3 The supporting data item is embedded in the data image and the supporting data item forms the trust support image downwards. Figure 3 The data mirror on the right is used to carry the data version status. The supporting data items inside the data mirror are used to carry the supporting role markers. The trust support mirror below the data mirror is used to carry the set of support relationships formed by the trust support records. Figure 3 The structure shown illustrates the embedded relationship of "data version - supporting data item - supporting function mark - credit support mirror". This embedded relationship constitutes the object source of the mirror reference pair.

[0108] The server configures data mirrors corresponding to the data version status as mirror nodes according to the approval node sequence, and associates the credit support mirrors with the corresponding mirror nodes, forming a credit mirror sequence. A mirror node includes a mirror node identifier, approval node sequence, data mirror identifier, credit support mirror identifier, data version identifier, a set of supporting data item identifiers, and a node status field. One mirror node carries one data mirror and a set of credit support mirrors associated with that data mirror. The credit mirror sequence is formed by multiple mirror nodes arranged according to the approval node sequence.

[0109] Reference Figure 2 Multiple mirror nodes are arranged in the order of the approval node, and the upper-level data mirror and the lower-level support mirror together form the credit granting mirror sequence. Figure 2 The upper-level data mirror represents the arrangement of data version status in the order of approval nodes, while the lower-level support mirror represents the credit support relationship corresponding to each data mirror. The upper-level data mirror and the lower-level support mirror form a hierarchical bearing relationship at the same position. Through this bit-ordered bearing, the server can trace back from any supplementary node to the preceding support node that triggered the supplementary document during subsequent processing, and can also write back the supplementary document closure data to the corresponding mirror node.

[0110] In the credited mirror sequence, the server configures a mirror node sequence identifier for each mirror node. This sequence identifier is used throughout subsequent supplementary mirror positioning, triggering preceding mirror positioning, offset index generation, determination of the breakpoint sequence location, determination of the refactoring starting mirror, and determination of the write-back mirror node. Therefore, the credited mirror sequence simultaneously handles the data version sequence, the credit support relationship sequence, and the subsequent control write-back sequence. With the data version and credit support relationship on the same sequence line, subsequent supplementary offset processing has a unified reference.

[0111] The server determines the submission node and the approval node that triggered the submission status based on the submission status. The submission status manifests as a submission task, submission notification, submission requirements in the approval comments, a data gap marker, an external verification discrepancy marker, a submission process event, or a review of the submission comments. The submission node originates from a submission data submission event, a submission task completion event, a submission data entry event, or a submission data version generation event. The approval node originates from the approval node that generated the submission requirement, the approval node that generated the data gap marker, the approval node that generated the external verification discrepancy conclusion, or the approval node that generated the review of the submission comments.

[0112] The server establishes a node association between the supplementary document submission node and the triggering approval node based on the supplementary document trigger identifier. This node association includes the application identifier, supplementary document trigger identifier, triggering approval node identifier, supplementary document submission node identifier, triggering approval node sequence number, supplementary document submission node sequence number, and business serial number. The node association is used to express the correspondence between the approval node that triggers the supplementary document and the business node that receives the supplementary document under the same supplementary document trigger state.

[0113] The server locates the corresponding data image in the credit image sequence based on the supplementary document submission node and identifies this data image as the supplementary document image. When locating the supplementary document image, the server uses the data version status corresponding to the supplementary document submission event as a basis, and combines this with the supplementary document submission node identifier, data version identifier, data object identifier, and approval node sequence to determine the image node. The supplementary document image contains the data version status after the supplementary document is formed, as well as the credit support image associated with that data version status.

[0114] The server locates the corresponding data image in the credit image sequence based on the trigger approval node and identifies this data image as the pre-trigger image. When locating the pre-trigger image, the server uses the data version status corresponding to the approval trace record that generated the supplementary document trigger status as the basis, and combines this with the trigger approval node identifier, supplementary document trigger identifier, data reference relationship, and approval node order to determine the image node. The pre-trigger image contains the pre-existing data version status that participated in the credit assessment when the supplementary document trigger status was generated, as well as the credit support image associated with that data version status.

[0115] Reference Figure 2 The trigger approval node corresponds to the trigger sequence, and the bolded image slice on the trigger sequence is the preceding image; the supplementary document submission node corresponds to the supplementary document sequence, and the bolded image slice on the supplementary document sequence is the supplementary document image. Figure 2 The arched line between the two indicates the component trigger association, and the dashed area below indicates the mirror reference pair. Figure 2 The bottom sequence of bits—preceding, triggering, supplementary, and subsequent—expresses the preceding and following positions of the reference relationship within the same credited mirror sequence. The triggering sequence provides the source of preceding support, and the supplementary sequence provides the source of supplementary support; together, they form the two sources for subsequent replacement decomposition.

[0116] The server extracts the trusted support image associated with the supplementary image and the trusted support image that triggered the preceding image association. The trusted support image associated with the supplementary image includes a set of supplementary-side support data items, a set of supplementary-side support function markers, a set of supplementary-side bearer destination markers, and a set of supplementary-side support data item identifiers. The trusted support image that triggered the preceding image association includes a set of preceding-side support data items, a set of preceding-side support function markers, a set of preceding-side bearer destination markers, and a set of preceding-side support data item identifiers. The server constructs these two trusted support images into a mirror reference pair.

[0117] The mirror reference pair includes a reference pair identifier, application identifier, supplementary document trigger identifier, supplementary document mirror identifier, triggering preceding mirror identifier, supplementary document side credit support mirror identifier, preceding side credit support mirror identifier, supplementary document submission node identifier, triggering approval node identifier, supplementary document sequence identifier, triggering sequence identifier, set of supporting data items on both sides, set of supporting data item identifiers on both sides, and set of carrying purpose markers. The set of supporting data items on both sides in the mirror reference pair is used for subsequent replacement and decomposition, and the set of carrying purpose markers is used to limit subsequent offset items to be formed under the same credit support purpose.

[0118] When multiple supplementary document data items correspond to the same supplementary document triggering state, the server determines the supplementary document image corresponding to each supplementary document data item and generates multiple sets of supplementary document-side supporting data items under the same supplementary document triggering identifier. For scenarios where multiple triggered data items correspond to the same triggering approval node, the server determines the corresponding preceding-side supporting data items according to the data reference relationship, the carrying purpose marker, and the supporting data item identifier. The server uses the supplementary document triggering identifier, the carrying purpose marker, and the image node position identifier as the aggregation basis to construct one or more sets of image reference pairs between the supplementary document-side credit support image and the preceding-side credit support image.

[0119] The conditions for constructing a mirror reference pair include: the supplementary mirror and the triggering preceding mirror belong to the same target financial application; they are both located in the same credit granting mirror sequence; they are respectively associated with credit granting supporting mirrors; there is a business association between them formed by the supplementary triggering state; and the supporting data items on both sides enter the offset verification under the same supporting purpose based on the bearing purpose mark. After the mirror reference pair is formed, the server writes it into the mirror reference pair set and provides the mirror reference pair set to the subsequent mirror offset section construction process.

[0120] Through the above processing, the node trace records and verification trace records in the approval trace data are extracted to form credit support records. These credit support records are bound to the document version status through support function markers and embedded into the supporting document items in the document mirror to form a credit support mirror. The document mirror and the credit support mirror form a credit mirror sequence along the approval node position. The supplementary document submission node and the triggering approval node locate the supplementary document mirror and the triggering pre-sequence mirror respectively in this sequence. The credit support mirrors associated with the supplementary document mirror and the triggering pre-sequence mirror are constructed as mirror reference pairs. The mirror reference pairs output the sets of supporting document items, the set of supporting document item identifiers, the set of carrying purpose markers, and the mirror node position identifiers on both sides, providing data sources for the subsequent generation of intra-item carrying components, inter-item replacement components, offset item indexes, and mirror offset sections.

[0121] In one embodiment, the replacement decomposition includes: when the supporting data item in the supplementary image corresponds to the same supporting data item identifier as the supporting data item in the preceding image, a supporting bearing continuation relationship is formed, and an intra-item bearing component is generated from the supporting bearing continuation relationship; when the supporting data item in the supplementary image corresponds to a different supporting data item identifier as the supporting data item in the preceding image, a supporting bearing transfer relationship is formed, and an inter-item replacement component is generated from the supporting bearing transfer relationship. The offset item index includes an offset item identifier and a mirror node position identifier. The offset item identifier is used to identify the offset item formed by the intra-item bearing component or the inter-item replacement component, and the mirror node position identifier is used to indicate the mirror node position of the offset item in the authorized mirror sequence; the mirror offset section consists of the offset item index and the intra-item bearing component and the inter-item replacement component that are indexed and associated with the offset item index.

[0122] Reference Figure 4 The preceding support mirror is located on the left side of the mirror offset section, and the supplementary support mirror is located on the right side of the mirror offset section. The preceding support mirror outputs the preceding support data items that have already received the credit support record in the preceding mirror, and the supplementary support mirror outputs the supplementary support data items corresponding to the supplementary submission, supplementary verification, or supplementary review in the supplementary mirror. Support data items from both sides enter... Figure 4 After the central mirror offset section, the intra-item bearing component, inter-item replacement component, and offset item index are formed based on the bearing purpose mark, support data item identifier, and mirror node position identifier. Figure 4 The right-hand side outputs bearing condition data, indicating that the entry conditions for bidirectional bearing verification originate from the mirror offset section.

[0123] The server reads the associated trusted support image from the mirror reference pair and retrieves the set of preceding support data items from that trusted support image. Each support data item in the preceding support data item set carries a trusted support record, corresponding to a support function marker, support data item identifier, data version identifier, carrier destination marker, and approval node sequence. This set of preceding support data items is used to express the source of supporting data that has entered the trusted judgment before the supplementary document triggering state is generated.

[0124] The server reads the associated trusted support image from the mirror reference pair and retrieves the set of support data items for the supplementary document from that trusted support image. Each support data item in the set corresponds to the supplementary document version status, the supplementary document submission node, the supplementary document support function flag, the support data item identifier, the carrier destination flag, and the supplementary document mirror node order. The set of support data items for the supplementary document is used to express the source of the support data that enters the trusted judgment process after the supplementary document is submitted.

[0125] The server uses the reference pair identifier as the entry point, placing the preceding support data item set and the supplementary support data item set under the same mirror reference pair for processing. During processing, the server reads the support data item identifier and the carrying purpose marker for each preceding support data item, and also reads the support data item identifier and the carrying purpose marker for each supplementary support data item. The server performs purpose aggregation according to the carrying purpose marker, so that preceding support data items and supplementary support data items under the same credit judgment purpose enter the same candidate offset item processing group.

[0126] During the purpose-based aggregation process, the carrying purpose marker serves as the first-level aggregation condition. Different credit support purposes, such as revenue authenticity, operational stability, fund usage, transaction background, guarantee conditions, access rules, and risk review, are grouped into different processing groups. When the same data object is referenced under different credit support purposes, the server groups it into different processing groups according to the carrying purpose marker. In actual approval, when the same business transaction record is used for both revenue and operational stability assessments, the server processes it separately for the two support purposes, maintaining clear boundaries in subsequent offset assessments.

[0127] For offset term p, let the preceding support data item corresponding to offset term p in the preceding image be: Let the component support data item corresponding to the offset item p in the component mirror be: The corresponding supporting data item identifiers for the two are as follows: ,in Indicates the identifier of the preceding supporting data item. This indicates the identifier for the supplementary support data item. The corresponding load-bearing purpose markers for these two are: ,in Indicates the target of the preceding supporting data item. This indicates the bearing purpose of the supplementary support data item.

[0128] The server uses a reference to identify and pre-existing supporting data items. Supporting documents for supplementary materials Supporting data item identifiers , Bearing purpose mark In addition, candidate offset items are generated using the mirror node position identifier. These candidate offset items are used to carry the supporting relationship to be determined between the preceding side and the supplementary side. After the candidate offset items are formed, the server writes them into the intra-item carrying component or the inter-item replacement component based on the consistency status of the carrying purpose and the supporting data item identifier relationship.

[0129] Reference Figure 4 The support item in the left-side preceding support mirror corresponds to and its supporting data item identifiers The support item in the mirror image of the right-side supplementary support corresponds to... and its supporting data item identifiers Before the two side supports enter the central mirror offset section, their respective load-bearing purpose markers are first introduced. and . Figure 4 The mirror offset section in the middle receives the support data item object with credit support record, support function mark, bearing purpose mark and mirror position sequence.

[0130] The server performs a payload determination on the preceding and supplementary supporting data items corresponding to the candidate offset item p. This payload determination occurs before the supporting data item identifier comparison. The payload determination confirms whether the preceding and supplementary supporting data items serve the same credit assessment purpose. A consistent payload state is indicated as follows: ,in This indicates that the preceding support data item and the supplementary support data item corresponding to the offset item p have the same bearing purpose; This indicates that the two are categorized into different purposes. This indicates a conditional indicator; it takes the value 1 when the condition within the parentheses is true, and 0 otherwise.

[0131] exist In this case, the server performs a comparison of the supporting data item identifiers. If the identifier of the preceding supporting data item is the same as the identifier of the supplementary supporting data item, then an intra-item succession status is formed: ,in This indicates the continuation component within the item corresponding to offset item p. The continuation status within an item is used to characterize the continuation of the same supporting data item along the same supporting data item identifier between the triggering pre-image and the supplementary image.

[0132] exist In the case where the identifier of the preceding supporting data item differs from the identifier of the supplementary supporting data item, an inter-item replacement state is formed: ,in This indicates the inter-item substitution component corresponding to offset item p. The inter-item substitution state is used to characterize that the replacement support data item in the supplementary image and the replaced preceding support data item in the trigger preceding image are under the same bearing purpose, and the two form a substitution relationship through the different support data item identifier.

[0133] In the above formula, , , Both are status variables, with values ​​of 0 or 1; the supporting data item identifier and the carrier destination marker are used for consistency and dissimilarity checks. The server determines the carrier destination before determining the supporting data item identifier, ensuring that subsequent intra-item carrier components and inter-item replacement components are all under the same authorized supporting destination. Data with similar names, similar fields, and the same authorized supporting destination belong to different levels, and the server prioritizes their aggregation at this stage according to the carrier destination marker.

[0134] Reference Figure 4 In the mirrored offset section, the upper region corresponds to the intra-item carrying component, the middle region corresponds to the inter-item replacement component, and the lower region corresponds to the offset item index. When the preceding sequence support data item and the supplementary support data item have the same carrying purpose and the support data item identifier is the same, the server writes the relationship corresponding to the candidate offset item into... Figure 4 The upper-level item carries over the component; when the preceding supporting data item and the supplementary supporting data item carry the same purpose, and the supporting data item identifiers are different, the server writes the relationship corresponding to the candidate offset item. Figure 4 Inter-item substitution components in the middle layer. Figure 4 The layered representation in the image indicates the data carrying area for different support bearing relationships of the mirror offset section.

[0135] exist The server determines that the supporting data item in the supplementary image corresponds to the same supporting data item identifier as the supporting data item in the preceding image, and that both correspond to the same bearer destination. The server generates a support bearer continuation relationship from the preceding supporting data item, the supplementary supporting data item, the supporting data item identifier, the bearer destination marker, the node sequence of the preceding image, the node sequence of the supplementary image, the supporting role marker, and the reference pair identifier. The support bearer continuation relationship is used to express the continuation of the trust support relationship for the same supporting data item between preceding and following images.

[0136] The server generates intra-item support components based on the support bearing continuation relationship. Intra-item support components include offset item identifier, preceding support data item identifier, supplementary support data item identifier, bearing destination marker, support bearing continuation relationship identifier, triggering preceding mirror node sequence, supplementary mirror node sequence, support function marker, and reference pair identifier. Intra-item support components generate positive anchoring conditions in subsequent bearing condition data and enter the positive bearing anchoring process.

[0137] exist At that time, the server determines that the supporting data items in the supplementary image correspond to different supporting data item identifiers in the preceding image, and that both correspond to the same bearing purpose. Based on the supplementary trigger status, data gaps, approval comments, review records, external verification receipts, data citation purpose, bearing purpose marker, and reference pair identifier, the server identifies the bearing transfer relationship between the supplementary supporting data items and the preceding supporting data items. The bearing transfer relationship is used to express that the replacement supporting data item forms a bearing transfer to the replaced preceding supporting data item under the same credited supporting purpose.

[0138] The supporting bearer transfer relationship includes the identifier of the preceding supporting data item being replaced, the identifier of the replacing supporting data item, the bearer destination marker, the supplementary document trigger status marker, the trigger approval node sequence, the supplementary document submission node sequence, the data reference purpose, the transfer source identifier, and the transfer basis identifier. The transfer basis identifier originates from the supplementary document trigger opinion, data gap marker, external verification receipt, review record, or approval opinion. The server generates inter-item replacement components from the supporting bearer transfer relationship. The inter-item replacement components include the offset item identifier, the identifier of the preceding supporting data item being replaced, the identifier of the replacing supporting data item, the bearer destination marker, the supporting bearer transfer relationship identifier, the supplementary document trigger status marker, the mirror node sequence identifier, and the reference pair identifier. The inter-item replacement components generate reverse tracing conditions in the subsequent bearer condition data and enter the reverse overlay tracing processing.

[0139] In scenarios where a preceding supporting data item is replaced by multiple supplementary supporting data items, the server generates multiple candidate offset items based on the same supplementary trigger state, the same bearer destination marker, and the same mirror node sequence identifier. When multiple candidate offset items point to the same preceding supporting data item or the same bearer destination, the server merges these multiple candidate offset items under the same offset item identifier. The merged offset item retains the identifiers of multiple replacement supporting data items and the identifier of the same replaced preceding supporting data item, which is used for subsequent reverse overwrite tracing.

[0140] In scenarios where multiple preceding supporting data items are replaced by a single comprehensive supplementary supporting data item, the server generates candidate offset items based on the identifier of the replaced preceding supporting data item, and merges them according to the same supplementary supporting data item identifier, the same carrying purpose marker, and the same supplementary trigger status. The merged offset items retain the set of replaced preceding supporting data items, the identifier of the replaced supporting data item, and the carrying purpose marker. This process is suitable for scenarios such as comprehensive verification receipts, comprehensive business transaction records, comprehensive guarantee materials, and comprehensive review opinions. When multiple old supporting materials are covered by a new comprehensive material, the system still retains the source of each preceding supporting point.

[0141] After offset entries are merged, the server maintains a unique location using the offset entry identifier, the bearer destination marker, and the mirror node sequence identifier. The offset entry identifier identifies the offset entry itself, the bearer destination marker defines the corresponding trust support purpose, and the mirror node sequence identifier indicates the offset entry's position in the trust mirror sequence. The merged result is written to the offset entry candidate table and then processed in the offset entry index generation process.

[0142] Reference Figure 4 After multiple intra-item components and inter-item replacement components enter the mirror offset section, they are all attached to the lower-level offset item index. Figure 4 The offset index is located at the bottom of the mirror offset section, serving as a unified ridge for intra-item bearing components and inter-item substitution components. Bearing relationships, substitution relationships, bearing purpose markers, and mirror node positions are indexed on this ridge, and subsequent bearing condition data, bearing closure data, and remodeling boundary data all continue along this index.

[0143] The server generates an offset index for offset item p. The offset index includes an offset identifier, a mirror node sequence identifier, a preceding supporting data item identifier, a complement supporting data item identifier, a carrier destination marker, an offset type identifier, a data version association identifier, a reference pair identifier, and a section identifier. The offset identifier identifies the offset item formed by an intra-item successor component or an inter-item substitution component. The mirror node sequence identifier identifies the mirror node sequence of this offset item in the authorized mirror sequence. The offset type identifier distinguishes between intra-item succession and inter-item substitution. The data version association identifier expresses the version association between the data version corresponding to the triggering preceding mirror and the data version corresponding to the complement mirror. The reference pair identifier traces the source of the mirror reference pair.

[0144] The server establishes an index association between the offset item index and the intra-item supporting component. This index association includes the offset item identifier, the intra-item supporting component identifier, the supporting load continuation relationship identifier, the load destination marker, the preceding mirror node sequence, and the complement mirror node sequence. The server also establishes an index association between the offset item index and the inter-item replacement component. This index association includes the offset item identifier, the inter-item replacement component identifier, the supporting load transfer relationship identifier, the load destination marker, the complement trigger status identifier, the preceding mirror node sequence, and the complement mirror node sequence.

[0145] The server consists of an offset item index and the intra-item continuation components and inter-item substitution components associated with the offset item index, forming a mirrored offset section. The mirrored offset section includes an offset item index area, an intra-item continuation component area, an inter-item substitution component area, a carrier destination marker area, a mirror node sequence area, a reference pair source area, a data version association area, and a support function status entry area. The offset item index area carries the offset item identifier and the mirror node sequence identifier; the intra-item continuation component area carries the support carrier continuation relationship; the inter-item substitution component area carries the support carrier transfer relationship; the carrier destination marker area limits the same authorized support purpose; the mirror node sequence area retains the positions of the preceding and following mirror nodes; the reference pair source area is used to trace the supplementary mirror and trigger the preceding mirror; the data version association area retains the association between the preceding data version and the supplementary data version; and the support function status entry area is used for subsequent coverage verification to read the support function status of the preceding side and the supplementary side.

[0146] Reference Figure 4 The left-side preceding support mirror image provides preceding support data items to the central section. Figure 4 The right-side supplementary support mirrors and provides supplementary support data items to the central section. The server determines the support data items on both sides by using the bearing purpose mark and support data item identifier, and then writes them into the bearing component within the item or the replacement component between items, and establishes a unified association through the offset item index. Figure 4 The bearing condition data on the right is output from the central section, indicating that the bearing condition data comes from the association status between the intra-item bearing component, the inter-item substitution component, and the offset item index.

[0147] After the mirrored offset section is generated, the server configures a section identifier for it. The section identifier is associated with the reference pair identifier, offset item identifier, load-bearing purpose marker, and mirror node sequence identifier. The section identifier is used to subsequently track the source of the load-bearing condition data. The offset item index is used to maintain data consistency for the same offset item among load-bearing condition data, load-bearing closure data, reshaping boundary data, offset control assignment data, and supplementary component closure data. At this point, the relationship between the preceding support data item and the supplementary support data item has been transformed from a data object correspondence to a credited support offset section relationship.

[0148] Furthermore, the coverage condition data includes forward anchoring conditions, reverse tracing conditions, and offset item indexes. The forward anchoring conditions are generated from the intra-item coverage components aggregated by the offset item index according to the offset item identifier, and point to the coverage object field corresponding to the forward coverage anchoring. The reverse tracing conditions are generated from the inter-item substitution components aggregated by the offset item index according to the offset item identifier, and point to the tracing object field corresponding to the reverse coverage tracing. The coverage object field includes the supporting data items in the complement mirror pointed to by the intra-item coverage components and the original supporting data items in the triggering preceding mirror. The tracing object field includes the replacement supporting data items pointed to by the inter-item substitution components and the replaced preceding supporting data items.

[0149] The server generates bearing condition data based on the mirrored offset section. This bearing condition data includes bearing condition data identifiers, section identifiers, offset item indexes, forward anchoring conditions, reverse tracing conditions, bearing purpose markers, bearing object fields, tracing object fields, positional constraints, and support function status entries. This bearing condition data serves as the entry data for subsequent bidirectional bearing verification, providing object fields, condition fields, and merging indexes for both forward bearing anchoring and reverse cover tracing.

[0150] For the intra-item acceptance components, the server aggregates them according to the offset item identifier and generates positive anchoring conditions from the aggregated intra-item acceptance components. The positive anchoring conditions include the offset item identifier, the intra-item acceptance component identifier, the acceptance object domain, the bearing destination marker, the triggering pre-image node sequence, the complement image node sequence, the support function status entry, and the support bearing continuity identifier. The acceptance object domain includes the support data items in the complement image pointed to by the intra-item acceptance component and the original support data items in the triggering pre-image. The original support data items are the support data items in the triggering pre-image that have already formed a credit support function and participated in the positive acceptance judgment.

[0151] For inter-item substitution components, the server aggregates them according to the offset item identifier and generates reverse tracing conditions from the aggregated inter-item substitution components. The reverse tracing conditions include the offset item identifier, inter-item substitution component identifier, tracing object field, bearer destination marker, support bearer transfer relationship entry, triggering preceding mirror node sequence, complement mirror node sequence, complement trigger status identifier, and support function status entry. The tracing object field includes the replacement support data item pointed to by the inter-item substitution component and the replaced preceding support data item. The replacement support data item is the support data item in the complement mirror used to replace the preceding support data item, and the replaced preceding support data item is the support data item in the triggering preceding mirror that is replaced or overwritten by the complement data.

[0152] The server writes the forward anchoring conditions, reverse tracing conditions, and offset index into the same cover condition data. The forward anchoring conditions are used for subsequent forward cover anchoring, the reverse tracing conditions are used for subsequent reverse cover tracing, and the offset index is used to merge the two types of verification results into the same offset. After the cover condition data is generated, the server sends it to the bidirectional cover verification processing procedure.

[0153] Reference Figure 4 The intra-item bearing component provides positive anchoring conditions to the bearing condition data, the inter-item substitution component provides reverse tracing conditions to the bearing condition data, and the offset item index provides a merging benchmark to the bearing condition data. Thus, the supporting data items in the mirror reference pair are transformed into two processing directions: positive bearing and reverse tracing, and the data association under the same offset item is maintained through the offset item index and bearing destination marker. Bearing condition data enters... Figure 5The bidirectional cover verification shown corresponds to the receiving object domain and the cause-tracing object domain entering the forward receiving anchor verification cavity and the reverse cover cause-tracing verification cavity, respectively.

[0154] In one embodiment, bidirectional coverage verification includes forward acceptance anchoring and reverse coverage tracing. The forward acceptance anchoring result includes an acceptance anchoring relationship constructed from intra-item acceptance components in the acceptance object domain, and an acceptance closure state configured within the acceptance anchoring relationship and determined by the support bearing continuity relationship. The reverse coverage tracing result includes a coverage tracing relationship constructed from inter-item substitution components in the tracing object domain, and a coverage attribution state and a coverage closure state configured within the coverage tracing relationship and determined by the support bearing transfer relationship. The server uses the offset item index as the merging basis to merge the forward acceptance anchoring result and the reverse coverage tracing result into the same offset item, forming coverage closure data including the acceptance closure state and the coverage closure state.

[0155] Reference Figure 5 The data on bearing conditions is located at Figure 5 On the left, the offset index is located at Figure 5 The middle section forms a vertical ridge. The internal components then enter... Figure 5 The upper positive receiving anchoring verification cavity, the inter-item replacement component enters Figure 5 The reverse overlay cause verification chamber below. The forward acceptance anchoring verification chamber outputs the acceptance closed state, and the reverse overlay cause verification chamber outputs the overlay closed state. Both states are merged to the right into the acceptance closed data. Figure 5 The reverse overlay tracing verification chamber is configured with a foldback tracing direction to represent the internal tracing path from the replaced supporting data item back to the preceding supporting data item; the overlay closure state is still output along the overlay closure data direction. Therefore, Figure 5 Expresses the checksum and merging process under the same offset item.

[0156] The server receives the bearing condition data and reads the positive anchoring conditions based on the offset item index in the bearing condition data. The positive anchoring conditions are generated by the bearing component within the item in the mirrored offset section. The positive anchoring conditions include the offset item identifier, the bearing component identifier within the item, the bearing object domain, the bearing purpose marker, the triggering pre-image node sequence, the supplementary image node sequence, the support action status entry, and the support bearing continuity relationship identifier.

[0157] The receiving object domain includes the original supporting data items in the triggering preceding image and the supporting data items in the complement image, both pointed to by the receiving component within the item. The server reads the preceding supporting data items from the receiving object domain. Supporting documents for supplementary materials The server reads the preceding support data item identifier, the supplementary support data item identifier, and the carrying purpose marker. Simultaneously, it reads the in-item carrying status corresponding to this offset item. The internal bearing status originates from the aforementioned mirror offset section, indicating that the preceding support data item and the supplementary support data item are for the same bearing purpose and correspond to the same support data item identifier.

[0158] The server constructs the acceptance anchoring relationship based on the acceptance components within the item. The acceptance anchoring relationship includes the preceding supporting data item, the supplementary supporting data item, the identifier of the same supporting data item, the bearing purpose marker, the supporting bearing continuation relationship, the triggering preceding mirror node sequence, and the supplementary mirror node sequence. This acceptance anchoring relationship is used to express the continuation of the same supporting data item along the same authorized supporting purpose between the triggering preceding mirror and the supplementary mirror. In business processing, this step checks whether the data item that originally played a supporting role continues to the next mirror node with the same supporting purpose after supplementation.

[0159] Let the order of the pre-triggered image and the supplementary image in the authorized image sequence be: ,in This indicates the position of the image node corresponding to the triggered preceding image. This indicates the positional order of the mirror node corresponding to the supplementary support image. The states of whether the preceding supporting data item and the supplementary support data item form a credit support function are recorded as follows: ,in This indicates that the preceding support data item corresponding to offset term p provides credit support in triggering the preceding mirroring. This indicates that the supplementary supporting data item corresponding to offset item p forms a credit support function in the supplementary image. The server determines this based on the credit support record, support function marker, approval log data, verification receipt or review record. and Among them, the submission status of the data in the supplementary image is related to... Layered recording; the server uses the supplementary support data item's entry into the credit support mirror state as... The basis for its value.

[0160] The positive continuation closed state is represented as: ,in This indicates that the offset term p forms a closed connection state in the positive connection direction; This indicates the component within the term corresponding to the offset term p; This is used to indicate that the complement image is located after the preceding image in the image node sequence. The server will... Together with the mirror positional condition, it serves as the criterion for determining the closed state of acceptance, so that the forward acceptance anchoring is simultaneously constrained by three types of factors: data item continuation, credit support, and positional relationship.

[0161] The positive anchoring result is expressed as follows: ,in This indicates the positive anchoring result of the offset term p. This indicates the anchoring relationship constructed by the components within the item. This indicates a closed state. The server will... Write the forward bearing result area of ​​the bearing closure data, and simultaneously write the offset item identifier, bearing destination mark, trigger preceding mirror node position and supplement mirror node position.

[0162] Reference Figure 5 The component within the item enters the upper positive anchoring verification cavity from the merging ridge defined by the offset item index. This verification cavity reads the bearing object domain, the support bearing continuity relationship, and the mirror node position, and outputs the bearing closure status. Figure 5 The above path expresses positive continuation confirmation: the same supporting data item continues from the triggering pre-image to the supplementary image, and forms a credit support function in the supplementary image.

[0163] The server performs reverse overwrite tracing on the inter-item replacement components in the tracing object field based on the reverse tracing conditions in the overwrite condition data. The reverse tracing conditions include the offset item identifier, the inter-item replacement component identifier, the tracing object field, the bearer destination marker, the support bearer transfer relationship entry, the triggering preceding mirror node sequence, the complement mirror node sequence, the complement trigger status identifier, and the support function status entry. The tracing object field includes the replacement support data item and the replaced preceding support data item.

[0164] The server reads the replaced preceding support data item from the cause-finding object domain. Replace supporting data items The server reads the identifier of the preceding supporting data item, the identifier of the replacing supporting data item, and the destination marker. The server also reads the inter-item replacement status corresponding to this offset item. The item replacement status originates from the aforementioned mirror offset section, indicating that the preceding support data item and the supplementary support data item are for the same load-bearing purpose and correspond to different support data item identifiers.

[0165] The server constructs a coverage tracing relationship based on inter-item substitution components. This relationship includes the replacement supporting document item in the supplementary document image, the replaced preceding supporting document item in the triggering preceding image, the carrier destination marker, the supporting carrier transfer relationship, the supplementary document triggering status, the triggering approval node sequence, and the supplementary document submission node sequence. The coverage tracing relationship is used to express how the replacement supporting document item, under the same credit support purpose, forms a source tracing back to the replaced preceding supporting document item. For example, if the preceding document uses contract documents to support the purpose of funds, and the supplementary document uses invoices and verification receipts to support the purpose of funds, the server tracks the preceding supporting document items covered by the invoices and verification receipts.

[0166] Let the set of support load transfer relationships from the pre-triggered mirror-side support data item to the complement mirror-side support data item be: ,in This set is composed of approval log data, document citation relationships, supplementary document triggering opinions, document gap markers, external verification receipts, review records, and carrier purpose markers. Each relationship in this set includes a preceding supporting document item, a supplementary supporting document item, a carrier purpose marker, a transfer source identifier, a supplementary document triggering status identifier, a triggering approval node sequence, and a supplementary document submission node sequence. The server uses this set to determine whether the replacement supporting document item and the replaced preceding supporting document item form a support carrier transfer source under the same credit support purpose.

[0167] The coverage attribution state is represented as: ,in This indicates that the supplementary support data item corresponding to the offset item p can be traced back to the previous support data item being replaced under the same load-bearing purpose, forming a coverage attribution state; This indicates the substitution component between items corresponding to offset item p; This indicates that the relationship between the preceding supporting data item, the supplementary supporting data item, and the supplementary side bearing target marker exists in the supporting bearing transfer relationship set. The coverage attribution status is used to express that the replacement source has been located in the credit transfer data.

[0168] The covered closed state is represented as: ,in This indicates that offset item p forms a coverage closure state in the reverse coverage tracing direction. The server writes the coverage attribution state and coverage closure state hierarchically into the reverse coverage tracing results. The coverage attribution state indicates that the replacement source has been traced back to the preceding supporting data item being replaced, and the coverage closure state indicates that coverage attribution, preceding credit support, supplementary credit support, and mirror node position have all met the closure condition. This hierarchical structure adapts to the intermediate state of "replacement source located, supplementary data support still under review".

[0169] The reverse coverage tracing result is represented as follows: ,in This represents the reverse coverage tracing result of offset term p. This represents a covering causal relationship constructed from the substitution components between terms. Indicates the coverage attribution status. This indicates the overlay is closed. The server will... Write the reverse overlay result area of ​​the overlay closure data, and simultaneously write the offset item identifier, the bearer destination marker, the overlay attribution status, the overlay closure status, and the mirror node position identifier.

[0170] Reference Figure 5 The inter-item replacement component enters the lower reverse cover cause-finding check cavity from the merge ridge defined by the offset item index. Figure 5The foldback line inside the reverse coverage tracing verification chamber indicates that the tracing direction is from the replacement support data item back to the previous support data item being replaced; the right side of this verification chamber outputs the coverage closure state, which, together with the upper receiving closure state, enters the coverage closure data. Therefore, Figure 5 This forms a verification structure that involves internal reverse tracing and external merging.

[0171] The server uses the offset index as the merging criterion, merging the forward anchoring results and the reverse coverage tracing results into the same offset, forming the coverage closure data. The coverage closure data includes the offset identifier, the coverage destination marker, the offset index, the forward anchoring results, the reverse coverage tracing results, the coverage closure status, the coverage tracing status, the coverage imbalance status, the reference pair identifier, and the mirror node position identifier.

[0172] Offset indexes are used as the main merge field in the cover closure data. The server looks up the corresponding offset index. and And write both into the same bearing closure data unit. Bearing closure state Indicates the closing result of the direction of succession within the item, covering the closing state. This indicates the closure result of the replacement direction between items. The bearing closure data retains the results of both directions within the same data unit, providing a unified entry point for subsequent bearing breakpoint item extraction.

[0173] The state of load-bearing imbalance is represented as: ,in This indicates that the offset term p has both an unclosed state in terms of its connection and coverage closure states, and this offset term is identified as a connection / coverage breakpoint term. This indicates that offset item p follows the existing covered closed path into the subsequent closure update process. The server will... Write the load-bearing imbalance status field into the load-bearing closure data, and... The offset item is written into the set of bearing breakpoint items.

[0174] The bearer-overcoming breakpoint is determined jointly by the forward bearer-overcoming anchoring result and the reverse coverage tracing result. The server reads the bearer-overcoming closure state and the coverage closure state under the same offset index and generates the bearer-overcoming imbalance state accordingly. This process makes the bearer-overcoming breakpoint appear as a breakpoint after bidirectional bearer-overcoming verification. In this process, data replacement is used to trigger bearer-overcoming verification; when the forward continuation relationship and the reverse tracing relationship of the same offset jointly enter the pending closure state, the server determines the offset as the bearer-overcoming breakpoint.

[0175] Reference Figure 5The receiving closure state and the covering closure state are output from the upper and lower verification cavities respectively, and merged into the receiving / covering closure data on the right side. The same offset term in the receiving / covering closure data carries both positive and negative results. (Refer to...) Figure 7 The bearing closure curve decreases near the breakpoint sequence, and the bearing imbalance curve forms a peak segment near this sequence. This peak segment corresponds to the sequence delimitation entry of the subsequent bearing breakpoint item.

[0176] Furthermore, the extraction of the bearing breakpoint item includes: when both the bearing closure state and the coverage closure state are not closed, a bearing imbalance state is formed, and the offset item associated with the bearing imbalance state is identified as the bearing breakpoint item. Reshaping and delimitation includes: determining the position of the bearing breakpoint item in the credit mirror sequence and the mirror node where the bearing breakpoint item is located based on the mirror node position identifier in the offset item index corresponding to the bearing breakpoint item; determining the reshaping starting mirror based on the mirror node where the bearing breakpoint item is located; determining the replaced preceding support mirror and the replacement support data item corresponding to the bearing breakpoint item along the mirror node position, using the position position as the delimitation reference, thus forming the reshaping and delimitation data. The preceding support locking data is formed from the reshaping and delimitation data and includes the mirror identifier and locking reference state of the replaced preceding support mirror, and the replaced preceding support mirror is configured as the locking reference object in subsequent application control.

[0177] Based on the mirror node position identifier in the offset index corresponding to the bearing breakpoint item, the position of the bearing breakpoint item in the authorized mirror sequence is determined. The position is used to characterize the node position of the bearing breakpoint item in the authorized mirror sequence. The server further determines the mirror node where the bearing breakpoint item is located, and determines the remodeling starting mirror based on the mirror node. The remodeling starting mirror is the data mirror carried by the mirror node where the bearing breakpoint item is located, or the data mirror associated with the bearing breakpoint item in the supplementary mirror.

[0178] Let the positional identifier of the mirror node corresponding to offset term p be: Let the set of supporting data items in the v-th mirror node be: ,when When the preceding support image is replaced, the locking bit sequence is represented as: ,in This indicates the locked position of the replaced preceding support image in the trusted image sequence. This formula means that the server searches forward along the image node position to find the data item still carrying the preceding support. The nearest mirror node is used as the locking boundary. The bit sequence corresponding to the preceding mirror is triggered. As a delimitation reference, it enters the set so that the reshaping delimitation falls within the range of the preceding support that generates the supplementary trigger state.

[0179] The server determines the preceding supporting mirror to be replaced by following the pixel order of the mirror nodes, using the pixel position as a boundary reference. The preceding supporting mirror to be replaced is the locked pixel order. The corresponding mirror node carries the trusted support image. The server also determines the replacement support data item corresponding to the breakpoint item. The replacement support data item comes from the supplementary support data item in the supplementary image, and is corresponding to the replacement component between items. The server consists of reconstructed breakpoint identifiers, positional endpoints, reconstructed starting image identifiers, replaced preceding support image identifiers, replaced support data item identifiers, and locked positional sequence to form reconstructed boundary data.

[0180] The locked reference state is represented as: ,in This indicates that the v-th mirror node is configured as the locked reference object corresponding to offset p. The locked reference object is the replaced preceding support mirror that maintains a reference relationship in subsequent application control. The server generates preceding support locking data for the replaced preceding support mirror based on the locking bit order and locking reference status. The preceding support locking data includes the mirror identifier of the replaced preceding support mirror, the locking reference status, the locked reference object, the locking bit order, the corresponding offset item identifier, and the bearer destination marker.

[0181] Reference Figure 6 , Figure 6 The bottom shows the mirror node sequence axis, divided into the preceding support area, trigger sequence, replacement sequence, and subsequent sequence. The bearing breakpoint item falls on the remodeling starting mirror via a vertical demarcation pin. A remodeling demarcation wedge region is formed from the remodeling starting mirror in the forward direction, and this wedge region hits the replaced preceding support mirror. The replaced preceding support mirror is indicated by a clamping boundary, signifying preceding support locking, and the replacement support data item is marked on the replacement sequence side. Figure 6 Placing the breakpoint item, positional landing point, reshaping starting mirror, replaced predecessor support mirror, replaced support data item, and predecessor support lock in the same positional graph indicates that this process belongs to positional reshaping and delimitation process.

[0182] Furthermore, the offset control assignment data includes a control object field, a lock reference field, a control action field, and a write-back field. The control object field and the lock reference field together define the lock reference state between the control object in the target financial application and the replaced preceding support mirror. The control action field is determined by the reshaping starting mirror, the replaced preceding support mirror, and the replacement support data item in the reshaping and delimitation data. The write-back field points to the write-back mirror node of the supplementary closure data in the credit mirror sequence. The server executes the application control action corresponding to the reshaping and delimitation data according to the offset control assignment data, forming the application control result. The application control result is used to update the coverage closure data, forming supplementary closure data. The supplementary closure data includes the supplementary closure status, the corresponding offset item identifier, and the lock reference status. The supplementary closure data is written back to the write-back mirror node, and the lock reference state corresponding to the preceding support lock data is maintained during the write-back of the supplementary closure data to update the credit support record for subsequent credit mirror offset verification.

[0183] Offset control assignment data is generated based on the redefined delimitation data and preceding support locking data. The offset control assignment data includes fields for the controlled object, lock reference, control action, and write-back.

[0184] The control object field is determined by the bearing breakpoint item, replacement support data item, target financial application identifier, offset item identifier, bearing purpose marker, and bearing imbalance status. The control object field indicates the offset object and supplementary support object to which the current application control action is directed. The control object field includes the application identifier, offset item identifier, bearing breakpoint item identifier, replacement support data item identifier, bearing purpose marker, and bearing imbalance status.

[0185] The lock reference field is determined by the preceding support lock data, the identifier of the replaced preceding support image, the lock reference status, the lock position, and the lock reference object. The lock reference field indicates the preceding support image that will continue to be referenced during the control request process. The lock reference field includes the identifier of the replaced preceding support image, the lock position, the lock reference status, the corresponding offset item identifier, and the carrier destination flag. This field carries the reference basis of the replaced preceding support image in subsequent review, re-verification, or external verification calls. In other words, the system incorporates the previously active support points into the current control action before processing the current supplementary data.

[0186] The control action field is determined by the reshaping starting mirror, the replaced preceding support mirror, the replaced supporting data item, and the support imbalance status in the reshaping and demarcation data. The control action field indicates the type and processing path of the application control action. Application control actions include manual review, automatic review, loan disbursement blocking, credit support item re-verification, external verification call, generation of supplementary document closure prompts, maintenance of preceding support references, or transfer to the review and approval node. Specific action names, approval flow node names, and system interface names are determined based on the financial institution's internal business system configuration.

[0187] The write-back field is determined by the mirror node corresponding to the supplementary document mirror, the write-back mirror node specified in the application control result, or the write-back node position in the authorized mirror sequence. The write-back field is used to indicate the position where the supplementary document closure data is written into the authorized mirror sequence. The write-back field includes the write-back mirror node identifier, write-back node position, write-back data type, and write-back status field.

[0188] Reference Figure 6 The reshape delimitation region and the preceding support locking region are jointly incorporated into the offset control assignment data. The reshape delimitation region provides the reshape starting image, the replaced preceding support image, and the replaced support data items, while the preceding support locking region provides the locked reference object and the locked reference status. Figure 6 The offset control assignment data on the right is used to express that the requested control action is driven by both the reshaping and delimitation results and the preceding support locking results.

[0189] The application control action is executed according to the offset control assignment data, forming the application control result. The application control result includes the application control action identifier, execution node identifier, execution status, review result, external verification call result, re-verification result, locked reference status, closure update result, and write-back mirror node identifier. The application control result is used to perform closure update on the overlay closure data.

[0190] Closure updates include: updating the overlay imbalance status to a processed status; updating the overlay attribution status to attributed, transferred for review, or pending further verification; updating the overlay closure status to closed or pending processing; updating the overlay closure status to closed or pending processing; maintaining, transferring, or releasing the locked reference status; and writing the complement closure status to the corresponding offset. All of these update actions are performed around the offset index, ensuring that the overlay closure data and the complement closure data maintain the same offset source.

[0191] After the closure update, the server generates supplementary closure data. This supplementary closure data includes the supplementary closure status, the corresponding offset identifier, the bearing destination marker, the locked reference status, the write-back mirror node identifier, the application control result identifier, and the update time. The supplementary closure status expresses the closure result of the bearing breakpoint item after the application control action. The offset identifier ensures that the supplementary closure data maintains the same index source as the mirror offset section, bearing condition data, and bearing closure data. The locked reference status expresses the reference maintenance status of the replaced preceding support mirror after write-back.

[0192] The server determines the write-back mirror node based on the write-back field in the offset control dispatch data. The write-back mirror node is the mirror node where the supplementary component mirror resides, the mirror node where the request control action was completed, the mirror node corresponding to the verification node, or the mirror node corresponding to the breakpoint item. The server writes the supplementary component closure data back to the write-back mirror node, maintaining the locked reference state corresponding to the preceding support lock data during the write-back process. After the write-back is completed, subsequent credit mirror offset verification continues to reference the credit support record corresponding to the replaced preceding support mirror.

[0193] Reference Figure 7 The bearing closure curve decreases near the breakpoint sequence, the bearing imbalance curve reaches its peak near the breakpoint sequence, and the lockout response curve rises after the breakpoint sequence and enters a plateau. Figure 7 The breakpoint sequence corresponds to the location where the bearing breakpoint item is formed, and the platform segment of the locked response curve corresponds to the maintenance of the locked reference state of the preceding support locked data. This graphical relationship is used to illustrate the state succession relationship between the supplementary document closure write-back and the preceding support locking: the bearing breakpoint item triggers the preceding support locking, the application control result forms the supplementary document closure data, and after the supplementary document closure data is written back, the corresponding locked reference state continues to be maintained. While the system processes the current supplementary document, it locks the previously effective preceding support data according to the sequence, and subsequent approval nodes continue to perform verification along the same support chain.

[0194] In one implementation, in scenarios involving one-to-one, one-to-many, many-to-one, or multiple batches of supplementary documents, the same offset item index permeates the mirror reference pair, mirror offset section, bearing condition data, bearing closure data, reshaping boundary data, preceding support locking data, offset control assignment data, and supplementary document closure data. After the supplementary document closure data is written back to the credited mirror sequence, the supplementary document closure status, offset item identifier, and lock reference status continue to be associated with the credited support record, enabling subsequent credited mirror offset verification to trace support data items, support function markers, and approval trace data along the offset item index.

[0195] In complex supplementary document scenarios, the server uses the offset item index as the delivery benchmark. The offset item index is generated from the mirror offset section, forward from the supporting data items, supporting data item identifiers, and carrying purpose markers in the mirror reference pair, and backward from the covering condition data, covering closure data, reshaping and demarcation data, preceding support locking data, offset control allocation data, and supplementary document closure data. This index starts from the entry of the supporting data item into the mirror offset section and continues until the supplementary document is closed and written back. In actual financial approvals, supplementary documents are often transmitted separately, in batches, or with different materials; the offset item index is used to bring these scattered actions back to the main line under the same credit support purpose.

[0196] In a one-to-one complement relationship, a complement support data item in the complement mirror corresponds to a preceding support data item in the preceding mirror. The server generates candidate offset items based on the preceding support data item identifier, the complement support data item identifier, the bearing destination marker, and the mirror node position identifier, and further generates an offset item index. After the offset item index enters the mirror offset section, it generates intra-item bearing components according to the same relationship of the support data item identifiers, or generates inter-item replacement components according to the different relationship of the support data item identifiers, and generates bearing condition data from these components.

[0197] In a one-to-many complement relationship, a preceding supporting data item is jointly undertaken or replaced by multiple complement supporting data items. The server generates multiple candidate offset items based on the same complement triggering state, the same carrying destination marker, and the same mirror node position identifier. When multiple candidate offset items point to the same preceding supporting data item or the same carrying destination, the server merges these multiple candidate offset items into the same offset item index. The merged offset item index records the identifiers of multiple complement supporting data items, the identifier of the same replaced preceding supporting data item, the same carrying destination marker, and the corresponding complement submission node position. After this offset item index enters the coverage condition data, multiple complement supporting data items together constitute the receiving object field or the tracing object field of the same offset item.

[0198] In a many-to-one supplementary document relationship, multiple preceding supporting data items are taken over or replaced by a single comprehensive supplementary supporting data item. The server generates candidate offset items based on the identifier of the replaced preceding supporting data item, and merges them according to the same supplementary supporting data item identifier, the same supplementary trigger status, and the same carrier destination marker. The merged offset item index records the set of replaced preceding supporting data items, the identifier of the replaced supporting data item, the carrier destination marker, and the order of the supplementary mirror node. This process is suitable for business scenarios such as comprehensive business transaction records, comprehensive verification receipts, comprehensive guarantee materials, and comprehensive review opinions. When multiple preceding supporting points are covered by a single comprehensive document, the system still retains the source of each preceding supporting point, which is crucial for subsequent cause tracing.

[0199] In a multi-batch supplementary document relationship, the same supplementary document triggering state corresponds to multiple supplementary document submission nodes. The server generates supplementary document images according to the supplementary document submission nodes, and forms multiple sets of mirror reference pairs based on the mirror node position of each supplementary document submission node in the trusted mirror sequence. After each batch of supplementary documents enters the mirror reference pair, the server generates corresponding candidate offsets, and cumulatively updates the candidate offsets of each batch using the offset identifier, the carrier destination marker, and the mirror node position identifier as merging conditions.

[0200] During the cumulative update process across multiple batches, the offset indexes generated by previous batches of supplementary documents are retained in the mirrored offset section. After subsequent batches of supplementary documents enter the credit support mirror, the server reads the existing offset indexes under the same supplementary document trigger state and the same bearing destination marker, and appends the support data items of the subsequent batches of supplementary documents to the supplementary document-side support data item set corresponding to that offset index. After the supplementary document data of the subsequent batches forms credit support, the server updates the status of the supplementary document support data item corresponding to that offset index. Through this cumulative update process, the supplementary document data submitted in batches continuously participates in the bearing verification around the same preceding support relationship.

[0201] Reference Figure 2 Multiple batches of replacement documents form multiple replacement document sequences in the credit mirror sequence. Each replacement document sequence establishes a mirror reference relationship with the corresponding trigger sequence through the replacement document trigger association. Figure 2 The trigger bit sequence provides the source of preceding support, and the component bit sequence provides the source of component support. (Refer to...) Figure 4 After multiple candidate offset items formed by one-to-many, many-to-one, and multiple batches of replacement parts enter the mirror offset section, they are all merged through the offset item index. Figure 4 The offset index in the section serves as the merging ridge within the cross section, maintaining data consistency among candidate offsets for the same bearing purpose.

[0202] If supplementary supporting documents have been submitted and the credit support function is in a pending state, the server generates a supplementary document image based on the submission node and records the document version status in the supplementary document image. After the supplementary documents are included in the document image, the server continues to wait for approval traces, verification receipts, or review records to mark the supplementary documents as having a supporting function. The credit support function status of the supplementary supporting document item is based on the supporting function extraction result. The server will update the status of the supplementary supporting document item. Write the support function status entry into the bearing condition data, and follow the instructions. Participate in positive anchoring and reverse coverage tracing.

[0203] The submission status of supplementary documents and the credit support status of supporting documents are recorded hierarchically. Submission of supplementary documents establishes a document version status, while credit support establishes a support status. The server reads this information during the forward acceptance anchoring process. and participate The generation of the data is read in the reverse overwrite tracing. and participate The generation of supplementary documents is thus achieved. This creates a continuous processing chain encompassing the entry of supplementary documents into the database, verification of supplementary documents, review of supplementary documents, and the formation of supplementary documents to support credit authorization.

[0204] Reference Figure 3 After the supplementary documents are entered into the document mirror, they are marked with a supporting role through approval records, verification receipts, or review records, and are associated with the document version status before entering the credit support mirror. Figure 3 The support layer in the diagram is used to represent this process. (See reference...) Figure 5 Status of supplementary supporting data items As a supporting state entry point for both forward acceptance anchoring and reverse coverage tracing, it participates in the formation of acceptance closure and coverage closure states. After this processing, the submission of supplementary data and the credit support closure results remain layered at the data level.

[0205] In scenarios where the bearer destinations differ, the server will group the preceding support data items and the supplementary support data items into a different bearer destination processing group. A consistent bearer destination status is indicated as follows: ,when and When assigning different credit support purposes, the server writes the corresponding candidate offsets into the credit support purpose group reconstruction queue and regenerates the candidate offsets according to the credit support purpose markers. The reconstructed candidate offsets are then assigned to different credit support purpose processing groups, such as revenue authenticity, operational stability, fund usage, transaction background, guarantee conditions, access rules, or risk review. Each processing group independently forms a corresponding offset index. Thus, the reference relationships formed by the same data object under different credit support purposes are grouped and supported.

[0206] Reference Figure 4 Before supporting data items enter the mirror offset section, the server first reads the bearing destination marker. Supporting data items with the same bearing destination marker enter the intra-item continuation component or inter-item replacement component under the same offset item index; supporting data items with different bearing destination markers enter the corresponding bearing destination processing group and form the corresponding candidate offset items. Figure 4 The mirror offset section in the middle therefore undertakes three processing tasks: bearing the purpose of grouping, component writing, and index merging.

[0207] In the write-back scenario, when a request control action generates a review node, the server writes back the supplementary closure data to the mirror node corresponding to the review node. When the request control action completes along the supplementary node, the server writes back the supplementary closure data to the mirror node where the supplementary mirror is located. When a request control action generates an external verification call node, the server writes back the supplementary closure data to the mirror node associated with the external verification receipt or the mirror node corresponding to the review node. The write-back mirror node is determined by the write-back field in the offset control dispatch data. The write-back field includes the write-back mirror node identifier, write-back node order, write-back data type, and write-back status field.

[0208] When the supplementary closure data is written back to the authorized mirror sequence, the server retains the corresponding offset item identifier, bearing destination marker, supplementary closure status, locked reference status, application control result identifier, and update time. The offset item identifier is used to maintain the index relationship between the supplementary closure data and the mirror offset section, bearing condition data, and bearing closure data; the locked reference status is used to maintain the reference relationship between the replaced preceding support mirror and subsequent application control; the write-back mirror node identifier is used to determine the positional location where subsequent approval nodes read the supplementary closure data. When subsequent nodes see the supplementary closure result, they can find the previously locked support source by following the offset item index.

[0209] Reference Figure 7 The bearing closure curve fluctuates after the supplementary part sequence and decreases near the breakpoint sequence; the bearing imbalance curve forms a peak near the breakpoint sequence; the locking response curve rises after the breakpoint sequence and remains on a plateau. This function curve relationship is used to express that: during the review write-back or subsequent application control process, after the supplementary part closure data is written back to the corresponding write-back mirror node, the previous support locking state continues to serve as the locking reference basis for subsequent verification.

[0210] The aforementioned state succession relationship is represented as follows: ,in This indicates a state where the intended purpose is consistent. Indicates the continuation state within an item. Indicates the state of substitution between items. Indicates a closed state. Indicates the coverage attribution status. Indicates a closed state. Indicates a state of imbalance between load and support. This indicates the locking bit order of the preceding support image that was replaced. This indicates a locked reference state.

[0211] In this state transition relationship, the server first determines whether the preceding supporting data item and the supplementary supporting data item belong to the same credit support purpose based on the bearing purpose marker; then, it determines the intra-item acceptance state or inter-item replacement state based on the supporting data item identifier; subsequently, it generates the acceptance closure state, coverage attribution state, and coverage closure state respectively based on the credit support function state and the mirror node position sequence; when both directions are in the pending closure state, the acceptance / coverage imbalance state and the acceptance / coverage breakpoint item are formed; finally, the locking position sequence and locking reference state are determined along the mirror node position sequence. This transition relationship... Figure 4 , Figure 5 , Figure 6 and Figure 7 When processed in one step, the state of the previous step becomes the entry point for the next step.

[0212] Reference Figure 7 The corresponding closed curve of the bearing and The closed-loop behavior after merging; the corresponding bearing imbalance curve. The rising segment and peak segment formed after the component sequence and near the breakpoint sequence; corresponding to the locked response curve. and The response after the formation of the bearing fault term. Figure 7 The trigger bit sequence, complement bit sequence, and breakpoint bit sequence correspond to the mirror reference pair positioning, complement support entry, and bearing breakpoint item formation, respectively. The lock response curve forms a jump segment after the breakpoint bit sequence and enters the platform state in the subsequent mirror node bit sequence, indicating that the preceding support lock data continues to maintain the lock reference state after the complement closure write-back.

[0213] exist Figure 7 In the state transition shown, the bearing closure curve fluctuates after the supplementary component sequence and forms a decreasing range near the breakpoint sequence, indicating a weakening of the closure support for forward bearing anchoring or reverse coverage tracing. The bearing imbalance curve gradually rises after the supplementary component sequence and forms a peak near the breakpoint sequence, indicating that the bearing closure state and coverage closure state of the same offset term enter the pending state. The locking response curve jumps after the breakpoint sequence, indicating that the server forms preceding support locking data based on the bearing breakpoint term and configures the replaced preceding support image as the locked reference object. After the locking response curve enters the platform, the server maintains the locked reference state during the supplementary component closure data write-back. Figure 7 The bearing closure descent, bearing imbalance formation, preceding support locking response, and write-back maintenance state are expressed in the same mirror node position.

[0214] From the perspective of data flow relationships, the server forms a credit mirror sequence based on the credit flow data; determines a mirror reference pair based on the credit mirror sequence; generates a mirror offset section based on the mirror reference pair; generates bearing condition data based on the mirror offset section; performs bidirectional bearing verification based on the bearing condition data; generates bearing closure data based on the bidirectional bearing verification; extracts bearing breakpoint items based on the bearing closure data; forms reshaping and delimitation data based on the bearing breakpoint items; generates offset control allocation data based on the reshaping and delimitation data and the preceding support locking data; forms application control results based on the offset control allocation data; and forms supplementary closure data based on the application control results and writes it back to the credit mirror sequence.

[0215] During the state consistency check, the server performs a pass-through verification on the supplementary document closure data, offset item index, mirror reference pair, supporting data items, supporting function markers, and approval record data. Each supplementary document closure data is associated with its corresponding offset item index; each offset item index is associated with a supporting data item in the mirror reference pair; each supporting data item is associated with a supporting function marker in the credit support mirror; and each supporting function marker is associated with a record in the approval record data. This pass-through chain is used to maintain the consistency of data sources among the supplementary document closure data, the preceding support lock data, and the credit support records.

[0216] Reference Figure 3 , Figure 4 and Figure 7 , Figure 3 The supporting role markers in the data provide traceability of the source of credit support records; Figure 4 The offset index in the data provides an index trace between the mirrored offset section and the bearing condition data; Figure 7 The lock response platform in the middle represents the maintenance status of the preceding support lock data after the supplementary document closure write-back. Thus, the server traces along the path of "supplementary document closure data - offset index - support data item - support function mark - approval trace data".

[0217] In one status verification method, the server reads the offset item identifier in the supplementary closure data and matches the corresponding offset item index in the mirror offset section. If the match is successful, the server reads the mirror reference pair and supporting data item corresponding to the offset item index; if the match is in a pending confirmation state, the server configures the supplementary closure data to a pending verification state and writes the corresponding application control result into the review queue. The server reads the locked reference object in the preceding support locking data and matches the replaced preceding support image in the authorized mirror sequence. If the match is successful, the server maintains the locked reference state; if the match is in a pending confirmation state, the server maintains the locked reference state and triggers review processing. The server reads the coverage attribution state and supplementary closure state in the coverage closure data and performs a second closure update on the coverage closure data based on the application control result. The above verification actions are performed around the offset item index, locked reference state, and supplementary closure state, ensuring that the written-back authorized mirror sequence continues to serve as the basis data for subsequent offset verification.

[0218] During the closure process, the server updates the credit support record based on the supplementary document closure data. The updates include the supplementary document closure status, offset identifier, lock reference status, write-back mirror node identifier, and application control result identifier. The updated credit support record remains associated with the original support role marker and establishes a write-back association with the supplementary document closure data. When subsequent approval nodes read the credit support record, they simultaneously read the corresponding offset index and lock reference status. Therefore, subsequent credit mirror offset verification continues to be performed along the existing support chain in the subsequent flow of the same target financial application.

[0219] In terms of engineering implementation, the server, database, approval flow engine, message queue, cache, interface communication, permission verification, field mapping, data anonymization, encrypted transmission, log recording, scheduled tasks, and distributed storage are all implementation contents well known to those skilled in the art, and this article will not further elaborate on their underlying deployment details. Credit transfer data, credit mirror sequence, mirror reference pair, mirror offset section, bearing condition data, bearing closure data, reshaping and delimitation data, preceding support locking data, offset control assignment data, and supplementary closure data can be stored in relational databases, non-relational databases, distributed storage systems, object storage systems, or financial institution business middleware. The data objects are associated with each other through application identifiers, reference pair identifiers, offset item identifiers, mirror node position identifiers, and write-back mirror node identifiers. The above implementation content does not affect the understanding and implementation of the implementation method of this application.

[0220] The same or similar processing content between different implementation methods can be referred to each other. Trust mirror arrangement, mirror reference pair construction, acceptance replacement decomposition, offset item index generation, bidirectional acceptance verification, acceptance breakpoint item extraction, reshaping and delimitation, preceding support locking, and supplementary component closure writeback, according to the aforementioned implementation methods and... Figures 1 to 7The data transfer relationship shown is implemented.

[0221] In the above implementation, each processing step is described according to the logical succession relationship of credit flow data acquisition, credit mirror sequence formation, mirror reference pair construction, mirror offset section generation, coverage condition data generation, bidirectional coverage verification, coverage breakpoint item extraction, reshaping and delimitation, preceding support locking, offset control assignment, application control, and supplementary document closure and write-back. For processes with clear data dependencies, the data object formed by the previous process is used as input for the subsequent process; for processes where data dependencies are already satisfied, the server can perform parallel execution, asynchronous execution, or batch execution according to the approval flow configuration, task queue, message event, or batch processing strategy. The above-mentioned adjustment of the execution sequence does not change the source relationship, index relationship, and write-back relationship between the data objects.

[0222] Based on the description of the above embodiments of the financial application control method based on credit mirror offset verification, this application also discloses a financial application control system based on credit mirror offset verification. The system includes a processor, a memory, and program instructions stored in the memory and executed by the processor. When the processor executes the program instructions, it performs the aforementioned credit mirror sequence formation, mirror offset section construction, bidirectional coverage verification, reshaping boundary locking, and offset control write-back related processing. The system can also implement corresponding processing through software modules, hardware modules, or a combination of software and hardware functional units. (Refer to...) Figure 8 The financial application control system based on credit mirror offset verification includes the following units:

[0223] The credit granting mirror sequence forming unit 110 is used to acquire credit granting flow data of the target financial application. The credit granting flow data includes document version status, supplementary document trigger status, and approval trace data. Based on the approval node position sequence corresponding to the approval trace data, the credit granting flow data is mirrored to form a credit granting mirror sequence arranged according to the approval node position sequence. The credit granting mirror sequence includes a document mirror corresponding to the document version status and a credit granting support mirror associated with the document mirror.

[0224] The mirror offset section construction unit 120 is used to determine the supplementary image and the triggering pre-sequence image pointed to by the supplementary triggering state in the data image of the credited image sequence, construct the credited support images associated with the supplementary image and the triggering pre-sequence image respectively as a mirror reference pair; perform a succession replacement decomposition on the support data items associated with the mirror reference pair to form a mirror offset section with intra-item succession components, inter-item replacement components and offset item index, and generate support condition data based on the association state of the intra-item succession components, the inter-item replacement components and the offset item index in the mirror offset section;

[0225] The bidirectional coverage verification unit 130 is used to perform bidirectional coverage verification based on the coverage condition data. The bidirectional coverage verification includes performing forward coverage anchoring on the intra-item coverage components corresponding to the coverage condition data, and performing reverse coverage tracing on the inter-item substitution components corresponding to the coverage condition data, forming forward coverage anchoring results and reverse coverage tracing results; and generating coverage closure data from the forward coverage anchoring results and the reverse coverage tracing results.

[0226] The reshaping and delimiting locking unit 140 is used to extract the bearing breakpoint item from the bearing closure data, and reshape and delimit the bearing breakpoint item along the mirror node position of the credited mirror sequence to determine the reshaping starting mirror, the replaced preceding support mirror, and the replaced support data item, forming reshaping and delimiting data; based on the reshaping and delimiting data, generating preceding support locking data for the replaced preceding support mirror in the credited mirror sequence;

[0227] The offset control write-back unit 150 is used to generate offset control allocation data by taking the preceding support locking data and the reshaping delimitation data as control generation inputs; to execute the application control of the target financial application based on the offset control allocation data to form an application control result; and to write back the supplementary closure data corresponding to the application control result to the credit mirror sequence.

[0228] The aforementioned units can be deployed within the same financial institution's business middleware, or they can be deployed separately within approval workflow systems, document management systems, supplementary document management systems, external verification systems, risk review systems, or review control systems. Data association is achieved through application identifiers, business serial numbers, reference pair identifiers, offset item identifiers, mirror node sequence identifiers, and write-back mirror node identifiers. Data interaction between these units can be implemented using database read / write, API calls, message events, task queues, or cache read / write methods. The division of units illustrates the corresponding processing logic. In actual deployment, multiple units can be merged and deployed within the same processing module, or a single unit can be split into multiple sub-modules. These deployment configurations do not alter the data transfer relationships between credit mirror orchestration, mirror reference pair construction, mirror offset section generation, bidirectional coverage verification, reshaping and delimitation, preceding support locking, offset control assignment, and supplementary document closure write-back.

[0229] The above description is merely a preferred embodiment of this application. It should be understood that this application is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the concept described herein through the above teachings or the technology or knowledge in related fields. Modifications and variations made by those skilled in the art that do not depart from the spirit and scope of this application should be protected within the scope of the appended claims.

Claims

1. A financial application control method based on credit mirror offset verification, characterized in that, include: Obtain the credit transfer data of the target financial application, the credit transfer data including document version status, supplementary document trigger status and approval trace data; based on the approval node sequence corresponding to the approval trace data, mirror the credit transfer data to form a credit mirror sequence arranged according to the approval node sequence, the credit mirror sequence including the document mirror corresponding to the document version status and the credit support mirror associated with the document mirror; In the data mirror of the credit mirror sequence, a supplementary mirror and a triggering pre-sequence mirror pointed to by the supplementary triggering state are determined. The credit support mirrors associated with the supplementary mirror and the triggering pre-sequence mirror are constructed as mirror reference pairs. The support data items associated with the mirror reference pairs are decomposed by acceptance and replacement to form a mirror offset section with intra-item acceptance components, inter-item replacement components and offset item indexes. Based on the association status of the intra-item acceptance components, the inter-item replacement components and the offset item indexes in the mirror offset section, acceptance condition data is generated. A two-way coverage verification is performed based on the coverage condition data. The two-way coverage verification includes forward coverage anchoring of the intra-item coverage component corresponding to the coverage condition data, and reverse coverage tracing of the inter-item substitution component corresponding to the coverage condition data, to form a forward coverage anchoring result and a reverse coverage tracing result. The positive anchoring results and the reverse coverage tracing results are used to generate the coverage closure data; Extract the bearing breakpoint items from the bearing closure data, and reshape and delimit the bearing breakpoint items along the image node position of the credit image sequence to determine the reshaping starting image, the replaced previous support image, and the replaced support data items, thus forming the reshaping and delimitation data. Based on the reshaping and delimiting data, preceding support locking data for the replaced preceding support image is generated in the credit image sequence; Using the preceding support locking data and the reshaping delimitation data as control generation inputs, offset control allocation data is generated; based on the offset control allocation data, application control of the target financial application is executed to form an application control result; and the supplementary closure data corresponding to the application control result is written back to the credit mirror sequence.

2. The method according to claim 1, characterized in that, The determination of the credit support record includes: extracting the audit record that provides credit support for the application materials from the audit audit record data, and determining the node position of the audit record in the audit node sequence and the document reference relationship pointed to by the audit record; generating a support role marker from the node position and the document reference relationship, and associating the support role marker with the corresponding document version status to form the credit support record; wherein, the audit record includes node audit records formed by the audit flow node or verification audit records formed by external verification receipts; the credit support mirror is determined by the credit support record corresponding to the document version status.

3. The method according to claim 2, characterized in that, The mirroring arrangement includes: associating the credit support record with the corresponding data mirror, and mapping the support function marker in the credit support record to the support data item in the data mirror, forming the credit support mirror; configuring the data mirror corresponding to the data version status as a mirror node according to the approval node position, and associating the credit support mirror with the corresponding mirror node, forming the credit mirror sequence; wherein, the support data item is the data object in the data mirror corresponding to the support function marker, the support data item inherits the credit support relationship corresponding to the credit support record, and is configured with a corresponding support data item identifier.

4. The method according to claim 3, characterized in that, Determining the supplementary document image and the triggering pre-sequence image pointed to by the supplementary document triggering state in the data image of the credit granting image sequence includes: the supplementary document triggering state corresponds to the supplementary document submission node and the triggering approval node that generates the supplementary document triggering state; the supplementary document image is determined by the supplementary document submission node, the triggering pre-sequence image is determined by the triggering approval node, and the credit granting support images associated with the supplementary document image and the triggering pre-sequence image are constructed as the image reference pair.

5. The method according to claim 4, characterized in that, The replacement decomposition includes: when the supporting data item in the supplementary image and the supporting data item in the triggering prequel image correspond to the same supporting data item identifier, a supporting bearing continuation relationship is formed, and an intra-item bearing component is generated from the supporting bearing continuation relationship; when the supporting data item in the supplementary image and the supporting data item in the triggering prequel image correspond to different supporting data item identifiers, a supporting bearing transfer relationship is formed, and an inter-item replacement component is generated from the supporting bearing transfer relationship; the offset item index includes an offset item identifier and a mirror node position identifier, the offset item identifier identifies the offset item formed by the intra-item bearing component or the inter-item replacement component, and the mirror node position identifier indicates the mirror node position of the offset item in the authorized mirror sequence; the mirror offset section is composed of the offset item index and the intra-item bearing component and inter-item replacement component that are indexed and associated with the offset item index.

6. The method according to claim 5, characterized in that, The coverage condition data includes forward anchoring conditions, reverse tracing conditions, and the offset item index; wherein, the forward anchoring conditions are generated by the intra-item coverage components collected by the offset item index according to the offset item identifier, and point to the coverage object field corresponding to the forward coverage anchoring; the reverse tracing conditions are generated by the inter-item replacement components collected by the offset item index according to the offset item identifier, and point to the tracing object field corresponding to the reverse coverage tracing; the coverage object field includes the supporting data items in the complement mirror and the original supporting data items in the triggering predecessor mirror pointed to by the intra-item coverage components, and the tracing object field includes the replacement supporting data items and the replaced predecessor supporting data items pointed to by the inter-item replacement components.

7. The method according to claim 6, characterized in that, The bidirectional coverage verification includes: the forward coverage anchoring result includes a coverage anchoring relationship constructed from the intra-item coverage components in the coverage object domain, and a coverage closure state configured in the coverage anchoring relationship and determined by the support bearing continuity relationship; the reverse coverage tracing result includes a coverage tracing relationship constructed from the inter-item substitution components in the tracing object domain, and a coverage attribution state and a coverage closure state configured in the coverage tracing relationship and determined by the support bearing transfer relationship; using the offset item index as the merging benchmark, the forward coverage anchoring result and the reverse coverage tracing result are merged into the same offset item to form coverage closure data including the coverage closure state and the coverage closure state.

8. The method according to claim 7, characterized in that, The extraction of the bearing breakpoint item includes: when the bearing closure data characterizes both the bearing closure state and the coverage closure state as unclosed, a bearing imbalance state is formed, and the offset item associated with the bearing imbalance state is determined as the bearing breakpoint item; the reshaping delimitation includes: determining the position of the bearing breakpoint item in the credited mirror sequence and the mirror node where the bearing breakpoint item is located based on the mirror node position identifier in the offset item index corresponding to the bearing breakpoint item, and determining the reshaping starting mirror according to the mirror node where the bearing breakpoint item is located; along the position of the mirror node, using the position position as the delimitation reference, determining the replaced predecessor support mirror and the replacement support data item corresponding to the bearing breakpoint item, forming the reshaping delimitation data; the predecessor support locking data is formed by the reshaping delimitation data, and includes the mirror identifier and locking reference state of the replaced predecessor support mirror, and configuring the replaced predecessor support mirror as the locking reference object in subsequent application control.

9. The method according to claim 8, characterized in that, The offset control assignment data includes a control object field, a lock reference field, a control action field, and a write-back field. The control object field and the lock reference field jointly define the lock reference state between the control object in the target financial application and the replaced preceding support mirror. The control action field is determined by the reshaping starting mirror, the replaced preceding support mirror, and the replacement support data item in the reshaping boundary data. The write-back field points to the write-back mirror node of the supplementary closure data in the credit mirror sequence. The application control action corresponding to the reshaping boundary data is executed according to the offset control assignment data to form an application control result. The application control result is used to update the coverage closure data to form the supplementary closure data, which includes the supplementary closure state, the corresponding offset item identifier, and the lock reference state. The supplementary closure data is written back to the write-back mirror node, and the lock reference state corresponding to the preceding support lock data is maintained during the write-back of the supplementary closure data to update the credit support record for subsequent credit mirror offset verification.

10. A financial application control system based on credit mirror offset verification, characterized in that, The system includes: A credit granting mirror sequence forming unit is used to acquire credit granting flow data of a target financial application. The credit granting flow data includes document version status, supplementary document trigger status, and approval trace data. Based on the approval node sequence corresponding to the approval trace data, the credit granting flow data is mirrored to form a credit granting mirror sequence arranged according to the approval node sequence. The credit granting mirror sequence includes a document mirror corresponding to the document version status and a credit granting support mirror associated with the document mirror. The mirror offset section construction unit is used to determine the supplementary image and the triggering pre-sequence image pointed to by the supplementary triggering state in the data image of the credited image sequence, construct the credited support images associated with the supplementary image and the triggering pre-sequence image respectively as mirror reference pairs; perform acceptance replacement decomposition on the support data items associated with the mirror reference pairs to form a mirror offset section with intra-item acceptance components, inter-item replacement components and offset item indexes, and generate acceptance condition data based on the association state of the intra-item acceptance components, the inter-item replacement components and the offset item indexes in the mirror offset section; A bidirectional coverage verification unit is used to perform bidirectional coverage verification based on the coverage condition data. The bidirectional coverage verification includes performing forward coverage anchoring on the intra-item coverage components corresponding to the coverage condition data, and performing reverse coverage tracing on the inter-item substitution components corresponding to the coverage condition data, forming forward coverage anchoring results and reverse coverage tracing results; and generating coverage closure data from the forward coverage anchoring results and the reverse coverage tracing results. The reshaping and delimiting locking unit is used to extract the bearing breakpoint item from the bearing closure data, and reshape and delimit the bearing breakpoint item along the mirror node position of the credited mirror sequence to determine the reshaping starting mirror, the replaced preceding support mirror, and the replacement support data item, forming reshaping and delimiting data; based on the reshaping and delimiting data, generating preceding support locking data for the replaced preceding support mirror in the credited mirror sequence; The offset control write-back unit is used to generate offset control allocation data by taking the preceding support locking data and the reshaping delimitation data as control generation inputs; to execute the application control of the target financial application based on the offset control allocation data to form an application control result; and to write back the supplementary closure data corresponding to the application control result to the credit mirror sequence.

Images