A loan certificate management and repayment automatic reminding method

Abstract

The present specification provides a loan certificate management and repayment automatic reminding method. The method solves the problem of missing certificates and timely completion by verifying the integrity of the certificate file and automatically triggering the supplement, reducing manual review intervention; in the document signing link, through electronic generation and standardized embedding, the signing efficiency and legal effectiveness are improved; in the repayment management stage, the reminding frequency is dynamically adjusted based on the remaining repayment time, so that the reminding strength and overdue risk are matched, and the timeliness and effectiveness of the reminder are enhanced; in the overdue identification link, a multi-dimensional feature overdue identification model is used for comprehensive evaluation, improving the objectivity and accuracy of overdue judgment. The present specification realizes seamless connection of the whole process from certificate archiving to repayment reminder, and guarantees the rights and interests and fund safety of both parties.

Description

Technical Field

[0001] This application relates to the field of electronic information technology, and in particular to a method for managing loan vouchers and automatically reminding borrowers to repay loans. Background Technology

[0002] In the financial services sector, loan certificate management and repayment reminder mechanisms are crucial for protecting the rights and interests of both lenders and borrowers, as well as ensuring the safety of their funds. With the widespread adoption of digital technology, the automated management of lending processes has become a key direction for industry development, impacting transaction efficiency and user experience.

[0003] However, existing loan management methods still have significant shortcomings in practical application. Many solutions tend to focus only on processing a single aspect, such as emphasizing the storage of vouchers or a single repayment notification, while neglecting the dynamic coordination between various stages throughout the entire loan cycle. This leads to process disruptions, poor information transmission, and problems such as missing vouchers, delayed or inappropriate repayment reminders, which in turn affect trust between lenders and borrowers and the efficiency of contract fulfillment. Summary of the Invention

[0004] To overcome the aforementioned problems in the existing technology, this specification provides a method for managing loan vouchers and automatically reminding repayments, including: The system retrieves loan applications uploaded by the lending client, verifies the supporting documents and personal information carried in the loan application to obtain verification results, and the verification results are used to indicate whether there are any missing items in the supporting documents; In the event of missing items, a retransmission notification is sent to the lending client to enable the lending client to update the voucher file; If the updated voucher file does not contain any missing items, an electronic loan document is generated based on the voucher file, and the electronic loan document includes the expected repayment date. The electronic loan document is pushed to the lender's client to update the electronic loan document based on the lender's signature information; The expected repayment date is extracted from the electronic loan document, and the remaining repayment time is continuously updated based on the current date and the expected repayment date. The reminder frequency is dynamically adjusted according to the remaining repayment time, and repayment reminders are sent to the lender's client based on the reminder frequency. The number of overdue days is determined based on the repayment information uploaded by the lender's client. A pre-trained overdue identification model is used to assess whether the lender has defaulted based on the number of overdue days and generates an overdue record. The overdue record is then pushed to the lender's client.

[0005] Furthermore, the verification results of the supporting documents and personal information carried in the loan application include: The clarity index of the voucher document is calculated. If the clarity index is lower than a preset threshold, the voucher document is image-enhanced using an image enhancement algorithm. The voucher document includes the identity image of the borrower / lender, a scanned copy of the loan agreement, and supporting documents. Personal information is extracted from the identity images, scanned copies of loan receipts, and supporting documents using character recognition technology; The personal information carried in the loan application is compared with the extracted personal information to obtain the verification result.

[0006] Furthermore, the supplementary notification is generated by embedding the missing item into a preset information template; the verification of the supporting documents and personal information carried in the loan application to obtain the verification result also includes: The voucher file is compared with a preset voucher template to identify missing items in the borrower's identity image, scanned copy of the loan agreement, and supporting documents.

[0007] Furthermore, updating the credential file includes: Obtain the re-uploaded files from the lending client for the missing items; The type of the re-uploaded file is identified to verify whether the type of the re-uploaded file is consistent with that of the missing item; After successful verification, the supplementary file is added to or replaced in the voucher file, and the updated voucher file is marked as complete; wherein, the complete status is used to indicate that the updated voucher file has no missing items.

[0008] Further, the step of generating electronic loan documents based on the voucher documents includes: Obtain the document data structure from the preset template, generate document data based on the document data structure, and embed the expected repayment date as a structured field into the document data; The document data is encrypted, and integrity verification information is generated. The integrity verification information is then associated with the encrypted document data to obtain a standardized electronic loan document.

[0009] Furthermore, updating the electronic loan document based on the lender's signature information includes: Receive the signature confirmation response returned by the lending client, and extract the signature time from the signature confirmation response; The signature time is embedded as a timestamp into the electronic loan document, and the signature confirmation response, timestamp, and embedded electronic loan document are stored together.

[0010] Furthermore, the step of dynamically adjusting the reminder frequency based on the remaining repayment time includes: Set multiple preset time intervals to determine the time interval to which the remaining repayment time belongs; The frequency corresponding to the time interval is matched, and the sending interval is shortened as the remaining repayment time decreases to increase the reminder frequency.

[0011] Further, the step of assessing whether the borrower is in default based on the number of overdue days using the overdue identification model and generating an overdue record includes: Get the number of overdue days between the actual repayment date and the expected repayment date; The overdue days, loan amount, and borrower's credit history characteristics are input into the overdue identification model; wherein, the overdue identification model adopts the logistic regression algorithm, and constructs a mapping relationship between the input and the overdue result based on training samples; The output value of the overdue identification model is compared with a preset threshold. Based on the comparison result, it is determined whether the overdue period has been reached, and an overdue record containing the determination result is generated.

[0012] Furthermore, the step of pushing the overdue record to the lender's client includes: Based on the overdue records, the borrower's performance status is updated to overdue, and the updated performance status is pushed to the lender's client. The push time is recorded, and the complete operation sequence from uploading the loan application to the push of the performance status is recorded in a chain storage structure with hash verification to form performance chain data.

[0013] On the other hand, this specification also provides a loan certificate management and automatic repayment reminder system, including: The credential verification module is used to obtain the loan application uploaded by the lending client, verify the credential files and personal information carried in the loan application to obtain the verification result, and the verification result is used to indicate whether there are any missing items in the credential file; The retransmission processing module is used to send a retransmission notification to the lending client when there are missing items, so that the lending client can update the voucher file; The document generation module is used to generate an electronic loan document based on the updated voucher document if there are no missing items. The electronic loan document includes the expected repayment date. The signature confirmation module is used to push the electronic loan document to the lender's client to update the electronic loan document based on the lender's signature information; The reminder management module is used to extract the expected repayment date from the electronic loan document, continuously update the remaining repayment time based on the current date and the expected repayment date, dynamically adjust the reminder frequency according to the remaining repayment time, and send repayment reminders to the lender's client based on the reminder frequency; The overdue processing module is used to determine the number of overdue days based on the repayment information uploaded by the lender's client, evaluate whether the lender has defaulted based on the number of overdue days using a pre-trained overdue identification model, generate an overdue record, and push the overdue record to the lender's client.

