Loan amount processing method, loan server and storage medium
The loan processing method and server system enable direct access to a shared credit limit, addressing inefficiencies in loan financing for enterprises with low credit scores by enhancing efficiency and fund control for financial institutions.
Patent Information
- Authority / Receiving Office
- HK · HK
- Patent Type
- Applications
- Current Assignee / Owner
- SHANGHAI ANT CHUANGJIANG INFORMATION TECHNOLOGY CO LTD
- Filing Date
- 2026-04-21
- Publication Date
- 2026-07-10
AI Technical Summary
Enterprises, especially SMEs and startups, face challenges in obtaining timely loan financing due to low credit scores, leading to rejected loan applications and inefficient, lengthy fund transfer processes through multiple nodes, with financial institutions lacking control over fund usage.
A loan processing method and server system that allows a first entity to directly access a shared credit limit from a second entity's pool, with authorization, improving efficiency and enabling financial institutions to manage and control funds effectively.
Enhances loan efficiency by shortening fund transfer paths and allowing financial institutions to monitor fund usage, thereby improving financial management and control.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202511632238.0 (22) Application Date 2025.11.07 (71) Applicant Ant International Business (Shanghai) Co., Ltd. Address Room 1408, No. 447, Nanquan North Road, China (Shanghai) Pilot Free Trade Zone, Pudong New Area, Shanghai 200131, China (72) Inventor Li Yan (74) Patent Agency Beijing Liuli Intellectual Property Agency (General Partnership) 16049 Patent Attorney Zhu Lefang (51) Int.Cl. G06Q 40 / 03 (2023.01) G06Q 10 / 0631 (2023.01) (54) Invention Title Loan Limit Processing Method, Loan Server and Storage Medium (57) Abstract This specification provides a loan limit processing method, a loan server and a storage medium. The loan server receives a credit limit allocation request from a first terminal device corresponding to a first entity. This request requests that at least a portion of the available credit limit of a second entity be allocated to the first entity. Based on the credit limit allocation request, the loan server generates an authorization task, sends the authorization task to the second terminal device corresponding to the second entity, and receives the execution result of the authorization task from the second terminal device. The authorization task inquires whether the second entity agrees to allocate credit limit to the first entity. Furthermore, if the execution result indicates agreement, the loan server determines the target credit limit that the second entity agrees to allocate to the first entity, allocates the target credit limit to the first entity's first loan account, and reduces the target credit limit from the second entity's available credit limit. Claims 3 pages, Description 16 pages, Drawings 5 pages, CN 121146891 A 2025.12.16 CN 1 21 14 68 91 A 1. A method for processing loan limits, applied to a loan server, the method comprising: receiving a limit allocation request from a first terminal device corresponding to a first subject, the limit allocation request being used to request that at least a portion of the available limit of a second subject be allocated to the first subject; generating an authorization task based on the limit allocation request, wherein the authorization task is used to inquire whether the second subject agrees to allocate a limit to the first subject; sending the authorization task to a second terminal device corresponding to the second subject, and receiving the execution result of the authorization task from the second terminal device; and, if the execution result indicates agreement, determining a target limit that the second subject agrees to allocate to the first subject, allocating the target limit to a first loan account of the first subject, and reducing the target limit from the available limit of the second subject. 2. The method according to claim 1, wherein the second subject corresponds to at least one second loan account,The at least one second loan account includes a target loan account of a shared type; the authorization task is used to inquire whether the second entity agrees to allocate the available credit limit in the target loan account to the first entity. 3. The method according to claim 2, wherein the method further includes: receiving a loan request from the second terminal device, the loan request including at least qualification certificate information corresponding to the second entity, the loan request being used to apply for a loan limit that can be shared with other entities; and, if it is determined based on the qualification certificate information that the second entity meets the loan conditions, determining the loan limit corresponding to the second entity, generating the target loan account for the second entity, using the loan limit as the available credit limit of the target loan account, and setting the type of the target loan account to a shared type. 4. The method according to claim 3, wherein the loan request further includes: trade document information between the second entity and at least one other entity; after generating the target loan account for the second entity, the method further includes: binding the target loan account with the at least one other entity, so that the at least one other entity has the right to share the credit limit of the target loan account. 5. The method of claim 2, wherein generating an authorization task based on the credit limit allocation request includes: determining whether the first entity has credit limit sharing authority over the target loan account; and generating the authorization task based on the credit limit allocation request if the first entity has credit limit sharing authority over the target loan account. 6. The method of claim 5, wherein the credit limit allocation request includes at least: trade document information between the first entity and the second entity; determining whether the first entity has credit limit sharing authority over the target loan account includes: obtaining the trade document information from the credit limit allocation request, and determining the closeness of the trade relationship between the first entity and the second entity based on the trade document information; and determining whether the first entity has credit limit sharing authority over the target loan account based on the closeness of the trade relationship. 7. The method according to claim 5, wherein the target loan account is pre-bound to at least one candidate entity, and determining whether the first entity has the right to share the credit limit of the target loan account includes: if the first entity is included among the at least one candidate entity, then determining that the first entity has the right to share the credit limit of the target loan account; or if the first entity is not included among the at least one candidate entity, then determining that the first entity does not have the right to share the credit limit of the target loan account. 8. The method according to claim 1, wherein after generating the authorization task, the method further includes: generating...The method according to claim 8, wherein after generating the access link corresponding to the authorization task, the method further includes: setting the validity period range of the access link; sending the authorization task to the second terminal device, wherein if the current time is outside the validity period range, the method further includes: sending a first prompt message to the second terminal device, wherein the first prompt message is used to prompt that the authorization task has expired. 10. The method according to claim 9, wherein the method further includes: if the current time is outside the validity period range, sending a first prompt message to the second terminal device, wherein the first prompt message is used to prompt that the authorization task has expired. 11. The method according to claim 1, wherein the quota allocation request includes a first quota requested by the first subject, the authorization task is used to ask the second subject whether it agrees to allocate the first quota to the first subject; determining the target quota that the second subject agrees to allocate to the first subject includes: determining the first quota as the target quota. 12. The method of claim 1, wherein, when the execution result indicates agreement, the execution result includes the second entity agreeing to allocate a second amount to the first entity; determining the target amount agreed to be allocated by the second entity to the first entity includes: determining the second amount as the target amount. 13. The method of claim 1, wherein, after allocating the target amount to the first entity's first loan account, the method further includes: receiving a withdrawal request corresponding to the first loan account from the first terminal device; determining a first amount requested by the first entity based on the withdrawal request, and determining the first entity's withdrawal account; transferring funds corresponding to the first amount to the first entity's withdrawal account, and reducing the corresponding amount from the available credit limit of the first loan account. 14. The method of claim 13, wherein, after transferring funds corresponding to the first amount to the first entity's withdrawal account, the method further includes: receiving a repayment request from the first terminal device; and, based on the repayment request, deducting at least a portion of funds from the first entity's repayment account for repayment, and increasing the corresponding amount from the available credit limit of the first loan account based on the amount of repayment funds. 15. The method of claim 13, wherein after transferring funds corresponding to the first amount to the first subject's account, the method further comprises at least one of the following:If the repayment deadline for the funds corresponding to the first amount is detected, a second reminder message is sent to the first terminal device (see page 2 / 3 of claim 3, CN 121146891 A), the second reminder message being used to remind the first entity to make repayment; If the repayment deadline for the funds corresponding to the first amount is detected, a third reminder message is sent to the second terminal device, the third reminder message being used to remind the second entity to make repayment, or to remind the second entity to urge the first entity to make repayment; If the repayment deadline for the funds corresponding to the first amount is detected, at least a portion of the funds is deducted from the first entity's repayment account for repayment, and a corresponding amount is added to the available credit limit of the first loan account based on the amount of repayment funds; or If the repayment deadline for the funds corresponding to the first amount is detected and the funds in the first entity's repayment account are insufficient for repayment, at least a portion of the funds is deducted from the second entity's repayment account for repayment, and a corresponding amount is added to the available credit limit of the first loan account based on the amount of repayment funds. 16. The method according to claim 1, wherein, after receiving the execution result, the method further comprises: sending a fourth prompt message to the first terminal device if the execution result indicates disagreement, the fourth prompt message being used to prompt the first subject that the credit limit allocation has failed. 17. A loan server, comprising: at least one storage medium storing at least one instruction set; and at least one processor communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and executes the method according to any one of claims 1-16 according to the instructions of the at least one instruction set. 18. A computer-readable non-transitory storage medium, wherein the computer-readable non-transitory storage medium stores at least one instruction set, and when the at least one instruction set is executed by the at least one processor, it implements the method according to any one of claims 1-16. Claims 3 / 3 Page 4 CN 121146891 A Method for processing loan limits, loan server and storage medium Technical Field
[0001] This specification relates to the field of Internet technology, and in particular to a method for processing loan limits, a loan server and storage medium. Background Art
[0002] Enterprises often face the need for loan financing during their operations. For example, for enterprises engaged in cross-border trade, due to the characteristics of long logistics time, long customs review time, and long trade risk review time, the payment terms of enterprises engaged in cross-border trade are long, which easily leads to short-term capital shortage problems and makes it impossible to respond to market demands in a timely manner (such as stocking up in advance). In this case, these enterprises hope to obtain financing from financial institutions to alleviate the above-mentioned cash flow problems. HoweverHowever, some enterprises (especially SMEs or startups) have low credit scores, making it difficult to meet the credit assessment standards of financial institutions, resulting in loan applications being rejected.
[0003] To address this issue, these enterprises that actually use the funds usually seek help from third-party entities (such as guarantee institutions, affiliated companies, or large groups with excellent credit). For example, the third-party entity applies for a loan from a financial institution based on its creditworthiness, and after the funds are approved, the third-party entity transfers the loan funds to the enterprise that actually uses the funds. The enterprise that actually uses the funds repays the funds to the third-party entity as agreed, and then the third-party entity fulfills its repayment obligation to the financial institution. However, in the above method, the loan funds need to flow through multiple nodes in sequence (financial institution, third-party entity, enterprise that actually uses the funds), resulting in a long flow chain and low loan efficiency. In addition, financial institutions cannot understand the use of funds by the actual borrower, making it impossible for financial institutions to effectively control and manage the loan funds.
[0004] The content of the background technology section is merely information known only to the inventor and does not mean that the above information had entered the public domain before the date of this disclosure, nor does it mean that it can be considered prior art of this disclosure.
[0005] This specification provides a loan processing method, a loan server, and a storage medium. With authorization from a second entity, the credit limit in the credit pool can be allocated to a first entity, which not only improves the loan efficiency of the first entity but also helps financial institutions effectively manage and control funds.
[0006] In a first aspect, this specification provides a loan credit limit processing method applied to a loan server. The method includes: receiving a credit limit allocation request from a first terminal device corresponding to a first entity, the credit limit allocation request requesting at least a portion of the available credit limit of a second entity to be allocated to the first entity; generating an authorization task based on the credit limit allocation request, wherein the authorization task is used to inquire whether the second entity agrees to allocate a credit limit to the first entity; sending the authorization task to a second terminal device corresponding to the second entity and receiving the execution result of the authorization task from the second terminal device; and, if the execution result indicates agreement, determining a target credit limit that the second entity agrees to allocate to the first entity, allocating the target credit limit to a first loan account of the first entity, and reducing the target credit limit from the available credit limit of the second entity.
[0007] In some embodiments, the second subject corresponds to at least one second loan account, the at least one second loan account including a shared target loan account; the authorization task is used to inquire whether the second subject agrees to allocate the available credit in the target loan account to the first subject. Specification 1 / 16 pages 5 CN 121146891 A
[0008] In some embodiments, the method further includes: receiving a loan request from the second terminal device, the loanThe request includes at least the qualification certificate information corresponding to the second entity, and the loan request is used to apply for a loan limit that can be shared with other entities; and if it is determined that the second entity meets the loan conditions based on the qualification certificate information, the loan limit corresponding to the second entity is determined, the target loan account is generated for the second entity, the loan limit is used as the available limit of the target loan account, and the type of the target loan account is set to a shared type.
[0009] In some embodiments, the loan request further includes: trade document information between the second entity and at least one other entity; after generating the target loan account for the second entity, the method further includes: binding the target loan account with the at least one other entity so that the at least one other entity has the right to share the limit of the target loan account.
[0010] In some embodiments, generating an authorization task based on the limit allocation request includes: determining whether the first entity has the right to share the limit of the target loan account; and if the first entity has the right to share the limit of the target loan account, generating the authorization task based on the limit allocation request.
[0011] In some embodiments, the credit limit allocation request includes at least: trade document information between the first entity and the second entity. Determining whether the first entity has credit limit sharing rights to the target loan account includes: obtaining the trade document information from the credit limit allocation request, and determining the closeness of the trade relationship between the first entity and the second entity based on the trade document information; and determining whether the first entity has credit limit sharing rights to the target loan account based on the closeness of the trade relationship.
[0012] In some embodiments, the target loan account is pre-bound to at least one candidate entity. Determining whether the first entity has credit limit sharing rights to the target loan account includes: if the first entity is included in the at least one candidate entity, then the first entity has credit limit sharing rights to the target loan account; or if the first entity is not included in the at least one candidate entity, then the first entity does not have credit limit sharing rights to the target loan account.
[0013] In some embodiments, after generating the authorization task, the method further includes: generating an access link corresponding to the authorization task and sending the access link to the first terminal device so that the first terminal device forwards the access link to the second terminal device; sending the authorization task to the second terminal device corresponding to the second subject includes: in response to receiving an access request for the access link from the second terminal device, sending the authorization task to the second terminal device.
[0014] In some embodiments, after generating the access link corresponding to the authorization task, the method further includes: setting the validity period range of the access link; sending the authorization task to the second terminal device, including: sending the authorization task to the second terminal device when the current time is within the validity period range.
[0015] In some embodiments, the method further includes: sending a first prompt message to the second terminal device when the current time is outside the validity period range, the first prompt message being used to prompt that the authorization task has expired.
[0016] In some embodiments, the quota allocation request includes a first quota requested by the first subject, the authorization task being used to ask the second subject whether it agrees to allocate the first quota to the first subject; determining the target quota that the second subject agrees to allocate to the first subject includes: determining the first quota as the target quota.
[0017] In some embodiments, when the execution result indicates agreement, the execution result includes a second quota that the second subject agrees to allocate to the first subject; determining the target quota that the second subject agrees to allocate to the first subject includes: determining the second quota as the target quota.
[0018] In some embodiments, after allocating the target amount to the first loan account of the first subject, the method further includes: receiving a withdrawal request corresponding to the first loan account from the first terminal device; determining a first amount requested by the first subject to withdraw based on the withdrawal request, and determining the withdrawal account of the first subject; and transferring funds corresponding to the first amount to the withdrawal account of the first subject, and reducing the corresponding amount in the available credit limit of the first loan account.
[0019] In some embodiments, after transferring funds corresponding to the first amount to the withdrawal account of the first subject, the method further includes: receiving a repayment request from the first terminal device; and deducting at least a portion of the funds from the repayment account of the first subject for repayment based on the repayment request, and increasing the corresponding amount in the available credit limit of the first loan account based on the amount of repayment funds.
[0020] In some embodiments, after transferring funds corresponding to the first amount to the first subject's account, the method further includes at least one of the following: when it is detected that the funds corresponding to the first amount are nearing the repayment deadline, sending a second reminder message to the first terminal device, the second reminder message being used to remind the first subject to make repayment; when it is detected that the funds corresponding to the first amount are nearing the repayment deadline, sending a third reminder message to the second terminal device, the third reminder message being used to remind the second subject to make repayment, or to remind...The second entity urges the first entity to make repayments; if it is detected that the funds corresponding to the first amount have reached the repayment deadline, at least a portion of the funds are deducted from the repayment account of the first entity for repayment, and a corresponding amount is added to the available credit limit of the first loan account based on the amount of repayment funds; or if it is detected that the funds corresponding to the first amount have reached the repayment deadline and the funds in the repayment account of the first entity are insufficient for repayment, at least a portion of the funds are deducted from the repayment account of the second entity for repayment, and a corresponding amount is added to the available credit limit of the first loan account based on the amount of repayment funds.
[0021] In some embodiments, after receiving the execution result, the method further includes: if the execution result indicates disagreement, sending a fourth prompt message to the first terminal device, the fourth prompt message being used to prompt the first entity that the credit limit allocation has failed.
[0022] In a second aspect, this specification also provides a loan server, including: at least one storage medium storing at least one instruction set; and at least one processor communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and executes the method as described in any of the first aspects above according to the instructions of the at least one instruction set.
[0023] In a third aspect, this specification also provides a computer-readable non-transitory storage medium, wherein the computer-readable non-transitory storage medium stores at least one instruction set, which, when executed by at least one processor, implements the method as described in any one of the first aspects above.
[0024] Other functions of the loan amount processing method, loan server, and storage medium provided in this specification will be partially listed in the following description. The inventive aspects of the loan amount processing method, loan server, and storage medium provided in this specification can be fully explained by practice or use of the methods, apparatus, and combinations described in the detailed examples below. Brief Description of the Drawings
[0025] In order to more clearly illustrate the technical solutions in the embodiments of this specification, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.
[0026] Figure 1 shows a schematic diagram of a loan scenario provided according to an embodiment of this specification; Figure 2 shows an architecture diagram of an implementation system for the loan scenario provided according to an embodiment of this specification; Figure 3 shows a schematic diagram of the hardware structure of a computing device provided according to an embodiment of this specification; Figure 4 shows a flowchart of a loan amount processing method provided according to an embodiment of this specification;Figure 5 shows a schematic diagram of a set of interactive pages provided according to an embodiment of this specification; Figure 6 shows a schematic diagram of another set of interactive pages provided according to an embodiment of this specification; Figure 7 shows a schematic diagram of yet another set of interactive pages provided according to an embodiment of this specification; Figure 8 shows a schematic diagram of quota allocation provided according to an embodiment of this specification. Detailed Description
[0027] The following description provides specific application scenarios and requirements for this specification, intended to enable those skilled in the art to make and use the contents of this specification. Various partial modifications to the disclosed embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and applications without departing from the spirit and scope of this specification. Therefore, this specification is not limited to the embodiments shown, but is the widest scope consistent with the claims.
[0028] The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not restrictive. For example, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” used herein may also include the plural forms. When used in this specification, the terms "comprising," "including," and / or "containing" mean that the associated integers, steps, operations, elements, and / or components are present, but do not exclude the presence of one or more other features, integers, steps, operations, elements, components, and / or groups, or that other features, integers, steps, operations, elements, components, and / or groups may be added to the system / method.
[0029] In this specification, "X comprises at least one of A, B, or C" means that X comprises at least A, or X comprises at least B, or X comprises at least C. That is, X may comprise only one of A, B, and C, or any combination of A, B, and C, as well as other possible contents / elements. The arbitrary combination of A, B, and C may be A, B, C, AB, AC, BC, or ABC.
[0030] In view of the following description, these and other features of this specification, as well as the operation and function of the related elements of the structure, and the economy of the combination and manufacture of the components, can be significantly improved. All of these form part of this specification with reference to the accompanying drawings. However, it should be clearly understood that the accompanying drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of this specification. It should also be understood that the drawings are not drawn to scale.
[0031] The flowcharts used in this specification illustrate the operations of a system implementation according to some embodiments of this specification. It should be clearly understood that the operations in the flowcharts may not be implemented in a sequential order. Instead, the operations may be implemented in reverse order or simultaneously. Furthermore, one or more other operations may be added to the flowchart. One or more operations may be removed from the flowchart.
[0032] The technical solutions provided in this specification are applicable to loan scenarios. The following examples, in conjunction with Figure 1, illustrate the application scenarios to which this specification applies.
[0033] Figure 1 shows a schematic diagram of a loan scenario provided according to an embodiment of this specification. As shown in Figure 1, the application scenario 100 may include a financial institution 150, a second entity 130, and at least one first entity 110 (e.g., entity A, entity B, entity C, etc.). Specification 4 / 16 pages 8 CN 121146891 A
[0034] Wherein, the financial institution 150 is a lender that provides credit and loan services to the first entity 110 and the second entity 130. The financial institution 150 includes, but is not limited to, banks, securities companies, insurance companies, trust companies, payment institutions, fund management companies, financial leasing companies, etc.
[0035] The first entity 110 and the second entity 130 are both borrowers, who are the parties requesting loans from the financial institution 150. It should be noted that the first entity 110 and the second entity 130 may be individuals, enterprises, or even countries, etc., which are not limited in this specification. When such entities apply for loans from financial institutions, they become the objects of evaluation. Financial institutions conduct a comprehensive assessment of the financial status, credit information, asset and liability information, and income and expenditure of these entities to determine specific credit conditions (such as interest rates, terms, and limits). In some embodiments, the second entity 130 may be an entity that meets the credit assessment standards of the financial institution 150, and the first entity 110 may be an entity that does not meet the credit assessment standards of the financial institution 150. In this specification, both the first entity 110 and the second entity 130 may be referred to as loan entities, credit entities, borrowing entities, etc.
[0036] Referring to Figure 1, the second entity 130 may initiate a credit application to the financial institution 150 based on its creditworthiness, and obtain a credit limit pool after being reviewed and approved by the financial institution 150.
[0037] In some embodiments, the second entity 130 may request credit from the financial institution 150 in ways including but not limited to the following: (1) Letter of credit. A letter of credit is a payment commitment instrument that the second entity 130 applies to the financial institution 150 for based on its good creditworthiness. After review and approval, the financial institution 150 approves the letter of credit credit limit for the second entity 130. When a transaction occurs, the second entity 130 may designate the first entity 110 or other counterparty as the beneficiary of the letter of credit. As long as the beneficiary submits documents that comply with the terms of the letter of credit, the financial institution 150 assumes the payment responsibility and pays the corresponding amount to the beneficiary as agreed.
[0038] (2) Trade finance loan. A trade finance loan refers to a short-term financing application made by the second entity 130 (buyer or seller) to the financial institution 150 based on a genuine trade contract between itself and its counterparty. The financial institution 150 determines the credit limit based on factors such as the credit status, transaction background, and repayment ability of the second entity 130, and provides corresponding loan funds support to the second entity 130 within the credit limit after the credit approval is approved.
[0039] (3) Accounts receivable factoring. Accounts receivable factoring refers to the second entity 130 transferring its accounts receivable to the financial institution 150 in exchange for early repayment. The financial institution 150 determines the corresponding factoring limit based on the quality of the accounts receivable, the credit status of the counterparty, and the credit rating of the second entity 130, and provides financing support to the second entity 130 within this limit.
[0040] (4) Buyer credit. Buyer credit is a loan directly issued by the financial institution 150 to the buyer to pay the seller. That is, the second entity 130, as the buyer, applies to the financial institution 150 for short-term financing to support the transaction based on the trade contract between it and the seller. The financial institution 150 allocates a special limit to the second entity 130 based on the credit status, transaction background, and repayment ability of the second entity 130. Thus, the second entity 130 uses the special limit to pay the seller. Continuing to refer to Figure 1, the limit in the limit pool obtained by the second entity 130 can be shared with one or more first entities 110. With authorization from the second entity 130, the credit limit in the credit pool can be allocated to one or more first entities 110. For example, referring to Figure 1, the financial institution 150 can allocate a portion of the credit limit in the credit pool to entity A, another portion to entity B, and yet another portion to entity C. Based on this, each first entity 110 can directly draw funds from the financial institution 150 based on its allocated credit limit. In some embodiments, the second entity 130 can also directly draw funds from the financial institution 150 based on the credit limit in the credit pool.
[0041] Compared to the method where the second entity 130 first draws funds from the credit pool and then transfers the funds to the first entity 110, the technical solution provided in this specification can shorten the fund transfer path and improve the loan efficiency of the first entity 110. In addition, since the credit limit of the first entity 110 is allocated by the financial institution 150, and the first entity 110 directly uses funds from the financial institution 150, the financial institution 150 can understand the actual use of funds by the first entity 110, thereby effectively controlling and managing the funds.
[0042] In the scenario shown in Figure 1, the credit limit pool obtained by the second entity 130 through the credit granting process is a shared credit limit pool, and the credit limit in this pool can be shared by multiple first entities 110. If the shared credit limit pool scheme is not adopted, the second entity 130 needs to specifically help the first entity 110 apply for credit from the financial institution 150 each time it receives a request from the first entity 110, and provide the credit limit obtained through the credit granting to the first entity 110 for its exclusive use. When multiple first entities 110 seek help from the second entity 130, the second entity 130 needs to grant credit to the financial institution 150 multiple times, and each time the credit granting is completed...Each entity 110 needs to submit transaction contracts, credit certificates, financial statements, and other materials to financial institution 150. However, with the shared credit pool scheme, the second entity 130 can obtain a credit pool that can be shared by multiple first entities 110 by applying for credit from financial institution 150 once, thereby avoiding the second entity 130 from repeatedly initiating the credit granting process and submitting supporting materials to financial institution 150 multiple times.
[0043] It should be noted that there may or may not be a trade relationship between the first entity 110 and the second entity 130, and there are no restrictions on the trade relationship between them. When there is a trade relationship between them, it can be a cross-border trade relationship or a non-cross-border trade relationship. In addition, when there is a trade relationship between them, the direction of the trade relationship can be arbitrary. For example, it can be that the second entity 130 sells goods or provides services to the first entity 110, or the first entity 110 supplies goods or performs contracts to the second entity 130. Figure 2 shows the architecture diagram of the implementation system 200 of the loan scenario 100 provided according to the embodiments of this specification. As shown in Figure 1, the implementation system 200 may include a loan server 160, a second terminal device 140, and at least one first terminal device 120.
[0044] The first terminal device 120 refers to the terminal device corresponding to the first entity 110. For example, the first entity 110-A corresponds to the first terminal device 120-A, the first entity 110-B corresponds to the first terminal device 120-B, and the first entity 110-C corresponds to the first terminal device 120-C. The first entity 110 can submit a credit limit allocation request to the loan server 160 through the first terminal device 120 to request that at least a portion of the available credit limit of the second entity 130 be allocated to the first entity 110. The first entity 110 can also view and manage the credit limit information allocated to it by the loan server 160 through the first terminal device 120.
[0045] The second terminal device 140 refers to the terminal device corresponding to the second entity 130. The second entity 130 can initiate a loan request to the loan server 160 through the second terminal device 140, so that the loan server 160 can grant it a certain loan amount (i.e., a shared credit pool). The second entity 130 can also view its obtained loan amount through the second terminal device 140 and manage the allocation and use of the loan amount. For example, the second entity 130 can also perform an authorization task through the second terminal device 140 to authorize the loan server 160 to allocate a portion of the credit pool to the first entity 110.
[0046] In this specification, the terminal devices (first terminal device 120, second terminal device 140) may include mobile devices, tablet computers, laptop computers, built-in devices of motor vehicles or similar content, or any combination thereof. In some embodimentsIn this context, the mobile device may include smart home devices, smart mobile devices, virtual reality devices, augmented reality devices, or similar devices, or any combination thereof. In some embodiments, the smart home device may include a smart TV, a desktop computer, etc., or any combination thereof. In some embodiments, the smart mobile device may include a smartphone, a personal digital assistant, a gaming device, a navigation device, etc., or any combination thereof. In some embodiments, the virtual reality device or augmented reality device may include a virtual reality headset, virtual reality glasses, a virtual reality controller, an augmented reality headset, augmented reality glasses, an augmented reality controller, or similar content, or any combination thereof. For example, the virtual reality device or the augmented reality device may include smart glasses, a head-mounted display, VR, etc. In some embodiments, the built-in device in the motor vehicle may include an in-vehicle computer, an in-vehicle TV, etc. Specification 6 / 16 pages 10 CN 121146891 A
[0047] In some embodiments, the terminal device may have a client installed with the target application. The client is able to provide the first subject 110 or the second subject 130 with the ability and interface to interact with the loan server 160. In this case, the loan server 160 can be regarded as the server of the target application. The target application can be any application that provides loan services.
[0048] The loan server 160 refers to the server deployed by the financial institution 150, used to support data processing and interaction for credit approval, loan disbursement, credit limit management, and various financial services. The loan server 160 can communicate with the first terminal device 120 and the second terminal device 140 respectively. The loan server 160 can receive a credit limit allocation request from the first terminal device 120. The credit limit allocation request is used to request that at least a portion of the available credit limit of the second entity 130 be allocated to the first entity 110. After receiving the credit limit allocation request, the loan server 160 can generate an authorization task based on the credit limit allocation request. The authorization task is used to confirm with the second entity 130 whether it agrees to allocate a portion of its available credit limit to the first entity 110. Subsequently, the loan server 160 can send the authorization task to the second terminal device 140 and receive the execution result of the authorization task from the second terminal device 140. If the execution result indicates agreement, the loan server 160 can determine that the second entity 130 agrees to allocate the target credit limit to the first entity 110, allocate the target credit limit to the first loan account of the first entity 110, and reduce the target credit limit from the available credit limit of the second entity 130.
[0049] The loan processing method described later in this specification can be executed on the loan server 160. At this time, the loan server 160 can store data or instructions for implementing the loan processing method, and can execute or be used to execute the...Data or instructions. In some embodiments, the loan server 160 may include hardware devices with data processing capabilities and necessary programs to drive the hardware devices.
[0050] In this specification, the first terminal device 120 and the loan server 160, and the second terminal device 140 and the loan server 160, may be connected via a network. The network can facilitate the exchange of information or data. In some embodiments, the network may be any type of wired or wireless network, or a combination thereof. For example, the network may include a cable network, a wired network, a fiber optic network, a telecommunications network, an intranet, the Internet, a local area network (LAN), a wide area network (WAN), a wireless local area network (WLAN), a metropolitan area network (MAN), a public switched telephone network (PSTN), a Bluetooth network, a ZigBee network, a near field communication (NFC) network, or a similar network. In some embodiments, the network may include one or more network access points. For example, the network may include wired or wireless network access points, such as base stations or Internet exchange points, through which one or more components of the first terminal device 130, the second terminal device 140, and the loan server 160 may connect to the network to exchange data or information.
[0051] It should be understood that the number of the first terminal device 120, the second terminal device 140, and the loan server 160 in FIG2 is merely illustrative. Depending on implementation needs, any number of the first terminal device 120, the second terminal device 140, and the loan server 160 can be used.
[0052] FIG3 shows a schematic diagram of the hardware structure of a computing device 300 provided according to an embodiment of this specification. The computing device 300 can serve as the loan server 150 in FIG1, executing the loan amount processing method described in this specification.
[0053] As shown in FIG3, the computing device 300 may include at least one storage medium 230 and at least one processor 220. In some embodiments, the computing device 300 may further include a communication port 250 and an internal communication bus 210. The computing device 300 may also include an I / O component 240.
[0054] The internal communication bus 210 can connect different system components. For example, the internal communication bus 210 can connect the storage medium 230, the processor 220, the communication port 250, and the I / O component 240, etc.
[0055] I / O component 240 supports input / output between computing device 300 and other components.
[0056] Communication port 250 is used for data communication between computing device 300 and the outside world. For example, communication port 250 can be used for data communication between computing device 300 and wireless network. Communication port 250 can be a wired communication port or a wireless communication port.
[0057] Storage medium 230 may include a data storage device. The data storage device may be a computer-readable non-transitory storage medium or a computer-readable temporary storage medium. For example, the data storage device may include one or more of a disk 232, a read-only storage medium (ROM) 234, or a random access storage medium (RAM) 236. Storage medium 230 also includes at least one instruction set stored in the data storage device. The instruction set may include computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc. Storage medium 230 stores at least one set of instructions, which are computer program code. When these instruction sets are retrieved and executed by a processor, they can instruct the processor to perform specific functions or steps, such as the various methods and steps described later in this application.
[0058] At least one processor 220 may be communicatively connected to at least one storage medium 230. When the computing device 300 is running, at least one processor 220 reads the at least one set of instructions and executes the methods and steps provided in this specification according to the instructions of the at least one set of instructions. Processor 220 may be in the form of one or more processors. In some embodiments, processor 220 may include one or more hardware processors, such as microcontrollers, microprocessors, reduced instruction set computers (RISC), application-specific integrated circuits (ASICs), application-specific instruction set processors (ASIPs), central processing units (CPUs), graphics processing units (GPUs), physical processing units (PPUs), microcontroller units, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), advanced RISC machines (ARMs), programmable logic devices (PLDs), any circuit or processor capable of performing one or more functions, etc., or any combination thereof.
[0059] For illustrative purposes only, computing device 300 in the accompanying drawings shows only one processor 220. However, it should be noted that computing device 300 in this specification may also include multiple processors, and therefore, the operations and / or method steps disclosed in this specification may be performed by one processor or by multiple processors in combination. For example, if the processor 220 of the computing device 300 is described in this specification as executing steps A and B, it should be understood that steps A and B can also be executed jointly or separately by two different processors 220 (e.g., the first processor executes step A, the second processor executes step B, or the first and second processors jointly execute steps A and B).
[0060] FIG4 shows a schematic flowchart of a loan amount processing method P400 provided according to an embodiment of this specification. As before, the loan server can execute the loan amount processing method P400 described in this specification. Specifically, the loan...The processor in the server can read the instruction set stored in its local storage medium, and then execute the loan amount processing method P400 of this specification according to the provisions of the instruction set. As shown in Figure 4, the loan amount processing method P400 may include S420-S480.
[0061] S420: The loan server receives a credit limit allocation request from the first terminal device corresponding to the first subject. The credit limit allocation request is used to request that at least a portion of the available credit limit of the second subject be allocated to the first subject.
[0062] Wherein, the available credit limit of the second subject refers to the remaining available credit limit in the loan amount that the loan server (financial institution) has granted credit to the second subject. It is easy to understand that before S420, the second subject has applied for a certain loan amount from the loan server in advance.
[0063] When the first subject wants to share / use the available credit limit of the second subject, the first subject can initiate a credit limit allocation request through the first terminal device to request the loan server to allocate at least a portion of the available credit limit of the second subject to the first subject.
[0064] In some embodiments, the credit limit allocation request may include one or more of the following: the name of the second subject, the first credit limit requested, the expected usage period, and the purpose of the funds.
[0065] For example, FIG5 shows a schematic diagram of a set of interactive pages provided according to an embodiment of this specification. This set of interactive pages may be the interactive pages of a first terminal device. As shown in FIG5, the first terminal device displays page 510 to the first subject. Page 510 may display the current available credit limit of the first subject (for example, the current available credit limit of the first subject in FIG5 is 0), and may also display an entry for requesting to use another person's credit limit (for example, the control "I want to use another person's credit limit"). When the first subject clicks the control "I want to use another person's credit limit", the first terminal device displays page 520. On page 520, the first subject may enter the name of the second subject (for example, Bbb), and may also enter the first credit limit requested (for example, 200,000), the usage period (for example, three months), and the description of the purpose of the funds (for example, purchasing goods), etc. Furthermore, when the first terminal device detects that the first subject clicks the "Submit" button on page 520, it generates a credit limit allocation request and sends the credit limit allocation request to the loan server via the network. Thus, the loan server receives the credit limit allocation request from the first terminal device.
[0066] S440: The loan server generates an authorization task based on the credit limit allocation request. The authorization task is used to inquire whether the second subject agrees to allocate a credit limit to the first subject.
[0067] In this specification, when the loan server receives a credit limit allocation request initiated by the first subject, the loan server needs to obtain authorization from the second subject. Only with the authorization of the second subject (i.e., the second subject agrees to the first subject's request) can the loan server proceed with the allocation.In the case of sharing the credit limit of the second subject, the loan server can allocate the credit limit of the second subject to the first subject. Therefore, in S420, the loan server can generate an authorization task based on the credit limit allocation request. This authorization task is used to ask whether the second subject agrees to allocate the credit limit to the first subject, or in other words, to ask whether the second subject agrees to the first subject sharing the available credit limit of the second subject.
[0068] Before S420, the second subject may correspond to one or more loan accounts, which is not limited in this specification. For ease of description, the loan account corresponding to the second subject will be referred to as the second loan account in the following description. The second subject may correspond to at least one second loan account. In some embodiments, the authorization task generated by the loan server is used to ask whether the second subject agrees to allocate the available credit limit of any second loan account to the first subject.
[0069] In some embodiments, loan accounts can be divided into shared type and non-shared type (i.e., private type). The shared type means that the credit limit of the loan account can be shared by the second subject and other subjects; the non-shared type means that the credit limit of the loan account can only be used by the second subject and cannot be used by other subjects. The at least one second loan account includes a target loan account of the shared type. The authorization task generated by the loan server is used to inquire whether the second entity agrees to allocate the available credit limit in the target loan account to the first entity.
[0070] In some embodiments, referring to FIG4, before S420, P400 may also include S410: the loan server executes the credit granting process to allocate a loan limit to the second entity. By executing S410, the loan server can generate a target loan account for the second entity and determine the loan limit of the target loan account. This will be described in detail below.
[0071] For example, the second entity can initiate a loan request through a second terminal device. After the second terminal device detects the loan request initiated by the second entity, it sends the loan request to the loan server. The loan server receives the loan request from the second terminal device. The loan request is used to apply for a loan limit that can be shared with other entities.
[0072] Wherein, the loan request includes at least the qualification information corresponding to the second entity, such as identity certificate, credit report, income and expenditure certificate, asset status and other materials. This qualification information can be used by the loan server to verify the legality of the second entity and assess its repayment ability, thereby determining whether the second entity meets the loan conditions.
[0073] After receiving the loan request, the loan server determines whether the second entity meets the loan conditions based on the qualification verification information. Specifically, the loan server conducts a detailed analysis and evaluation of the qualification verification information submitted by the second entity to obtain an evaluation result. The evaluation content includes, but is not limited to, key indicators such as credit score, income and expenditure level, debt situation, historical loan records, and asset certificates. Then, the loan server determines whether the second entity meets the loan conditions based on the evaluation result.
[0074] If the assessment results indicate that the second entity does not meet the loan conditions, the loan server may reject the loan request of the second entity or require the second entity to provide supplementary materials.
[0075] If the assessment results indicate that the second entity meets the loan conditions, the loan server may determine the loan amount corresponding to the second entity based on the aforementioned assessment results. Then, the loan server generates a target loan account for the second entity, uses the loan amount as the available amount of the target loan account, and sets the type of the target loan account to a shared type. Here, "setting the type of the target loan account to a shared type" means that the amount in the target loan account can be shared with other entities.
[0076] In some embodiments, the loan request initiated by the second entity may also include trade document information between the second entity and at least one other entity. This trade document information may include, but is not limited to, purchase and sale contracts, order agreements, invoices, logistics documents, and other materials that can prove the existence of a genuine transaction relationship between the parties. Through this trade document information, the loan server can know which entities have trade dealings with the second entity. In this case, after generating a target loan account for the second entity, the loan server can also bind the target loan account to the at least one other entity, so that the at least one other entity has the right to share the credit limit of the target loan account.
[0077] For example, assuming that the loan request initiated by the second entity includes trade document information between it and entity A, then the loan server binds the target loan account to entity A. In this case, entity A has the right to share the credit limit of the target loan account. Assuming that the loan request initiated by the second entity includes trade document information between it and entity A, entity B, and entity C, then the loan server binds the target loan account to entity A, entity B, and entity C. In this case, entity A, entity B, and entity C all have the right to share the credit limit of the target loan account.
[0078] In some embodiments, after receiving a credit limit allocation request, the loan server can first obtain at least one second loan account of the second entity. Specifically, after receiving a credit limit allocation request, the loan server can query at least one second loan account under the name of the second entity from the internal account system according to the identification information of the second entity carried in the credit limit allocation request. The identification information of the second entity includes entity ID, identification number, etc. Then, the loan server determines whether a shared-type target loan account exists among the at least one second loan account. If a shared-type target loan account exists, the loan server can generate an authorization task based on the relevant information of the target loan account (at this time, the authorization task is used to inquire whether the second entity agrees to allocate the available credit limit of the target loan account to the first entity). If no shared-type target loan account exists...If the target loan account is of the same type, the loan server can send a prompt message to the first terminal device to indicate that the first entity's credit limit allocation has failed, and the reason for the failure is that the second entity does not have a similar loan account.
[0079] In some embodiments, if there is a target loan account of the same type among the at least one second loan account, the loan server can further determine whether the first entity has the right to share the credit limit of the target loan account. If the first entity has the right to share the credit limit of the target loan account, the loan server generates an authorization task based on the credit limit allocation request.
[0080] For example, the credit limit allocation request initiated by the first entity may also include trade document information between the first entity and the second entity. Among them, trade document information includes, but is not limited to, purchase and sale contracts, transaction orders, invoice records, logistics information, etc. In this case, the loan server can obtain the trade document information from the credit limit allocation request and determine the closeness of the trade relationship between the first entity and the second entity based on the trade document information. For example, the loan server can comprehensively analyze the transaction frequency, transaction amount, cooperation duration and performance between the first entity and the second entity to determine the closeness of the trade relationship between the first entity and the second entity. Furthermore, the loan server can determine whether the first entity has the right to share the credit line of the target loan account based on the closeness of the trade relationship. For example, when the closeness of the trade relationship is high, the loan server determines that the first entity has the right to share the credit line of the target loan account; when the closeness of the trade relationship is low, the loan server determines that the first entity does not have the right to share the credit line of the target loan account.
[0081] For another example, the target loan account is pre-bound to at least one candidate entity (see the related description above; when the second entity initiates a loan request, it can carry trade document information between itself and at least one other entity in the loan request. In this case, after the loan server generates the target loan account for the second entity, it will bind the target loan account to these other entities). In this case, the loan server can check whether the first entity is included among the at least one candidate entity pre-bound to the target loan account, thereby determining whether the first entity has the right to share the credit line of the target loan account. For example, if the first entity is included among the at least one candidate entity, the loan server determines that the first entity has the right to share the credit line of the target loan account. If the first entity is not included among the at least one candidate entity, the loan server determines that the first entity does not have the authority to share the credit limit of the target loan account.
[0082] S460: The loan server sends an authorization task to the second terminal device corresponding to the second entity and receives the execution result of the authorization task from the second terminal device.
[0083] It should be noted that this specification does not limit the specific content of the authorization task. As an example, authorizationThe task can describe the amount of money requested by the first subject, the purpose of the funds, the usage period, etc., and ask the second subject whether they agree to use it. For example: Subject Aaa (i.e., the first subject) requests to use a credit line of 200,000, with a usage period of three months, and the purpose of the funds is to purchase goods. Please confirm whether you agree.
[0084] The loan server sends the above-mentioned authorization task to the second terminal device so that the second terminal device can display the authorization task to the second subject. The second terminal device can determine the execution result based on the second subject's "agree" or "disagree" operation on the authorization task, and send the execution result to the loan server. Thus, the loan server obtains the execution result of the authorization task.
[0085] In some embodiments, after generating the authorization task, the loan server can generate an access link corresponding to the authorization task. For example, the access link can be a Uniform Resource Locator (URL) of the operation page of the authorization task. Then, the loan server sends the access link to the first terminal device. Under the operation of the first subject, the first terminal device can forward the access link to the second terminal device. The way the first terminal device sends the access link to the second terminal device can include, but is not limited to, message notification, SMS, email, or in-app push.
[0086] Figure 6 shows a schematic diagram of another set of interactive pages provided according to an embodiment of this specification. This set of interactive pages can be interactive pages of a first terminal device. As shown in Figure 6, the first terminal device displays page 530 to a first subject. Page 530 displays the access link and may also display a sending entry to a second subject (e.g., a control "Send to Bbb"). When the first subject clicks the control "Send to Bbb", the first terminal device displays page 540. On page 540, the first subject can select the name of the second subject (e.g., Bbb) from the friend list. Then, the page jumps to 550. On page 550, the access link is sent to the dialog box between the first subject and the second subject. It should be noted that pages 530, 540, and 550 can be pages of the same application or pages of different applications. For example, in some embodiments, page 530 can be a page of a first application that provides loan capabilities, and this first application also provides social capabilities; in this case, pages 540 and 550 can also be pages of the first application. For example, in some embodiments, page 530 may be a page of a first application providing loan capabilities, and pages 540 and 550 may be pages of a second application providing social capabilities.
[0087] After receiving the access link, the second terminal device may display the access link, so that the second subject can click or open the access link on the second terminal device. The second terminal device detects the second subject's click or opening.After the operation, an access request for the access link is generated and sent to the loan server through a secure communication channel. In response to receiving the access request for the access link from the second terminal device, the loan server sends an authorization task to the second terminal device. Thus, the second terminal device can display an operation page for the authorization task to the second subject, allowing the second subject to perform an "agree" or "disagree" operation on the operation page.
[0088] Figure 7 shows a schematic diagram of another set of interactive pages provided according to an embodiment of this specification. This set of interactive pages can be the interactive pages of the second terminal device. As shown in Figure 7, the second terminal device displays page 560 to the second subject. Page 560 can display a dialog box between the second subject and the first subject. An access link is displayed in the dialog box. The second subject clicks the access link, and the second terminal device displays page 570. Authorization details are displayed on page 570. These authorization details include the applicant (e.g., Aaa), the applied amount (e.g., 200,000), the usage period (e.g., three months), and the purpose of the funds (e.g., purchasing goods). On page 570, the second subject clicks the "Agree" button to agree to allocate a credit limit to the first subject. When the second terminal device detects that the second subject has clicked the "Agree" button, it considers that the second subject has agreed to the credit limit allocation request of the first subject. Therefore, the second terminal device returns the execution result of "Agree" to the loan server. If the second subject clicks the "Disagree" button, the second terminal device considers that the second subject does not agree to the credit limit allocation request of the first subject and returns the execution result of "Reject" or "Requires Supplementary Information" to the loan server.
[0089] In some embodiments, after generating the access link corresponding to the authorization task, the loan server can also set the validity period of the access link. The validity period refers to a time period starting from the time the access link is generated. That is, the access link will automatically expire after the time period ends, and it can no longer be used to access the operation page of the authorization task. It should be noted that this specification does not limit the value of the validity period, which can be several minutes, several hours, or several days, etc.
[0090] In this case, in response to receiving an access request for the access link from the second terminal device, the loan server determines whether the current time is within the validity period of the access link. If the current time is within the validity period, the loan server sends an authorization task to the second terminal device. If the current time is outside the validity period, the loan server refuses to process the access request, that is, the loan server will not send an authorization task to the second terminal device. At this time, the loan server may send a first prompt message to the second terminal device. The first prompt message is used to indicate that the authorization task has expired.
[0091] The above embodiments can effectively reduce the risk of access links being hijacked or brute-forced by limiting the validity period of access links, and can avoid the first subject waiting indefinitely.
[0092] S480: If the execution result indicates agreement, the loan server determines that the second subject agrees to allocate the target amount to the first subject, allocates the target amount to the first subject's first loan account, and reduces the target amount from the second subject's available amount.
[0093] It is easy to understand that if the execution result indicates agreement, it means that the second subject agrees to share the amount with the first subject. In this case, the loan server can determine the target amount that the second subject agrees to allocate to the first subject. There are multiple ways to determine the target amount, and two possible examples are given below.
[0094] In some embodiments, the amount allocation request initiated by the first subject may include: the first amount that the first subject requests to be allocated. The first amount represents the amount that the first subject wants to share from the target loan account (amount pool). Accordingly, the authorization task generated by the loan server is used to ask the second subject whether it agrees to allocate the first amount to the first subject. In this case, if the execution result indicates agreement, it means that the second subject agrees to allocate the first credit line to the first subject. Therefore, the loan server can determine the first credit line as the target credit line.
[0095] In some embodiments, when the execution result indicates agreement, the execution result may include the second credit line that the second subject agrees to allocate to the first subject. The second credit line may be different from the first credit line applied for by the first subject. For example, the first subject applied for a first credit line of 300,000, and the second subject agreed to allocate a second credit line of 200,000 to the first subject. Of course, the second credit line may also be the same as the first credit line, and this specification does not limit this. In this case, the loan server can determine the second credit line as the target credit line.
[0096] After determining the target credit line, the loan server allocates the target credit line to the first loan account of the first subject (pages 12 / 16, CN 121146891 A). Accordingly, the loan server reduces the available credit line of the target loan account of the second subject by the target credit line. For example, Figure 8 shows a schematic diagram of credit line allocation provided according to an embodiment of this specification. As shown in Figure 8, assuming that before executing P400, the available credit limit of the target loan account of the second entity is 1 million, and the available credit limit of the first loan account of the first entity is 0. And assuming that the loan server determines the target credit limit to be 200,000 by executing method P400. In this case, after executing P400, the available credit limit of the first loan account of the first entity is 200,000, and the available credit limit of the target loan account of the second entity is 800,000.
[0097] In the above embodiment, the loan server can receive the credit limit allocation request initiated by the first entity and obtain...With the authorization of the second entity, at least a portion of the second entity's available credit limit is allocated to the first entity. Thus, the first entity can obtain the target credit limit without submitting qualification certificate information to the loan server. In other words, even if the first entity has a low credit rating, it can still obtain a loan from a financial institution, meeting the loan needs of low-credit entities.
[0098] After the loan server allocates the target credit limit to the first entity, the first entity can directly initiate a fund disbursement process through the first terminal device. The fund disbursement process is described below.
[0099] In some embodiments, the first entity initiates a disbursement request for a first loan account on the first terminal device. The loan server receives the disbursement request corresponding to the first loan account from the first terminal device. For example, the disbursement request includes the first amount requested by the first entity, the disbursement account, etc. The disbursement account can be, but is not limited to, the first entity's bank account, e-wallet, or other receiving account. The loan server can determine the first amount requested by the first entity from the disbursement request and determine the first entity's disbursement account. Furthermore, the loan server can transfer funds corresponding to the first amount to the first entity's withdrawal account and reduce the corresponding amount from the available limit of the first loan account.
[0100] In the above embodiment, after obtaining the target limit, the first entity can directly initiate fund withdrawal from the loan server within the target limit range, thus eliminating the need for the second entity to withdraw funds first and then transfer the withdrawn funds to the first entity. This shortens the fund transfer path and improves the efficiency of the first entity obtaining loan funds. In addition, since the loan server can directly perceive the first entity's fund withdrawal process, financial institutions can understand the first entity's actual fund usage behavior, thereby enabling effective control and management of funds.
[0101] After the first entity performs the fund withdrawal operation, the first entity can repay the fund withdrawal behavior. This repayment can be proactive or reactive. The repayment process is described below.
[0102] In some embodiments, the first entity can proactively repay. In this case, the first entity initiates a repayment request for the first loan account in the first terminal device. The repayment request includes, but is not limited to, the repayment amount, the repayment account, and the repayment time. The repayment amount can be equal to the first amount withdrawn, corresponding to a full repayment scenario; the repayment amount can also be less than the first amount withdrawn, corresponding to partial repayment / installment repayment scenarios. The repayment account can be a bank account or e-wallet linked to the first entity. The loan server receives the repayment request from the first terminal device, deducts at least a portion of the funds from the first entity's repayment account for repayment based on the repayment request, and adds a corresponding amount to the available credit limit of the first loan account based on the amount of repayment funds.
[0103] In some embodiments, if the first subject does not actively repay the loan, the loan server may execute a reminder process or an automatic deduction process. The repayment process includes at least one of the following: (1) When the loan server detects that the funds corresponding to the first amount are nearing the repayment deadline, it sends a second reminder message to the first terminal device. The second reminder message is used to remind the first subject to repay the loan.
[0104] (2) When the loan server detects that the funds corresponding to the first amount are nearing the repayment deadline, it sends a third reminder message to the second terminal device. The third reminder message is used to remind the second subject to repay the loan, or to remind the second subject to urge the first subject to repay the loan. Specification 13 / 16 pages 17 CN 121146891 A
[0105] (3) When the loan server detects that the funds corresponding to the first amount have reached the repayment deadline, it deducts at least a portion of the funds from the first subject's repayment account for repayment, and adds a corresponding amount to the available credit limit of the first loan account based on the amount of the repayment funds.
[0106] (4) When the loan server detects that the funds corresponding to the first amount have reached the repayment deadline and the funds in the repayment account of the first entity are insufficient for repayment, it deducts at least a portion of the funds from the repayment account of the second entity for repayment, and increases the corresponding amount in the available credit limit of the first loan account based on the amount of repayment funds.
[0107] In (1) or (3) above, the loan server can remind the first entity to make repayment or automatically deduct the funds of the first entity for repayment, which can reduce the risk of funds. In (2) or (4) above, the loan server can also remind the second entity to make repayment or automatically deduct the funds of the second entity for repayment. That is, if the first entity is unable to make repayment on time, the second entity with better credit can help the first entity to make repayment, thereby further reducing the risk of funds.
[0108] S480 above describes the case where the execution result indicates agreement. In some embodiments, if the execution result indicates disagreement, the loan server can send a fourth prompt message to the first terminal device. The fourth prompt message is used to prompt the first entity that the credit limit allocation has failed. In this case, the first entity cannot share the available credit limit of the second entity. In some embodiments, the second prompt information may also include the reason for failure, so that the first subject can understand the specific reason for the failure of the credit limit allocation, thereby facilitating subsequent processing.
[0109] In summary, the loan limit processing method provided in this specification allows the loan server to allocate at least a portion of the available credit limit of the second subject to the first subject when it receives a credit limit allocation request initiated by the first subject and obtains authorization from the second subject. Therefore, the first subject can obtain the target credit limit without submitting qualification certificate information to the loan server. In other words, even if the first subject has a low credit rating, it can still obtain a loan from a financial institution.To meet the loan needs of low-credit entities. Since the target amount is directly allocated to the first entity by the financial institution, the first entity can directly initiate fund disbursement from the loan server within the target amount range, thus eliminating the need for the second entity to disburse the funds first and then transfer the disbursed funds to the first entity. This shortens the fund transfer path and improves the efficiency of the first entity in obtaining loan funds. In addition, since the loan server can directly sense the fund disbursement process of the first entity, the financial institution can understand the actual fund usage behavior of the first entity, thereby enabling effective control and management of funds.
[0110] In another aspect, this specification provides a computer-readable non-transitory storage medium storing at least one instruction set for processing loan amounts. When the at least one instruction set is executed by a processor, the at least one instruction set instructs the processor to implement the steps of the loan amount processing method P400 described in this specification. In some possible embodiments, various aspects of this specification can also be implemented in the form of a program product, which includes program code. When the program product is run on a computing device 300, the program code is used to cause the computing device 300 to execute the steps of the loan amount processing method P400 described in this specification. The program product used to implement the above method may employ a portable compact disc read-only memory (CD-ROM) containing program code and may run on computing device 300. However, the program product of this specification is not limited thereto. In this specification, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system. The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: portable discs, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. The computer-readable storage medium may include a data signal propagated as part of a carrier wave in baseband, wherein readable program code is carried. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium can also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in connection with an instruction execution system, apparatus, or device. On the readable storage mediumThe included program code can be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. The program code for performing the operations of this specification can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, etc., and conventional procedural programming languages such as the "C" language or similar programming languages. The program code can be executed entirely on computing device 300, partially on computing device 300, as a standalone software package, partially on computing device 300 and partially on a remote computing device, or entirely on a remote computing device.
[0111] Specific embodiments of this specification have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0112] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure may be presented by way of example only and may not be restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments of this specification.
[0113] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" means that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment" or "an embodiment" or "an alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Furthermore, particular features, structures, or characteristics may be appropriately combined in one or more embodiments of this specification.
[0114] It should be understood that in the foregoing description of the embodiments of this specification, in order to aid in understanding a feature, and for the purpose of simplifying this specification, various features are combined in a single embodiment, drawing, or description thereof. However, this does not mean that the combination of these features is necessary, and those skilled in the art, upon reading this specification, may readily identify some of the devices as standalone embodiments. In other words, the embodiments in this specification can also be understood...The solution is an integration of multiple sub-implementations. The content of each sub-implementation is valid even if it contains fewer features than a single previously disclosed embodiment.
[0115] Every patent, patent application, publication of a patent application, and other material, such as articles, books, specifications, publications, documents, articles, etc., referenced herein, except for those inconsistent with or conflicting with this document, or those having a limiting effect on the widest scope of the claims, may be incorporated herein by reference for all purposes now or hereafter associated with this document. Furthermore, in the event of any inconsistency or conflict between the description, definition, and / or use of relevant terms in any material and the description, definition, and / or use of relevant terms in this document, the terms in this document shall prevail.
[0116] Finally, it should be understood that the embodiments of the applications disclosed herein are illustrative of the principles of the embodiments of this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments described herein are not limited to the embodiments precisely described in the application. Specification 16 / 16 pages 20 CN 121146891 A Figure 1 Specification Drawing 1 / 5 pages 21 CN 121146891 A Figure 2 Specification Drawing 2 / 5 pages 22 CN 121146891 A Figure 3 Specification Drawing 3 / 5 pages 23 CN 121146891 A Figure 4 Figure 5 Specification Drawing 4 / 5 pages 24 CN 121146891 A Figure 6 Figure 7 Figure 8 Specification Drawing 5 / 5 pages 25 CN 121146891 A Abstract Abdominal ultrasound examination method, system and device medium The invention provides a loan amount processing method, a loan server and a storage medium. And the loan server receives a quota allocation request from a first terminal device corresponding to the first subject, wherein the quota allocation request isused for requesting to allocate at least part of the available quota of the second subject to the first subject. The loan server generates an authorization task based on the quota allocation request, sends the authorization task to a second terminal device corresponding to a second subject, and receives an execution result of the authorization task from the second terminal device, and the authorization task is used for inquiring whether the second subject agrees to allocate the quota to the first subject. And furthermore, under the condition that the execution result represents agreement, the loan server determines a target quota which the second subject agrees to allocate to the first subject, allocates the target quota to a first loan account of the first subject, and reduces the target quota in available quota of the second subject.
Claims
1. A method for processing loan amounts, applied to a loan server, the method comprising: A quota allocation request is received from the first terminal device corresponding to the first subject, the quota allocation request being used to request that at least a portion of the available quota of the second subject be allocated to the first subject; An authorization task is generated based on the quota allocation request, wherein the authorization task is used to ask the second entity whether it agrees to allocate a quota to the first entity; Send the authorization task to the second terminal device corresponding to the second entity, and receive the execution result of the authorization task from the second terminal device; and If the execution result indicates agreement, the second entity agrees to allocate a target amount to the first entity, the target amount is allocated to the first entity's first loan account, and the target amount is reduced from the second entity's available credit limit.
2. The method according to claim 1, wherein, The second entity corresponds to at least one second loan account, and the at least one second loan account includes a target loan account of the shared type; The authorization task is used to inquire whether the second entity agrees to allocate the available credit limit in the target loan account to the first entity.
3. The method according to claim 2, wherein, The method further includes: The loan request is received from the second terminal device, the loan request including at least the qualification certificate information corresponding to the second entity, and the loan request is used to apply for a loan limit that can be shared with other entities; and If the second entity meets the loan conditions based on the qualification certificate information, the loan amount corresponding to the second entity is determined, the target loan account is generated for the second entity, the loan amount is used as the available amount of the target loan account, and the type of the target loan account is set to shared type.
4. The method according to claim 3, wherein, The loan request also includes: trade document information between the second entity and at least one other entity; After generating the target loan account for the second entity, the method further includes binding the target loan account to the at least one other entity, so that the at least one other entity has the right to share the credit limit of the target loan account.
5. The method according to claim 2, wherein, Generate an authorization task based on the quota allocation request, including: Determine whether the first entity has the authority to share the credit line of the target loan account; and If the first entity has the authority to share the credit limit of the target loan account, the authorization task is generated based on the credit limit allocation request.
6. The method according to claim 5, wherein, The credit limit allocation request includes at least: trade document information between the first entity and the second entity, and determining whether the first entity has credit limit sharing authority over the target loan account, including: The trade document information is obtained from the quota allocation request, and the closeness of the trade relationship between the first entity and the second entity is determined based on the trade document information; and Based on the closeness of the trade relationship, it is determined whether the first entity has the authority to share the credit line of the target loan account.
7. The method according to claim 5, wherein, The target loan account is pre-linked with at least one candidate entity. Determining whether the first entity has credit line sharing permissions for the target loan account includes: If the first entity is included among the at least one candidate entity, then the first entity is determined to have credit line sharing authority over the target loan account; or If the first entity is not among the at least one candidate entity, then it is determined that the first entity does not have the authority to share the credit line of the target loan account.
8. The method according to claim 1, wherein, After generating the authorization task, the method further includes: generating an access link corresponding to the authorization task and sending the access link to the first terminal device so that the first terminal device forwards the access link to the second terminal device; Sending the authorization task to the second terminal device corresponding to the second subject includes: in response to receiving an access request for the access link from the second terminal device, sending the authorization task to the second terminal device.
9. The method according to claim 8, wherein, After generating the access link corresponding to the authorized task, the method further includes: setting the validity period range of the access link; Sending the authorization task to the second terminal device includes: sending the authorization task to the second terminal device if the current time is within the validity period.
10. The method according to claim 9, wherein, The method further includes: when the current time is outside the validity period, sending a first prompt message to the second terminal device, the first prompt message being used to indicate that the authorized task has expired.
11. The method according to claim 1, wherein, The quota allocation request includes a first quota requested by the first entity, and the authorization task is used to ask the second entity whether it agrees to allocate the first quota to the first entity; Determining the target amount that the second entity agrees to allocate to the first entity includes: determining the first amount as the target amount.
12. The method according to claim 1, wherein, In cases where the execution result represents agreement, the execution result includes the second entity's agreement to allocate a second quota to the first entity; Determining the target amount that the second entity agrees to allocate to the first entity includes: determining the second amount as the target amount.
13. The method according to claim 1, wherein, After allocating the target amount to the first loan account of the first entity, the method further includes: Receive the withdrawal request corresponding to the first loan account from the first terminal device; Based on the withdrawal request, determine the first amount requested by the first entity and determine the withdrawal account of the first entity; and Funds corresponding to the first amount are transferred to the first entity's withdrawal account, and the corresponding amount is reduced from the available credit limit of the first loan account.
14. The method according to claim 13, wherein, After transferring the funds corresponding to the first amount to the first entity's withdrawal account, the method further includes: Receive repayment request from the first terminal device; and Based on the repayment request, at least a portion of the funds are deducted from the repayment account of the first entity for repayment, and a corresponding amount is added to the available credit limit of the first loan account based on the amount of repayment funds.
15. The method according to claim 13, wherein, After transferring the funds corresponding to the first amount to the first entity's withdrawal account, the method further includes at least one of the following: If it is detected that the funds corresponding to the first amount are nearing the repayment deadline, a second reminder message is sent to the first terminal device. The second reminder message is used to remind the first entity to make the repayment. If it is detected that the funds corresponding to the first amount are nearing the repayment deadline, a third reminder message is sent to the second terminal device. The third reminder message is used to remind the second entity to make the repayment, or to remind the second entity to urge the first entity to make the repayment. If the funds corresponding to the first amount are detected to have reached the repayment deadline, at least a portion of the funds will be deducted from the repayment account of the first entity for repayment, and the corresponding amount will be added to the available credit limit of the first loan account based on the amount of repayment funds. or If it is detected that the funds corresponding to the first amount have reached the repayment deadline and the funds in the repayment account of the first entity are insufficient to make the repayment, at least a portion of the funds shall be deducted from the repayment account of the second entity for repayment, and the corresponding amount shall be added to the available credit limit of the first loan account based on the amount of repayment funds.
16. The method according to claim 1, wherein, After receiving the execution result, the method further includes: If the execution result indicates disagreement, a fourth prompt message is sent to the first terminal device, which is used to notify the first entity that the quota allocation has failed.
17. A loan server, comprising: At least one storage medium storing at least one instruction set; as well as At least one processor is communicatively connected to the at least one storage medium, wherein the at least one processor reads the at least one instruction set during operation and executes the method as described in any one of claims 1-16 according to the instructions of the at least one instruction set.
18. A computer-readable non-transitory storage medium, wherein, The computer-readable non-transitory storage medium stores at least one set of instructions, which, when executed by at least one processor, implement the method as described in any one of claims 1-16.