[0014] This manual achieves systematization and intelligence in loan management by constructing a fully automated closed loop from voucher verification, resubmission, electronic document generation and signing, dynamic reminders to overdue assessment. In the application stage, the completeness verification of voucher documents and automatic triggering of resubmission solve the problem of timely replacement of missing vouchers, reducing manual review intervention. In the document signing stage, electronic generation and standardized embedding improve signing efficiency and legal validity. In the repayment management stage, the reminder frequency is dynamically adjusted based on the remaining repayment time, matching the reminder intensity with the overdue risk and enhancing the timeliness and effectiveness of reminders. In the overdue identification stage, a multi-dimensional feature overdue identification model is used for comprehensive assessment, improving the objectivity and accuracy of overdue judgment. This manual achieves seamless integration of the entire process from voucher archiving to repayment reminders, protecting the rights and interests and fund security of both lenders and borrowers. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of a loan certificate management and automatic repayment reminder method provided in the embodiments of this specification; Figure 2 This is a schematic diagram illustrating the verification results obtained by verifying the supporting documents and personal information carried in the loan application, as provided in the embodiments of this specification. Figure 3 This is a schematic diagram illustrating the updating of the credential file provided in the embodiments of this specification; Figure 4 This is a schematic diagram of the structure of a loan voucher management and automatic repayment reminder system provided in the embodiments of this specification; Figure 5 This is a schematic diagram of an application scenario provided in the embodiments of this specification. Detailed Implementation

[0016] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0017] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0018] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0019] In the financial services sector, loan certificate management and repayment reminder mechanisms are crucial for protecting the rights and interests of both lenders and borrowers, as well as ensuring the safety of their funds. With the widespread adoption of digital technology, the automated management of lending processes has become a key direction for industry development, impacting transaction efficiency and user experience.

[0020] However, existing loan management methods still have significant shortcomings in practical application. Many solutions tend to focus only on processing a single aspect, such as emphasizing the storage of vouchers or a single repayment notification, while neglecting the dynamic coordination between various stages throughout the entire loan cycle. This leads to process disruptions, poor information transmission, and problems such as missing vouchers, delayed or inappropriate repayment reminders, which in turn affect trust between lenders and borrowers and the efficiency of contract fulfillment.

[0021] Especially in the initial stages of loan applications, the identity images, scanned copies of loan agreements, and supporting documents uploaded by borrowers are often incomplete or unclear. Current technology lacks an effective mechanism for automated verification of the completeness of these documents and for supplementing missing information, leading to prolonged review periods and increased manual intervention. In the document signing stage, the generation and signing of electronic loan documents, if lacking standardized embedding and verification methods, can easily pose legal risks. In the repayment reminder stage, the core issue focuses on the accurate calculation and dynamic adjustment of the remaining repayment time. Due to the failure to effectively combine the real-time changes of the current date and the agreed repayment date, the system often cannot flexibly adjust the reminder method and frequency according to different stages of the remaining days. This technological lag directly results in borrowers not receiving sufficiently strong reminders as the repayment date approaches, or failing to trigger the generation of overdue records after the repayment date has passed, thus affecting the lender's financial security.

[0022] Specifically, in practical business, if a borrower's repayment date is set for 30 days later, and the system fails to remind the borrower in different ways on the 10th, 5th, and 1st days based on the remaining days, the borrower may miss the repayment deadline due to negligence. Furthermore, if the system fails to generate a record and notify the lender immediately upon overdue payment, the lender will be unable to take timely countermeasures, resulting in the risk of financial loss. In addition, in the overdue determination process, existing technologies often rely solely on whether the repayment date has passed, lacking a comprehensive assessment of multiple dimensions such as the loan amount and the borrower's credit history, leading to insufficient accuracy and objectivity in overdue identification.

[0023] Therefore, how to intelligently adjust the reminder frequency based on voucher integrity verification, electronic document signing, and dynamic changes in the remaining days in loan management, and how to combine multi-dimensional features for overdue identification and performance chain recording, has become a key technical problem that urgently needs to be solved.

[0024] The loan certificate management and automatic repayment reminder method provided in this application can be applied to various lending business scenarios, such as personal consumer loans, micro and small enterprise financing, online lending platforms, and bank online credit systems. With the digitalization and online development of financial services, the entire process of lending, from application, approval, and signing to repayment, is gradually migrating to online platforms. In this process, how to achieve automated verification of loan certificates, electronic generation and signing of documents, dynamic adjustment of repayment reminders, and accurate identification of overdue status through technical means is a key link in improving business efficiency, reducing overdue risk, and protecting the rights and interests of both lenders and borrowers.

[0025] The method for managing loan vouchers and automatically reminding borrowers to repay can include: obtaining loan applications and uploaded identity images, scanned copies of loan receipts, and supporting documents through the borrower's client; extracting document content using image recognition technology and verifying its completeness; sending a notification to the borrower's client to supplement missing items, and generating an electronic loan document after all documents are complete, embedding the expected repayment date into the document data, and pushing it to the borrower's client for online signature confirmation; extracting the expected repayment date from the signature record, calculating the remaining repayment time between the current date and the expected repayment date, and dynamically adjusting the reminder frequency based on the remaining repayment time, sending repayment reminders through multiple channels such as SMS and application messages; after the borrower repays, determining the number of overdue days based on the repayment information, assessing whether it constitutes an overdue payment using an overdue identification model, generating an overdue record and pushing it to the lender's client, forming a complete performance chain data.

[0026] As an application example, borrowers initiate loan applications via mobile devices or web platforms, uploading documents such as photos of their ID cards, scanned copies of loan agreements, and proof of income. Upon receiving the application information, the system uses optical character recognition (OCR) technology to extract personal information, loan amount, and term details from the documents and compares them with the application information. If a scanned copy of the loan agreement is missing or blurry, the system automatically generates a re-upload notification, sent to the borrower's mobile phone via SMS, guiding them to re-upload. Once all documents are complete, the system generates an electronic loan document containing the expected repayment date and pushes it to the borrower's client via a secure online channel. After the borrower signs and confirms online, the system records the signature time and the expected repayment date.

[0027] During the repayment management phase, the system continuously calculates the remaining days between the current date and the expected repayment date. When the remaining days fall within a preset reminder range (e.g., 10 days, 5 days, 1 day), a repayment reminder is sent to the borrower via SMS and application messaging channels, with the reminder frequency gradually increasing as the remaining days decrease. If the borrower fails to repay before the expected repayment date, the system extracts the actual repayment date from the reminder response log, calculates the overdue days, and inputs the overdue days, loan amount, and the borrower's credit history characteristics (including historical repayment records, number of overdue payments, credit score, etc.) into a pre-trained overdue identification model. The model outputs a probability value constituting an overdue payment, which is then compared with a preset threshold to determine whether an overdue payment has occurred, generating an overdue record and notifying the lender. The time and content of operations such as voucher upload, signature confirmation, repayment reminders, and overdue records in the above process are recorded using a chained storage structure with hash verification, forming a complete performance chain data.

[0028] It should be noted that the above-mentioned application scenarios or application examples of the loan voucher management and automatic repayment reminder method provided in the embodiments of this application are for ease of understanding, and the embodiments of this application do not specifically limit the application of the loan voucher management and automatic repayment reminder method.

[0029] The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0030] Please see Figure 1 , Figure 1 This is a schematic diagram of a loan certificate management and automatic repayment reminder method provided in the embodiments of this specification. The method includes: S200: Obtain the loan application uploaded by the lender's client, verify the supporting documents and personal information carried in the loan application, and obtain the verification result. The verification result is used to indicate whether there are any missing items in the supporting documents.

[0031] In some embodiments, the loan document management and automatic repayment reminder method is executed by a management server. Communication connections are established with both the borrower's client and the lender's client. The borrower's client initiates loan applications, uploads document files, receives supplementary transmission notifications, views electronic loan documents and performs online signature confirmation, and receives repayment reminders. The lender's client receives overdue records and performance status notifications to stay informed about the borrower's repayment status. The management server, as the core executor of the method, is responsible for receiving data submitted by the borrower's client, performing operations such as document verification, supplementary transmission processing, electronic document generation and signing management, repayment reminder scheduling, overdue identification, and performance chain data storage, and pushing the processing results to the corresponding clients.

[0032] When borrowers initiate loan applications via mobile devices or web platforms, they upload supporting documents such as an image of their identity, a scanned copy of the loan agreement, and other supporting documents. Image recognition technology is used to extract key information from these documents: optical character recognition algorithms are used to process the identity image to extract personal information such as name and ID number; loan amount and term details are extracted from the scanned loan agreement; and income verification or credit records are extracted from the supporting documents.

[0033] After extracting the information, the results are cross-checked and their completeness is assessed. The extracted personal information is compared with the application information submitted by the borrower. If they match, the application is marked as approved; otherwise, a mismatch record is generated. The system also checks for missing items, including missing identity images, missing signature areas on scanned loan documents, and illegible supporting documents. The verification result includes either "all documents are complete" or information on specific missing items.

[0034] In one possible implementation, please refer to Figure 2Step S200 verifies the supporting documents and personal information carried in the loan application to obtain the verification result, which may specifically include: S2001: Calculate the clarity index of the voucher document. If the clarity index is lower than a preset threshold, perform image enhancement processing on the voucher document using an image enhancement algorithm. The voucher document includes the identity image of the borrower, a scanned copy of the loan agreement, and supporting documents.

[0035] The sharpness index can be calculated based on image gradient information.

[0036] For example, the Sobel or Laplacian operators can be used to calculate the gradient magnitude of pixels in an image, and the average gradient magnitude of the entire image can be used as the sharpness score. In most cases, the more pronounced the gradient in the edge regions of an image, the higher the sharpness score; if the image is blurry, the gradient magnitude is generally low, and the sharpness score is correspondingly reduced. A preset threshold can be set based on the sharpness distribution of historical credential documents. For example, the threshold can be set to an empirical value; images below this threshold are considered of insufficient quality, making it difficult to guarantee the accuracy of subsequent optical character recognition.

[0037] When the sharpness index falls below a preset threshold, image enhancement processing is triggered. For example, image enhancement processing can employ histogram equalization, which stretches the grayscale histogram distribution of the image across the entire grayscale range, redistributing pixels that were originally concentrated in a specific grayscale interval, thereby improving image contrast. For instance, if the identity image uploaded by a borrower is too dark due to insufficient lighting during capture, resulting in minimal grayscale difference between characters and the background, histogram equalization will relatively increase the grayscale value of the character area and relatively decrease the grayscale value of the background area, making the character outlines clearer. Similarly, for scanned loan documents, if the image appears washed out or lacks contrast due to scanning equipment issues, histogram equalization can also enhance the distinction between text and background. After image enhancement processing, subsequent optical character recognition will be performed based on the enhanced image.

[0038] S2002: Use character recognition technology to extract personal information from the identity image, scanned copy of the IOU, and supporting documents.

[0039] The implementation of optical character recognition (OCR) typically includes image preprocessing, text region localization, character segmentation, and character recognition. For identity images, such as ID card photos, the algorithm first locates the portrait or front of the ID card, then identifies fields such as name, ID number, and address, and converts the text in the image into structured text data using a character recognition model. For scanned loan receipts, the algorithm identifies key fields such as the loan amount, loan term, lender information, and borrower information. For supporting documents, such as income statements or bank statements, the algorithm extracts information such as income amount, employer, and issuance date.

[0040] In the image preprocessing stage, if the voucher document has already undergone histogram equalization enhancement, it directly proceeds to the text region localization stage. Text region localization can employ methods based on connected component analysis or deep learning-based text detection models. Character segmentation breaks down text lines into individual characters, while character recognition uses models such as convolutional neural networks to convert character images into corresponding text codes. In processing scanned IOUs, if the IOU contains handwritten content, optical character recognition may need to be combined with a handwriting recognition model to convert the handwriting into readable text.

[0041] S2003: Compare the personal information carried in the loan application with the extracted personal information to obtain the verification result.

[0042] Loan applications include the borrower's personal information, such as name, ID number, loan amount, and loan term. The comparison process matches the information extracted by optical character recognition (OCR) against the information in the application item by item. For example, the name identified in the identity image is compared with the name entered in the application; a match is marked if they are identical. Similarly, the ID number identified in the identity image is compared with the ID number entered in the application; any discrepancies are recorded as an anomaly. For the loan amount, the amount extracted from the scanned loan agreement is compared with the loan amount in the application, allowing for a match within a preset error range. Income amounts extracted from supporting documents may be used to cross-verify the borrower's repayment ability, rather than being directly compared with the application information.

[0043] The comparison results can be summarized into verification results, which are used to indicate whether there are any missing items or inconsistencies in the supporting documents. For example, if all extracted information matches the application information and all supporting documents are uploaded completely, the verification result can be marked as "verification passed"; if a certain type of document is missing, or if there are mismatches between the extracted information and the application information, the verification result will record the specific missing items or mismatched fields, which will serve as the basis for subsequent supplementary submission notifications or manual review.

[0044] In one possible implementation, step S200, which verifies the supporting documents and personal information carried in the loan application to obtain verification results, may further include comparing the supporting documents with a preset supporting document template to identify missing items in the borrower's identity image, scanned copy of the loan agreement, and supporting documents. The supplementary notification is generated by embedding the missing items into a preset information template.

[0045] Specifically, the pre-defined voucher templates define a complete list of document types required for loan approval, as well as the necessary information fields that each document type should include. For example, for personal consumer loan scenarios, the voucher template may specify that it must include: an identity image (including the front and back of the ID card), a scanned copy of the loan agreement (including the loan amount, loan term, borrower's signature, and lender's signature), and supporting documents (such as income statements or bank statements). The necessary information fields defined in the identity image template may include name, ID number, and document validity period; the necessary information fields defined in the scanned copy of the loan agreement template may include loan amount, loan term, annual interest rate, borrower's signature, lender's signature, and signing date; the necessary information fields defined in the supporting document template may include income amount, issuing unit, and issuance date.

[0046] When comparing the voucher files uploaded by the borrower and lender with the preset voucher template, the first step is to check if the file types are complete. For example, if the borrower and lender only uploaded an image of their identity and a scanned copy of the IOU, but did not upload any supporting documents, the supporting documents are identified as a missing item. If the file types are complete, the next step is to check whether each file type contains the necessary information fields defined in the template. For example, if a scanned copy of the IOU has been uploaded, but optical character recognition reveals that it lacks the borrower's signature area, or that the signature area cannot be recognized with valid signature strokes, then "missing borrower's signature in scanned IOU" is identified as a missing item.

[0047] During the comparison process, for uploaded but incomplete supporting documents, the system may classify them as missing items. For example, if an identity image has been uploaded, but optical character recognition (OCR) reveals that the ID number field is empty or does not conform to the format, then "incomplete ID number in identity image" will be identified as a missing item. For supporting documents, if they have been uploaded but OCR cannot extract a valid income amount, or if the extracted income amount does not match the loan amount filled in the application and exceeds a preset threshold, then "invalid supporting document content" or "income certificate does not match loan amount" will be identified as missing items.

[0048] After identifying missing items, the system embeds them into a pre-defined information template to generate a supplementary notification. The pre-defined information template can be a structured text template containing a standard prompt and populateable fields. For example, the template might read: "Dear customer, your loan application is missing the following documents or information: [List of Missing Items]. Please upload them before the [Deadline] so that we can continue processing your application." The system will populate the [List of Missing Items] field in the template with the identified missing items, and can also populate the [Deadline] field with a supplementary submission deadline set according to business rules (e.g., within 24 hours or 3 business days).

[0049] The generated supplementary submission notification can be sent to the lender's client via SMS or in-app messaging. For example, if the missing items are "supporting documents" and "lender's signature in the scanned copy of the IOU," the notification could state: "Supporting documents are missing, and the scanned copy of the IOU lacks the lender's signature. Please upload the missing documents." Simultaneously, the system can record the sending time, details of the missing items, and the deadline for supplementary submission, storing these information in a log database for future tracking of whether the lender has completed the supplementary submission on time.

[0050] S201: In the event of missing items, a retransmission notification is sent to the lending client to enable the lending client to update the voucher file.

[0051] When the verification results indicate missing items, the specific type of missing item is identified, marked as content requiring resubmission, and a resubmission notification containing a list of missing files and a resubmission deadline is generated. Then, the missing items are inserted into a preset information template to generate a formatted notification, which is sent to the lender's client via SMS or in-app messaging, while recording the sending time and details of the missing items.

[0052] After receiving the notification, the lender re-uploads the supporting documents. The server then retrieves the re-uploaded documents and extracts the content using the same image recognition algorithm as the initial verification. Once all documents are complete, the re-uploaded documents are archived in the loan record, confirming the final document completeness status.

[0053] In one possible implementation, please refer to Figure 3 Updating the credential file in step S201 may specifically include: S2011: Obtain the re-uploaded file from the lending client for the missing item.

[0054] After receiving the supplementary file notification, the lender re-uploads the file via a mobile terminal or web platform. The process of obtaining the supplementary file includes receiving the file data stream, verifying the file format (such as JPEG, PNG, PDF, etc.), and storing it in a temporary storage area. The system can initially categorize this supplementary file operation based on the type of missing item recorded in the notification, such as whether the supplementary file is for an identity image, a scanned copy of the loan agreement, or a supporting document.

[0055] S2012: Perform content recognition on the supplementary file to verify whether the type of the supplementary file is consistent with that of the missing item.

[0056] The purpose of content recognition is to confirm that the supplementary file does indeed correspond to the missing item type, rather than an irrelevant file. For example, if the missing item is an "identity image," the system uses optical character recognition technology to extract the text content from the supplementary file and determine whether it contains identity information such as ID number and name; if the missing item is a "scanned copy of a loan agreement," it identifies whether it contains loan agreement elements such as loan amount, loan term, and signature area; if the missing item is a "proof document," it identifies whether it contains key fields such as income amount and issuing unit.

[0057] During this process, the supplementary file can be compared with the preset voucher template to determine if the file type matches. For example, the preset voucher template stipulates that the identity image must include the features of a front or back photo of an ID card. If the supplementary file is identified as a bank statement screenshot, the type is determined to be inconsistent. If the type matching verification fails, the system can resend a prompt message to the lending client, requesting them to re-upload the correct file type.

[0058] S2013: After successful verification, the supplementary file is added to or replaced in the voucher file, and the updated voucher file is marked as complete. The completeness status indicates that the updated voucher file contains no missing items.

[0059] If the missing item is a file that already exists in the original voucher file but is incomplete (e.g., the identity image is blurry and unrecognizable), the missing file will be replaced with the supplementary file. If the missing item is a file type that is completely missing in the original voucher file (e.g., no supporting document was uploaded), the supplementary file will be added to the corresponding category of the voucher file. After the replacement or supplementation operation is completed, the system will re-verify the completeness of the updated voucher file to confirm that all file types specified in the voucher template are complete and valid. After the verification passes, the updated voucher file will be marked as complete, the update time and operation record will be recorded, and it will be stored in the loan record. If there are still other missing items that have not been supplemented, the system will remain in the pending supplementation status, waiting for the borrower to continue uploading.

[0060] S202: If the updated voucher file does not contain any missing items, generate an electronic loan document based on the voucher file, the electronic loan document including the expected repayment date.

[0061] Once the supporting documents are complete and verified, the document data structure is obtained from the preset template, and key information such as the borrower's information, loan amount, and interest rate terms are automatically filled into the template to obtain the electronic loan document.

[0062] The expected repayment date can be embedded in the electronic loan document, and the expected repayment date is determined based on the loan term and the application date. In some implementations, encryption mechanisms can be used to protect the document data, and hash algorithms can be used to verify the document content to ensure that it has not been tampered with during transmission and storage.

[0063] In one possible implementation, generating an electronic loan document based on the voucher file in step S202 may specifically include: S2021: Obtain the document data structure from the preset template, generate document data based on the document data structure, and embed the expected repayment date as a structured field into the document data.

[0064] Preset templates can be predefined document templates or data structure templates. In document templates, the template typically contains fixed terms and conditions, formatting styles, and reserved data population locations. For example, a loan agreement template stored in PDF format includes placeholders for borrower / borrower names, loan amounts, loan terms, and expected repayment dates. In data structure templates, the template can be represented as a JSON or XML data structure definition, specifying the names, types, and constraints of each field. Based on the template definition, the system extracts borrower information, loan amounts, and other data from verified voucher files, converts the expected repayment date to a standard date format, and populates it into the corresponding structured fields in the template. Embedding the expected repayment date as a structured field allows for direct programmatic extraction of the date during subsequent repayment management, eliminating the need for further parsing from the text content. For example, in a JSON structure, a "expectedRepaymentDate" field can be defined with a value such as a standard format string like "2025-06-30".

[0065] S2022: Encrypt the document data and generate integrity verification information. Associate the integrity verification information with the encrypted document data to obtain a standardized electronic loan document.

[0066] The purpose of encryption is to protect the confidentiality of electronic loan documents during transmission and storage. In one implementation, a symmetric encryption algorithm (such as AES) can be used to encrypt the document data, with the encryption key managed by the system and decrypted only when verification or display of the document is required. In another implementation, an asymmetric encryption method can be used, employing the lender's public key to encrypt the document, ensuring that only the lender can decrypt and view the content.

[0067] Integrity verification information is used to verify whether electronic loan documents have been tampered with after their generation. In most cases, the system uses a hash algorithm (such as SHA-256) to calculate a hash value for the encrypted document data or the original document data, and stores this hash value as integrity verification information associated with the document data. When document integrity needs to be verified subsequently, the hash value of the current document is recalculated and compared with the original hash value. If they match, it proves that the document has not been modified. In some implementations, digital signature technology can also be used, whereby the system signs the hash value of the document data using a private key, and the recipient verifies the signature using a public key, thereby providing non-repudiation.

[0068] After the above processing, the system generates standardized electronic loan documents. The standardized format can be a composite file containing encrypted data and integrity verification information, such as encapsulating the encrypted document data and hash value into a JSON object, or generating a PDF / A document with an embedded digital signature. This standardized format facilitates exchange, storage, and long-term archiving between different systems, while ensuring data confidentiality and integrity.

[0069] S203: Push the electronic loan document to the lender's client to update the electronic loan document based on the lender's signature information.

[0070] After receiving the electronic loan document, the lender's client displays the document's content through its interface. Once the lender confirms the document information is correct, it generates a signature using the electronic signature component provided by its client. This component supports various signature input methods, such as: the lender signing by hand on a touchscreen, with the client capturing the coordinate sequence and pressure data of the handwriting to form a signature image or vector data; or the lender clicking the "Confirm Signature" button and entering a transaction password or performing biometric identification (such as fingerprint or facial recognition), with the client generating electronic signature data representing the lender's signing intent. The signature information includes at least the lender's identification and the signature generation time. The client encapsulates this signature information in a signature confirmation response and returns it to the server via a secure communication channel. Upon receiving the signature confirmation response, the server extracts the signature time and signature data from the response to perform subsequent signature time embedding and associated storage operations.

[0071] In one possible implementation, updating the electronic loan document based on the lender's signature information in step S203 may specifically include: S2031: Receive the signature confirmation response returned by the lending client, and extract the signature time from the signature confirmation response.

[0072] After viewing the electronic loan document through a client application, the lender confirms it using an electronic signature tool. The signature confirmation response may include signature data, lender / borrower identification, document identification, and signature time. In one implementation, the signature time is recorded by the lender / borrower's client when the user completes the signature operation and returned as part of the response data. In another implementation, the signature time is generated by the server upon receiving the signature confirmation response, using the server time as the reference for the signature time to avoid disputes caused by inaccurate client time. The signature confirmation response can be protected using digital signature technology, such as signing the response content with the lender / borrower's digital certificate, to ensure the authenticity and non-repudiation of the response.

[0073] S2032: Embed the signature time as a timestamp into the electronic loan document, and store the signature confirmation response, timestamp, and embedded electronic loan document together.

[0074] Embedding the signature time as a timestamp into electronic loan documents can be achieved using various technical methods. In one implementation, the system writes the signature time as metadata into a custom field or document attribute of the electronic loan document file, creating a formally signed version with a timestamp. In another implementation, the system can submit the signature time along with the hash value of the document data to a third-party timestamp service provider to obtain an authoritative timestamp certificate, which is then embedded into the electronic loan document to meet legal requirements for time evidence of electronic signatures.

[0075] S2033: The associated storage of signature confirmation responses, timestamps, and embedded electronic loan documents is intended to form a complete signature record archive.

[0076] In most cases, the system encapsulates the above information into a record, assigns it a unique identifier, and stores it in the database. The storage structure may include the following fields: record ID, borrower ID, document ID, original (or summary) signature confirmation response, timestamp, document file with embedded timestamp, storage time, etc. In one implementation, the system can also calculate the joint hash value of the signature confirmation response, timestamp, and document data, and use this hash value as the basis for integrity verification, storing it together with the record for subsequent verification of whether the signed record has been tampered with. After the associated storage is completed, the electronic loan document is marked as signed, and subsequent repayment management processes can be executed based on this signed version.

[0077] S204: Extract the expected repayment date from the electronic loan document, continuously update the remaining repayment time based on the current date and the expected repayment date, dynamically adjust the reminder frequency according to the remaining repayment time, and send repayment reminders to the lender's client based on the reminder frequency.

[0078] The expected repayment date stored in the signature record may exist in various forms, such as "June 30, 2025" or "2025-06-30". To facilitate subsequent mathematical calculations, it needs to be converted to a standardized date format (such as YYYY-MM-DD). Converting to a standard date format eliminates calculation errors caused by different representations, ensuring the accuracy of subsequent difference calculations.

[0079] The remaining repayment period is continuously updated as the current date progresses, and the reminder frequency is dynamically adjusted based on these changes. Based on the adjusted reminder frequency, repayment reminders are sent to the lender's client via SMS and application messaging channels. An integrated SMS service interface calls a third-party API to send text messages, while notifications are also sent via in-app push notifications. The reminder content includes information such as the remaining repayment days and the repayment amount. The sending time and content of each reminder are recorded and stored in a log database.

[0080] In one possible implementation, step S204, which dynamically adjusts the reminder frequency based on the remaining repayment time, may specifically include: Multiple preset time intervals are set to determine the time interval to which the remaining repayment time belongs. These preset time intervals can be divided according to the actual needs of the lending business. For example, the following intervals can be set: remaining repayment time greater than 30 days, remaining repayment time between 15 and 30 days, remaining repayment time between 7 and 14 days, remaining repayment time between 3 and 6 days, remaining repayment time between 1 and 2 days, and remaining repayment time of 0 days or already due. Each time interval corresponds to a different reminder strategy. When determining the interval to which the remaining repayment time belongs, the system compares the calculated remaining days with the above interval thresholds to determine the current interval position.

[0081] The frequency corresponding to the time interval is matched to increase the reminder frequency by shortening the sending interval as the remaining repayment time decreases. Each preset time interval can be pre-associated with a reminder frequency parameter. For example, when the remaining repayment time is greater than 30 days, no reminder may be sent or a reminder may be sent once a month; when the remaining repayment time is between 16 and 30 days, a reminder may be sent once a week; when the remaining repayment time is between 8 and 15 days, a reminder may be sent once every three days; when the remaining repayment time is between 4 and 7 days, a reminder may be sent once every two days; when the remaining repayment time is between 1 and 3 days, a reminder may be sent once a day; when the remaining repayment time is 0 days or the payment is overdue, multiple reminders may be sent daily (e.g., once every 4 hours).

[0082] The shortening of the reminder sending interval as the remaining repayment time decreases can be achieved through scheduled tasks or event-triggered mechanisms. In one implementation, the system calculates the remaining repayment time for all outstanding borrowers at a fixed time each day (e.g., 9:00 AM), and determines whether and how often to send reminders based on the current repayment period. When the remaining repayment time is short, the system may need to send multiple reminders within the same day. When the remaining repayment time is 0 days (i.e., the due date), reminders are sent at 9:00 AM, 3:00 PM, and 7:00 PM. Shortening the sending interval allows borrowers to receive more frequent reminders as the repayment deadline approaches, helping to reduce the possibility of overdue payments due to negligence.

[0083] Dynamic adjustment of reminder frequency can be achieved using a rules engine. The rules engine defines the mapping relationship between different time intervals and reminder frequencies. When the remaining repayment time crosses the interval boundary, the system automatically switches to the corresponding frequency rule. For example, when the remaining repayment time changes from day 8 to day 7, the system detects the interval change and adjusts the reminder frequency from once every three days to once every two days. Simultaneously with the interval switch, the system can record an adjustment log, including the adjustment time, the frequency before the adjustment, the frequency after the adjustment, and the current remaining repayment time. These records can be used for subsequent reminder effectiveness analysis and rule optimization.

[0084] S205: Determine the number of overdue days based on the repayment information uploaded by the lender's client, evaluate whether the lender is in default based on the number of overdue days using a pre-trained overdue identification model, generate an overdue record, and push the overdue record to the lender's client.

[0085] The repayment information uploaded by the lender's client can include repayment vouchers (such as bank transfer screenshots or payment platform transaction serial numbers), repayment amount, and / or repayment timestamps.

[0086] In one possible implementation, after receiving repayment information, the number of overdue days is determined based on the repayment information uploaded by the lender's client, specifically including: If the borrower completes repayment through the integrated payment interface, the repayment information will directly include the transaction completion time returned by the payment gateway, and the server will use this time as the actual repayment date. If the borrower only uploads a repayment voucher (such as a screenshot of a bank statement), the server will use optical character recognition technology to extract the transaction date and amount from the voucher and verify it against the amount due. After the verification is successful, the extracted transaction date will be used as the actual repayment date.

[0087] After obtaining the actual repayment date, determine the difference in natural days between the actual repayment date and the expected repayment date. If the actual repayment date is later than the expected repayment date, the difference is positive, which is the number of overdue days. If the actual repayment date is earlier than or equal to the expected repayment date, the number of overdue days is counted as 0, and it can be directly determined that there is no overdue payment, without the need for evaluation through the overdue identification model.

[0088] This step retrieves repayment feedback from the reminder response log or repayment interface, identifies the actual repayment date, calculates the difference in natural days between the actual and expected repayment dates, and obtains the number of overdue days. Then, the number of overdue days, loan amount, and the borrower's credit history are input into the overdue identification model. This model comprehensively processes these features and outputs an evaluation result, which is compared with a preset threshold to determine whether an overdue payment has occurred. After the determination, an overdue record is generated based on the overdue conclusion, stored in the database, and pushed to the lender's client. The notification time and content are recorded, and the entire process from voucher retrieval to overdue notification is recorded using a chained storage structure with hash verification.

[0089] In one possible implementation, step S205, which assesses whether the borrower is in default based on the number of overdue days using an overdue identification model and generates an overdue record, may specifically include: S2051: Input the overdue days, loan amount, and credit history characteristics of the borrower into the overdue identification model; wherein, the overdue identification model is based on the logistic regression algorithm and constructs a mapping relationship between the input and the overdue result based on the training samples.

[0090] The input features of the overdue loan identification model include the number of overdue days, the loan amount, and the borrower's credit history. Credit history features can include quantitative indicators such as the borrower's past loan repayment records, number of overdue payments, and credit score. During the model building phase, historical loan sample data is collected, with each sample containing the above features and the corresponding actual overdue result (whether it constitutes an overdue payment), as training data.

[0091] Logistic regression algorithms map linear combinations of input features to probability values ​​between 0 and 1 by fitting a logistic function (Sigmoid function). During model training, parameters are optimized using maximum likelihood estimation or gradient descent to minimize the difference between the model's predictions and the actual results for the training samples. For example, the model might learn that the number of overdue days has a higher weight on the overdue outcome, followed by the loan amount, and the weight of credit history features might vary depending on the data distribution. After training, the model establishes a mapping relationship between input features and overdue probabilities.

[0092] After the model is trained, for each new loan, the real-time calculated overdue days, loan amount, and credit history characteristics are input into the model to obtain the corresponding overdue probability. In actual business, a probability threshold can be set, for example, 0.5. If the probability output by the model is greater than or equal to this threshold, it is determined to constitute an overdue payment; if it is lower than the threshold, it is determined not to constitute an overdue payment. This threshold can be flexibly adjusted according to business needs: if you want to capture as many potential overdue cases as possible (reduce false negatives), you can lower the threshold, for example, to 0.3; if you want to reduce the number of times normal repayments are mistakenly judged as overdue (reduce false positives), you can raise the threshold, for example, to 0.7.

[0093] S2052: Compare the output value of the overdue identification model with a preset threshold, determine whether it constitutes an overdue payment based on the comparison result, and generate an overdue record containing the determination result.

[0094] The model output value represents the borrower's probability of default, ranging from 0 to 1. A preset threshold can be set according to business needs, for example, to 0.5. If the output probability is greater than or equal to the threshold, it is considered a default; if it is less than the threshold, it is considered not a default. In one implementation, the threshold can be adjusted according to different risk preferences. For example, for risk-averse lenders, the threshold can be lowered to 0.3 to reduce the possibility of missing default events.

[0095] When generating overdue records, the recorded information may include the borrower / lender identifier, contract number, number of overdue days, model output probability, judgment result (whether it constitutes an overdue payment or not), and judgment time. Overdue records are stored in the database and associated with the corresponding loan documents. Simultaneously with generating overdue records, the system can record the specific values ​​of each input feature for subsequent review and verification of the model's judgment results.

[0096] In one possible implementation, pushing the overdue record to the lender's client in step S205 may specifically include: S2053: Based on the overdue record, update the borrower's performance status to overdue status and push the updated performance status to the lender's client.

[0097] The performance status reflects the stage a borrower is in during the loan performance process. During stages such as loan application upload, document verification, document signing, and repayment reminders, the borrower's performance status can be at different stages, such as "Application in Progress," "Document Verification in Progress," "Pending Signing," "Performance in Progress," "Overdue," and "Repaid." When an overdue record is generated, the system determines the performance status to be updated based on the overdue conclusion (e.g., whether it constitutes an overdue payment or not). For example, if it constitutes an overdue payment, the borrower's performance status is updated from "Performance in Progress" to "Overdue"; if the borrower subsequently repays, the status is further updated to "Repaid." The system encapsulates the updated performance status along with information such as the overdue record, borrower identifier, and contract number, and pushes it to the lender's client via a communication interface. Push methods can include in-app message push, SMS notification, or API callback, ensuring that the lender can promptly receive changes in the borrower's performance status.

[0098] S2054: Record the push time. The complete operation sequence from the loan application to the performance status push is recorded in a chain storage structure with hash verification to form performance chain data.

[0099] The complete operation sequence covers the entire lending process, including but not limited to: loan application upload time, document verification time, notification of supplementary upload time, receipt of supplementary upload document time, electronic loan document generation time, document push time, signature confirmation time, repayment reminder sending time (may include multiple times), overdue days calculation time, overdue record generation time, and overdue record push time. Each operation corresponds to one record, which includes the operation type, operation time, operation result, and associated file hash value or related data summary.

[0100] The chain-like storage structure borrows from the data organization method of blockchain. Each record, when stored, contains not only its own operation information but also the overall hash value of the previous record, and its own content hash value is also calculated and stored. Specifically, the first record calculates its own hash value; the second record stores the hash value of the first record and calculates a new hash value based on its own content and the hash value of the first record; subsequent records follow the same pattern. This structure ensures that if any record is tampered with, its hash value changes, causing the hash verification of all subsequent records to fail, thus guaranteeing the integrity and immutability of the performance chain data. In case of disputes or when auditing is required, the authenticity, completeness, and unmodified nature of the entire operation sequence can be confirmed by verifying the hash values ​​of each record.

[0101] This manual achieves systematization and intelligence in loan management by constructing a fully automated closed loop from voucher verification, resubmission, electronic document generation and signing, dynamic reminders to overdue assessment. In the application stage, the completeness verification of voucher documents and automatic triggering of resubmission solve the problem of timely replacement of missing vouchers, reducing manual review intervention. In the document signing stage, electronic generation and standardized embedding improve signing efficiency and legal validity. In the repayment management stage, the reminder frequency is dynamically adjusted based on the remaining repayment time, matching the reminder intensity with the overdue risk and enhancing the timeliness and effectiveness of reminders. In the overdue identification stage, a multi-dimensional feature overdue identification model is used for comprehensive assessment, improving the objectivity and accuracy of overdue judgment. This manual achieves seamless integration of the entire process from voucher archiving to repayment reminders, protecting the rights and interests and fund security of both lenders and borrowers.

[0102] Please see Figure 4 This manual also provides a loan certificate management and automatic repayment reminder system, including: The credential verification module is used to obtain the loan application uploaded by the lending client, verify the credential files and personal information carried in the loan application to obtain the verification result, and the verification result is used to indicate whether there are any missing items in the credential file; The retransmission processing module is used to send a retransmission notification to the lending client when there are missing items, so that the lending client can update the voucher file; The document generation module is used to generate an electronic loan document based on the updated voucher document if there are no missing items. The electronic loan document includes the expected repayment date. The signature confirmation module is used to push the electronic loan document to the lender's client to update the electronic loan document based on the lender's signature information; The reminder management module is used to extract the expected repayment date from the electronic loan document, continuously update the remaining repayment time based on the current date and the expected repayment date, dynamically adjust the reminder frequency according to the remaining repayment time, and send repayment reminders to the lender's client based on the reminder frequency; The overdue processing module is used to determine the number of overdue days based on the repayment information uploaded by the lender's client, evaluate whether the lender has defaulted based on the number of overdue days using a pre-trained overdue identification model, generate an overdue record, and push the overdue record to the lender's client.

[0103] Figure 5This diagram illustrates a system architecture for an application scenario according to an embodiment of this application. The system includes a lending client 51, a borrower client 53, and a management server 52. The lending client 51 and the management server 52, as well as the borrower client 53 and the management server 52, can be connected via a network. The management server 52 includes the aforementioned voucher verification module, re-transmission processing module, document generation module, signature confirmation module, reminder management module, and overdue processing module, to achieve fully automated management of the entire process from voucher archiving to overdue reminders.

[0104] The embodiments of the subject matter and functional operation described in this specification can be implemented in the following ways: digital electronic circuits, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or combinations thereof. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions encoded on a tangible, non-transitory program carrier for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. Alternatively or additionally, the program instructions may be encoded on artificially generated propagation signals, such as machine-generated electrical, optical, or electromagnetic signals, which are generated to encode information and transmit it to a suitable receiving device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or combinations thereof.

[0105] The processing and logic described in this specification can be executed by one or more programmable computers that execute one or more computer programs to perform corresponding functions by operating on input data and generating output.

[0106] Suitable computers for executing computer programs include, for example, general-purpose and / or special-purpose microprocessors, or any other type of central processing unit. Typically, the central processing unit receives instructions and data from read-only memory and / or random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as disks, magneto-optical disks, or optical disks, or the computer will be operatively coupled to such mass storage devices to receive data from or transfer data to them, or both. However, a computer is not required to have such devices. Furthermore, a computer can be embedded in another device, such as a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0107] Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, such as semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry.

[0108] While this specification contains numerous specific implementation details, these should not be construed as limiting the scope of any invention or the scope of the claims, but rather are primarily intended to describe features of specific embodiments of a particular invention. Certain features described in the various embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in a single embodiment may also be implemented separately in various embodiments or in any suitable sub-combination. Furthermore, while features may function in certain combinations as described above and even initially claimed in this way, one or more features from a claimed combination may be removed from that combination in some cases, and a claimed combination may refer to a sub-combination or a variation thereof.

[0109] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or requiring all illustrated operations to be performed to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system modules and components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0110] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0111] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for managing loan vouchers and automatically reminding borrowers of repayments, characterized in that, include: The system retrieves loan applications uploaded by the lending client, verifies the supporting documents and personal information carried in the loan application to obtain verification results, and the verification results are used to indicate whether there are any missing items in the supporting documents; In the event of missing items, a retransmission notification is sent to the lending client to enable the lending client to update the voucher file; If the updated voucher file does not contain any missing items, an electronic loan document is generated based on the voucher file, and the electronic loan document includes the expected repayment date. The electronic loan document is pushed to the lender's client to update the electronic loan document based on the lender's signature information; The expected repayment date is extracted from the electronic loan document, and the remaining repayment time is continuously updated based on the current date and the expected repayment date. The reminder frequency is dynamically adjusted according to the remaining repayment time, and repayment reminders are sent to the lender's client based on the reminder frequency. The number of overdue days is determined based on the repayment information uploaded by the lender's client. A pre-trained overdue identification model is used to assess whether the lender has defaulted based on the number of overdue days and generates an overdue record. The overdue record is then pushed to the lender's client.

2. The method for managing loan vouchers and automatically reminding repayments according to claim 1, characterized in that, The verification results obtained from the verification of the supporting documents and personal information carried in the loan application include: The clarity index of the voucher document is calculated. If the clarity index is lower than a preset threshold, the voucher document is image-enhanced using an image enhancement algorithm. The voucher document includes the identity image of the borrower / lender, a scanned copy of the loan agreement, and supporting documents. Personal information is extracted from the identity images, scanned copies of loan receipts, and supporting documents using character recognition technology; The personal information carried in the loan application is compared with the extracted personal information to obtain the verification result.

3. The method for managing loan vouchers and automatically reminding repayments according to claim 1, characterized in that, The supplementary notification is generated by embedding the missing item into a preset information template; the verification of the voucher documents and personal information carried in the loan application to obtain the verification result also includes: The voucher file is compared with a preset voucher template to identify missing items in the borrower's identity image, scanned copy of the loan agreement, and supporting documents.

4. The method for managing loan vouchers and automatically reminding repayments according to claim 1, characterized in that, Updating the credential file includes: Obtain the re-uploaded files from the lending client for the missing items; The type of the re-uploaded file is identified to verify whether the type of the re-uploaded file is consistent with that of the missing item; After successful verification, the supplementary file is added to or replaced in the voucher file, and the updated voucher file is marked as complete; wherein, the complete status is used to indicate that the updated voucher file has no missing items.

5. The method for managing loan vouchers and automatically reminding repayments according to claim 1, characterized in that, The step of generating electronic loan documents based on the voucher documents includes: Obtain the document data structure from the preset template, generate document data based on the document data structure, and embed the expected repayment date as a structured field into the document data; The document data is encrypted, and integrity verification information is generated. The integrity verification information is then associated with the encrypted document data to obtain a standardized electronic loan document.

6. The method for managing loan vouchers and automatically reminding repayments according to claim 1, characterized in that, Updating the electronic loan document based on the lender's signature information includes: Receive the signature confirmation response returned by the lending client, and extract the signature time from the signature confirmation response; The signature time is embedded as a timestamp into the electronic loan document, and the signature confirmation response, timestamp, and embedded electronic loan document are stored together.

7. The method for managing loan vouchers and automatically reminding repayments according to claim 1, characterized in that, The method of dynamically adjusting the reminder frequency based on the remaining repayment time includes: Set multiple preset time intervals to determine the time interval to which the remaining repayment time belongs; The frequency corresponding to the time interval is matched, and the sending interval is shortened as the remaining repayment time decreases to increase the reminder frequency.

8. The method for managing loan vouchers and automatically reminding repayments according to claim 1, characterized in that, The step of assessing whether the borrower is in default based on the number of overdue days using the overdue identification model and generating an overdue record includes: Get the number of overdue days between the actual repayment date and the expected repayment date; The overdue days, loan amount, and borrower's credit history characteristics are input into the overdue identification model; wherein, the overdue identification model adopts the logistic regression algorithm, and constructs a mapping relationship between the input and the overdue result based on training samples; The output value of the overdue identification model is compared with a preset threshold. Based on the comparison result, it is determined whether the overdue period has been reached, and an overdue record containing the determination result is generated.

9. The method for managing loan vouchers and automatically reminding repayments according to claim 1, characterized in that, The step of pushing the overdue record to the lender's client includes: Based on the overdue records, the borrower's performance status is updated to overdue, and the updated performance status is pushed to the lender's client. The push time is recorded, and the complete operation sequence from uploading the loan application to the push of the performance status is recorded in a chain storage structure with hash verification to form performance chain data.

10. A loan voucher management and automatic repayment reminder system, characterized in that, include: The credential verification module is used to obtain the loan application uploaded by the lending client, verify the credential files and personal information carried in the loan application to obtain the verification result, and the verification result is used to indicate whether there are any missing items in the credential file; The retransmission processing module is used to send a retransmission notification to the lending client when there are missing items, so that the lending client can update the voucher file; The document generation module is used to generate an electronic loan document based on the updated voucher document if there are no missing items. The electronic loan document includes the expected repayment date. The signature confirmation module is used to push the electronic loan document to the lender's client to update the electronic loan document based on the lender's signature information; The reminder management module is used to extract the expected repayment date from the electronic loan document, continuously update the remaining repayment time based on the current date and the expected repayment date, dynamically adjust the reminder frequency according to the remaining repayment time, and send repayment reminders to the lender's client based on the reminder frequency; The overdue processing module is used to determine the number of overdue days based on the repayment information uploaded by the lender's client, evaluate whether the lender has defaulted based on the number of overdue days using a pre-trained overdue identification model, generate an overdue record, and push the overdue record to the lender's client.

Images