Liquidity risk stress testing system and method supporting dynamic configuration of horizon structure

Abstract

The application relates to the field of financial technology data processing, and particularly discloses a liquidity risk stress testing system and method supporting dynamic configuration of a term structure. The system comprises a configuration layer, a scheme layer, an execution layer and an output layer. The configuration layer provides metadata definition of a term structure, stress parameters and buffer parameters, and a term bucket is independently stored in records and builds a red-black tree index. The scheme layer binds multiple configurations into an executable scheme. The execution layer loads the configuration according to the scheme identifier and executes stress testing calculation to generate cash flow gap values and the shortest survival period of each term bucket. The output layer stores the results in a row storage structure separated from a main table and a subtable, and dynamically generates column metadata to drive front-end display and data exchange. The application realizes runtime dynamic configuration and zero-code adaptation of the term structure, guarantees the calculation efficiency of large-scale data matching through the red-black tree index, and realizes automatic adaptation of display, import and export.

Description

Technical Field

[0001] This invention relates to financial technology data processing technology, specifically to a liquidity risk stress testing system and method that supports dynamic configuration of term structure. Background Technology

[0002] Liquidity risk stress testing is a core component of commercial banks' asset and liability management. Regulators require commercial banks to regularly conduct stress tests to assess cash flow gaps and minimum survival periods under different stress scenarios and within various timeframes. With the dynamic adjustment of regulatory requirements and the differentiated needs of different legal entities within a multi-legal entity service structure, the allocation of maturity structures faces the practical pressure of frequent changes.

[0003] Chinese patent application CN114565225A discloses a liquidity risk stress test template and method. It acquires target financial data through a data acquisition module, analyzes beginning and ending cash flow changes, obtains risk factor changes through a risk stress test module, calculates net cash flow under stress scenarios, and then uses a liquidity risk assessment module to perform stress scenario analysis on cash inflows and outflows for each period and assesses liquidity risk. This method uses a cash flow approach, dividing inflows and outflows according to maturity dates to calculate the net cash outflow gap. The maturity gap calculation relies on a pre-defined maturity classification.

[0004] However, the aforementioned existing technologies still have the following drawbacks in the computer implementation of term structures: Firstly, the time frame structure is fixed in the column structure of the database table, with each time bucket corresponding to a data column. Adjusting the time bucket requires executing DDL changes and simultaneously modifying the ORM entity class, the calculation engine branch logic, the front-end rendering code, and the import / export templates. This results in a long change chain, high maintenance costs, and makes it impossible to achieve dynamic adjustment at runtime.

[0005] Secondly, the differentiated term structure requirements of different legal entities result in a large number of hard-coded legal entity identifier constants and conditional branches in the code. When a new legal entity is added, multiple code locations need to be modified one by one, and the maintainability of the system deteriorates sharply as the number of legal entities increases.

[0006] Third, the term bucket matching adopts a field-by-field reading method, which is inefficient. Furthermore, the sell-off rate in the mitigation scenario is strongly coupled with the term bucket structure. When the term bucket changes, the mitigation algorithm needs to be modified simultaneously, which further increases the complexity of the system. Summary of the Invention

[0007] To address the problems in existing technologies, such as the strong coupling between the definition of term structure and data table structure and program code, which leads to the need to modify multiple layers of code for term structure changes, the reliance on hard-coded branches for corporate differentiation, low efficiency of term bucket matching, and fixed result storage structure, this invention provides an automated system and method for liquidity risk stress testing that supports dynamic configuration of term structure.

[0008] To achieve the above objectives, this invention provides an automated liquidity risk stress testing system that supports dynamic configuration of maturity structure. The system includes a configuration layer, a scheme layer, an execution layer, and an output layer. (a) Configuration layer The configuration layer includes a structure configuration module, a pressure configuration module, and a slow-release configuration module, with each module storing configuration data independently.

[0009] The structure configuration module provides term structure definitions and term bucket definitions, and receives dynamic configuration operations from users for term structure schemes through a graphical interface. Term bucket definitions use row-based storage, with each term bucket stored independently as a record. The number of term buckets is not limited by the number of columns in the data table, and adding or deleting term buckets only involves adding or deleting configuration records without changing the data table structure. The structure configuration module includes an index building unit, which loads the corresponding term structure definition and term bucket details based on the term structure identifier bound to the current scheme before calculation starts, builds a red-black tree-based term interval index in memory, and performs term bucket matching using the red-black tree index in response to term matching requests from cash flow data. The structure configuration module also includes a term parsing unit, which performs regular expression matching and standardized day conversion on non-standardized term information, and calculates the remaining days for date fields.

[0010] The pressure configuration module is used to locate the pressure parameters of each subject under each pressure scenario using a three-level key-value index of pressure scenario code, subject set code, and subject code, and to store the pressure parameters in an independent configuration table.

[0011] The mitigation configuration module is used to configure the discount rate and sell-off rate of mitigation assets according to legal entities, stress scenarios, and stress levels. The discount rate and sell-off rate are stored hierarchically in independent configuration tables. The mitigation configuration module includes a proportional allocation unit, which is used to linearly allocate the calculated sell-off amount to each term bucket according to the proportion of the actual number of days in each term bucket to the total number of days in the observation window.

[0012] (II) Scheme Level The solution layer includes a solution binding module, which provides a solution table. This table binds a set of stress scenario configurations, a set of mitigation scenario configurations, and a set of term structure configurations into an executable solution. The solution table includes a term structure identifier field, used to explicitly bind the term structure configuration record used by the solution. When the same legal entity maintains multiple term structure configurations, the solution creator selects one through the configuration interface, and the execution layer accurately loads the corresponding term structure definition based on this identifier during solution execution.

[0013] (III) Execution Layer The execution layer includes a computation engine, a summary module, and a lifetime computation module.

[0014] The calculation engine is used to perform calculations based on the configuration bound to the scheme table. The calculation engine includes a loading unit, a first calculation unit, a second calculation unit, and a summarizing unit.

[0015] The loading unit is used to read the term structure identifier of the scheme table when the computation starts. After verifying that the legal entity identifier of the term structure configuration is consistent with the legal entity of the scheme, it calls the structure configuration module to load the corresponding term structure definition and build a red-black tree index. At the same time, it loads the stress scenario parameters and the mitigation scenario parameters, and passes the completed term structure context to each downstream computation unit.

[0016] The first calculation unit iterates through each account, reads the churn rate parameters for the corresponding pressure level from the pressure configuration module, calculates the churn amount, and calls the allocation processing unit to determine the term bucket allocation. For liability accounts with a definite maturity date (such as time deposits), the standardized number of days is calculated based on its remaining term. This number of days is used as the lookup key to match the unique corresponding term bucket through a red-black tree index. All churn amounts for this account are allocated to this bucket without cross-bucket allocation. For accounts without a definite maturity date (such as demand deposits), the churn amount is allocated to each term bucket according to its historical average duration or a preset term structure model. This unit performs the above calculations for the baseline scenario and the three pressure scenarios, totaling four pressure levels, generating four sets of first calculation results.

[0017] The second calculation unit calls the allocation processing unit to determine the maturity bucket allocation based on the remaining maturity characteristics of the assets (such as high-quality liquid assets). For salable assets with a clear remaining maturity, they are directly matched to the corresponding unique maturity bucket; for asset pools with unclear remaining maturities, allocation is carried out according to their weighted average remaining maturity or a preset liquidity release curve.

[0018] The summary unit is used to add the allocation results of the first calculation unit and the second calculation unit, and recursively aggregate them from bottom to top according to the subject hierarchy tree, wherein the term buckets of parent and child nodes are accumulated one by one according to the bucket number.

[0019] The aggregation module is used to uniformly refine the cash flow gap value within each term bucket into daily values, incrementally accumulate the daily net cash flow in chronological order, and generate a daily cash flow sequence for each term bucket.

[0020] The lifespan calculation module is used to accumulate the daily cash flow sequence generated by the aggregation module, starting from the initial balance. When the closing balance of a day is not greater than zero for the first time, the number of days elapsed is recorded as the shortest lifespan.

[0021] (iv) Output layer The output layer includes a storage module and a metadata generation module.

[0022] The storage module provides a row-based storage structure that separates the main table from the term bucket sub-tables. The main table stores the subject dimension and a total field that does not change with the term bucket. The term bucket sub-tables store the calculated values ​​of each term bucket under each pressure level in row format, including the main table foreign key, pressure level, bucket number, and bucket value fields. The storage module includes a write unit and a delete unit. The write unit is used to first batch write records to the main table within the same transaction when the results are written to the database, and then batch write records to the sub-tables based on the backfilled primary key. The delete unit is used to cascade delete old data in the order of priority between the sub-tables and the main table.

[0023] The metadata generation module dynamically generates column metadata in response to changes in the term structure configuration, based on the term structure definition bound to the scheme. This column metadata includes at least the bucket number, display label, and coverage days. The front-end presentation layer dynamically generates table columns using a loop driven by the column metadata. The data import template dynamically generates header rows based on the column metadata using a runtime document generation library. During import parsing, it establishes a mapping between column names and column indices by matching the header column names. The data export report dynamically writes cells according to the column metadata.

[0024] This invention also provides an automated method for liquidity risk stress testing that supports dynamic configuration of maturity structure, the method comprising the following steps: Step S1: Read the term structure identifier bound to the scheme table, load the corresponding term structure definition and term bucket details according to the term structure identifier, construct a term interval index based on a red-black tree in memory, and load the stress scenario configuration and mitigation scenario configuration bound to the scheme. Step S2: Parse the term information of the original data and convert it into standardized days. Use the standardized days as the lookup key to match the corresponding term bucket through the red-black tree index. Step S3: For each subject, read the loss rate under the corresponding pressure level according to the pressure scenario configuration, calculate the loss amount, and allocate the loss amount to each period bucket according to the ratio of the actual number of days in each period bucket to the total number of days in the observation window. Step S4: Based on the slow-release scenario configuration, read the discount rate and sell-off rate under the corresponding pressure level, calculate the sell-off amount, and allocate the sell-off amount to each term barrel according to the proportion of the actual number of days of each term barrel to the total number of days of the observation window; Step S5: Add the allocation results from step S3 and step S4 to the cash flow, and recursively aggregate from bottom to top according to the account hierarchy tree. Step S6: Evenly refine the cash flow gap value in each period bucket into daily values, and incrementally accumulate the daily net cash flow in chronological order. When the end balance of the day is not greater than zero for the first time, record the number of days elapsed as the shortest survival period. Step S7: Store the calculation results in a row storage structure that separates the main table and the time-limited bucket sub-table. Write the main table records in batches within the same transaction, and then write the sub-table records in batches according to the backfilled primary key. Step S8: Dynamically generate column metadata based on the term structure definition, and drive the front-end display, data import and data export to dynamically render based on the column metadata.

[0025] Compared with the prior art, this application has the following advantages: 1. The term structure definition uses row storage and supports dynamic configuration at runtime. In existing technologies, term structures are implemented using fixed columns in database tables. In this invention, term buckets are defined using row-based storage, with each term bucket stored independently as a single record in the database. The number of term buckets is not limited by the number of columns in the data table, and adding or deleting term buckets only involves adding or deleting configuration records, without requiring changes to the data table structure. Users can dynamically configure the term structure through a graphical interface. After a term structure change, no code modification or service restart is required; the changes take effect immediately with the next system run. Thus, the term structure definition changes from "compile time" to "runtime," achieving zero-code adaptation and real-time effectiveness for term structure changes, significantly reducing system maintenance costs and change risks.

[0026] 2. Explicit binding at the solution level enables zero-code branching for legal entity differences. In existing technologies, the need for differentiated term structures for different legal entities is achieved through hard-coded legal entity identifier constants and conditional branches in the code. This invention explicitly binds a set of stress scenario configurations, a set of mitigation scenario configurations, and a set of term structure configurations into an executable scheme through a scheme table, which includes a term structure identifier field. When the same legal entity maintains multiple term structures, the scheme creator selects one through the configuration interface, and the calculation engine accurately loads the corresponding term structure definition based on this identifier during scheme execution. The differences in term structures for different legal entities are entirely reflected in the differences in configuration records. The calculation engine does not contain hard-coded identifier constants or conditional branches specific to any legal entity. Adding new legal entity differentiation requirements only requires adding configuration records, without modifying the code. Therefore, legal entity differentiation achieves zero-code branching, significantly improving system scalability.

[0027] 3. Red-black tree-based memory indexing ensures computational performance under dynamic configuration. Existing technologies achieve term bucket matching by reading each field sequentially, with computational efficiency linearly dependent on the number of term buckets, failing to support efficient bucketing of large volumes of cash flow data. This invention loads the term structure definition and term bucket details bound to the current scheme into memory before computation begins, constructs a term interval index based on a red-black tree, and performs a binary tree search using the maturity date as the lookup key. Even with hundreds of term buckets, it maintains sub-millisecond search performance, ensuring computational efficiency for large-scale data processing while achieving dynamic configuration of the term structure.

[0028] 4. Row-based storage result structure implements zero-DDL for time-limited bucket changes. In existing technologies, the result storage table changes with the term structure. Each new term bucket requires adding several columns to the result table, resulting in high DDL operation risks and complex historical data migration. This invention employs a row-based storage structure separating the main table and term bucket sub-tables. The main table stores the subject dimension and a total field that remains unchanged with the term buckets. The sub-tables store the calculated values ​​of each term bucket under each pressure level in row format. When the number of term buckets changes, the calculation results can be completely saved and restored without modifying the main table structure, completely solving the technical problem of requiring DDL operations for term bucket changes under fixed-column storage. Furthermore, results are written to the main table in batches within the same transaction, followed by batches to the sub-tables. Deletion is performed in a cascading order, prioritizing sub-tables over the main table, ensuring data consistency.

[0029] 5. Dynamically driven display and import / export functionality based on column metadata, enabling zero-code adaptation. In existing technologies, both Excel import templates and exported reports are static files. When the term structure changes, the template file must be recreated, and it's difficult to synchronize the template with the system version. This invention dynamically generates column metadata based on the term structure definition. The front-end presentation layer dynamically generates table columns using loop instructions driven by the column metadata. The data import template dynamically generates header rows based on the column metadata using a runtime document generation library and parses them according to column names. The data export report dynamically writes cells according to the column metadata. When the term structure changes, the import template and exported report automatically adapt, eliminating the need to recreate static template files and the risk of template incompatibility with the system version.

[0030] 6. The dual-mode allocation mechanism decouples the delayed-release scenario from the term structure. In existing technologies, the sell-off rate in mitigation scenarios is strongly coupled with the current term bucket structure, requiring simultaneous modification of the mitigation algorithm when term buckets change. This invention provides two allocation modes: "precise matching" and "model amortization." For businesses with a defined remaining term, a unique term bucket is precisely matched using a red-black tree index, eliminating the need for proportional calculations. For businesses without a term, amortization is performed according to a preset model. In both modes, the allocation logic does not rely on hard-coded bucket numbers or names, but is entirely driven by the term structure configuration. When the term structure changes, precise matching automatically adapts to the new bucket boundaries, and model amortization automatically recalculates the weights of each bucket without requiring modification to the algorithm code, achieving complete decoupling between the mitigation scenario simulation module and the term structure.

[0031] The above modules are not simply an aggregation of isolated technical means, but rather constitute the complete technical solution of this invention through organic synergy, producing an overall technical effect that surpasses the sum of the individual effects of each module.

[0032] The row-level storage term structure definition in the configuration layer works in conjunction with the explicit binding mechanism in the scheme layer: row storage enables dynamic expansion of the term structure, while scheme binding allows multiple term structures under the same legal entity to be selected independently without interference. Together, they achieve flexibility and accuracy in term structure configuration. The red-black tree index in the execution layer works in conjunction with the row storage in the configuration layer: row storage solves the flexibility of term structure definition, while the red-black tree index ensures computational performance for large-scale data matching under dynamic configuration. Together, they improve system flexibility without sacrificing computational efficiency. The row-level storage result structure in the output layer works in conjunction with the row-level storage term structure in the configuration layer: both term structure definition and result storage use row storage, ensuring that the entire chain from term bucket definition to calculation to storage is not limited by table structure. No DDL operation needs to be performed at any stage due to changes in the number of term buckets, forming a complete zero-DDL technology closed loop from configuration to calculation to storage. The dynamic metadata generation module directly maps the term structure definition in the configuration layer to the display and interactive interface in the output layer, enabling a complete automated closed loop from user configuration to front-end display, import, and export of term structures. Attached Figure Description

[0033] Figure 1 This is a schematic diagram of the overall system architecture described in Example 1; Figure 2 A schematic diagram illustrating the dynamic configuration and index construction process of the term structure; Figure 3 A flowchart for stress test calculation and summary; Figure 4 This is the overall flowchart of the method described in Example 2. Detailed Implementation

[0034] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. This specific embodiment is illustrated using the liquidity risk stress testing module of a commercial bank's asset and liability management ALM system as an example. The technology stack of this system is Java 8 plus Spring Boot 2.7 plus MyBatis-Plus 3.5 plus Vue 2.7 plus ElementUI plus GuassDB database. However, the technical solutions described in this invention are not limited to this specific technology stack, and those skilled in the art can make adaptive adjustments according to the actual system environment.

[0035] To facilitate understanding of the specific embodiments of the present invention, some terms involved in these specific embodiments will be explained below.

[0036] The term structure refers to a scheme that divides a future period into several consecutive and non-overlapping time intervals, each of which is called a term bucket.

[0037] Row storage refers to storing the value of each bucket as an independent data record rather than as an independent column of the data table.

[0038] A red-black tree is a self-balancing binary search tree that maintains its balance through rotation and coloring operations during data insertion and deletion.

[0039] A legal entity refers to an organization that has independent civil subject status under the law. In the asset and liability management system, it refers to a legal entity banking institution that independently conducts liquidity risk stress tests.

[0040] Stress scenarios are hypothetical market environments designed to assess a financial institution’s risk tolerance under extreme market conditions.

[0041] The mitigation scenario is a hypothetical scenario in stress testing in which financial institutions alleviate liquidity pressure by selling high-quality liquid assets.

[0042] A subject set is a grouping unit that categorizes accounting subjects with the same business attributes.

[0043] The observation window is the future time span examined in liquidity risk stress tests.

[0044] Column metadata is data used to describe the attributes of each column in a data table.

[0045] Account hierarchy tree is a multi-level tree structure composed of parent-child relationships between accounting accounts.

[0046] The shortest survival period is the longest number of days a financial institution can continue operating under stress scenarios, relying solely on its existing reserves of high-quality liquid assets without external financing support.

[0047] Example 1 This embodiment provides an automated liquidity risk stress testing system that supports dynamic configuration of the maturity structure. Designed for liquidity risk stress testing scenarios within commercial bank asset-liability management systems, this system aims to address the problem of strong coupling between maturity structure definition, data table structure, and program code in existing technologies. Figure 1 The overall architecture diagram shown depicts a system divided into four logical layers from bottom to top: configuration layer, scheme layer, execution layer, and output layer. These layers interact through standardized data interfaces and context objects. Lower layers provide configurable metadata and computational dependencies to upper layers, while upper layers drive the loading and execution of specific configuration logic by using scheme identifiers, forming a complete technical loop encompassing configuration definition, scheme binding, engine execution, and result rendering.

[0048] I. Configuration Layer The configuration layer is the system's data definition center, responsible for the metadata management of all variable business elements. This layer includes a structure configuration module, a stress configuration module, and a mitigation configuration module. These modules are stored independently in the physical database but logically linked through the scheme identifier in the scheme layer. The configuration layer does not contain any business execution logic; its sole responsibility is to receive configuration operations from users through the graphical interface and persistently store the configuration results in structured data. Changes to the configuration layer do not require restarting the application service; the execution layer dynamically loads the latest configuration each time a scheme starts.

[0049] (a) Structural Configuration Module The structure configuration module provides the definition of the term structure and term buckets, and receives dynamic configuration operations from users on the term structure scheme through a graphical user interface. This module contains two core data structures: a main term structure table and a term bucket detail sub-table.

[0050] Each record in the term structure master table defines a complete term structure scheme. The term structure master table contains the following fields: unique structure identifier, structure name, structure type, date flag, whether it's front-closed and back-open, associated legal entity identifier, and analysis identifier. The analysis identifier is a metadata tag field used to classify and filter term structure schemes and label them with business scenarios (e.g., distinguishing between "regulatory reporting" and "internal management") in the graphical configuration interface. It is not used as a logical input parameter for the calculation engine and does not affect the stress test calculation process and results. Taking a commercial bank's nine-barrel regulatory reporting scheme as an example, the unique structure identifier is assigned the value TS_2026_001, the structure name is "Nine-Barrel Regulatory Reporting Scheme," the structure type is marked as a time period structure to distinguish it from the result vector type, the date flag is set to a relative date to indicate that the boundaries of each term barrel are calculated relative to the data date, the "front-closed and back-open" field is set to ensure that adjacent term barrels do not overlap at boundary points, the associated legal entity identifier is the bank's legal entity code BANK001, and the analysis identifier is used to mark the specific analysis scenario applicable to this scheme.

[0051] Each record in the Term Bucket Details sub-table defines a specific time bucket. This sub-table uses row-based storage, meaning each term bucket is stored as an independent database record, rather than using a fixed column method in a database table. The Term Bucket Details sub-table contains the following fields: Bucket ID, Term Structure ID, Bucket Number, Term Lower Limit, Term Lower Limit Unit, Term Upper Limit, Term Upper Limit Unit, Frequency Value, and Frequency Unit. The Frequency Value and Frequency Unit are reserved extension fields to support term modeling for future rolling renewal businesses (such as rolling issuance of certificates of deposit). In the current version's stress test calculations, they are not involved in red-black tree index construction and term matching logic, and do not affect the core calculation process. Taking the aforementioned nine-bucket scheme as an example, the first record has the bucket ID BUCKET_001, the Term Structure ID TS_2026_001, the bucket number 1, the term lower limit value of 0 with a term lower limit unit of days, and the term upper limit value of 1 with a term upper limit unit of days. The second record has a bucket number of 2, a lower limit of 1, and an upper limit of 7, representing a bucket for days 2-7. Subsequent records define buckets for days 8-30, 31-60, 61-90, 91-180, 181-270, 271-365, 366-545, and 546-730, respectively. Because row-based storage is used, the number of buckets is not limited by the number of columns in the database table. Adding or deleting buckets only involves inserting or deleting configuration records in the corresponding sub-table, without requiring data table structure modification commands. This avoids the table locking risks, data migration complexity, and version rollback difficulties associated with performing data definition language operations in a production environment.

[0052] The structure configuration module contains index building units. For example... Figure 2 As shown, the index building unit is used to accurately load the term structure definition and term bucket details corresponding to the current scheme from the database before computation starts, based on the term structure identifier bound to the current scheme, and build a term range index based on a red-black tree in the application server's memory. The specific construction process is as follows: The index building unit first retrieves all term bucket details under the term structure from the database; these records are sorted by start date. Then, it traverses the details list, using the start date of each term bucket as the key value of the red-black tree node and the complete information of the term bucket as the node value, performing a standard red-black tree node insertion operation. During insertion, when two nodes have the same key value, the end date is used as a secondary comparison criterion; the node with the later end date is placed in the right subtree, and the node with the earlier end date is placed in the left subtree, ensuring that each key value has a unique position in the tree. After the insertion operation is completed, the system automatically executes the red-black tree balance correction algorithm, including left rotation, right rotation, and node coloring correction, ensuring that the tree height is maintained within twice the logarithm of base 2 (number of nodes + 1). Once the index is built, it can be reused throughout the entire program, eliminating the need for repeated construction. The index building unit also responds to subsequent cash flow data term matching requests by performing a floor search operation on the red-black tree using a standardized number of days as the lookup key. Specifically, it traverses from the root node. If the lookup key equals the current node's start date, the node is recorded and the search terminates. If the lookup key is less than the current node's start date, the search continues in the left subtree. If the lookup key is greater than the current node's start date, the current node is recorded and the search continues in the right subtree, until a leaf node is reached. After traversal, the last recorded node (i.e., the largest node whose start date is less than or equal to the lookup key) is taken, and its end date is verified to be greater than or equal to the lookup key. If the verification passes, the bucket number corresponding to the node is returned. If the verification fails, it indicates that the term does not belong to any defined term bucket, and the system marks the record as a term matching anomaly, processing it according to the preset strategy of placing it in the largest term bucket or the overdue bucket.

[0053] The structure configuration module also includes a term parsing unit. This unit parses term information in the original imported data that exists in non-standardized text form. This unit has a built-in extensible regular expression rule library, organized according to keyword priority. For fields with a value of "three months" or "3 months", the term parsing unit's regular expression engine first matches the keyword "month", extracts the associated value 3, and then calls a predefined conversion function to multiply the number of months by 30 to convert it to a standardized number of days of 90. For fields with a value of "one year", matching the keyword "year" multiplies the value 1 by 365 to obtain a standardized number of days of 365. For fields with a value of "two weeks", matching the keyword "week" multiplies the value 2 by 7 to obtain a standardized number of days of 14. For fields with a value of "one quarter", matching the keyword "quarter" multiplies the value 1 by 90 to obtain a standardized number of days of 90. For fields with a value of "half a year" or "six months", matching the "half a year" pattern or the "month" pattern calculates to 182 days or 180 days. For date fields such as "January 15, 2027", the term parsing unit calls the system's date difference function, using the current data date July 15, 2026 as the baseline, and calculates the number of days between the two to be 184 days. For fields with values ​​of "indefinite term" or that cannot be matched by the regular expression rule base, this unit marks the record as a term parsing exception and processes it according to the system's preset default handling strategy, while generating an exception log for business personnel to review afterward.

[0054] (ii) Pressure Configuration Module The stress configuration module uses a three-level key-value pair—stress scenario code, account set code, and account code—as a composite index to precisely locate the stress parameters of each accounting account under each stress scenario. This module stores all stress parameters in an independent configuration table, completely separate from the calculation engine's program code. Taking the "Personal Current Deposit" account as an example, users can configure its attrition rate as follows: 3% for mild stress, 8% for moderate stress, and 15% for severe stress. These parameters are stored in the database as records with stress scenario code S001, account set code PS001, account code A101, and attrition rates of 0.03 (mild), 0.08 (moderate), and 0.15 (severe). Parameter values ​​are modified through a graphical interface and take effect immediately without requiring compilation, packaging, or application server restart.

[0055] (III) Slow-release configuration module The mitigation configuration module is used to configure the discount rate and sell-off rate of mitigation assets according to three dimensions: legal entity, stress scenario, and stress level. These parameters are stored in a separate configuration table. For legal entity BANK001, under a mild stress scenario, this module configures a discount rate of 98% and a sell-off rate of 50% for high-quality liquid assets; under a moderate stress scenario, the discount rate is 95% and the sell-off rate is 70%; and under a severe stress scenario, the discount rate is 90% and the sell-off rate is 90%.

[0056] The mitigation configuration module includes an allocation processing unit. This unit does not use a one-size-fits-all proportional allocation method, but instead performs intelligent routing based on the term attributes of the input accounts. This unit provides two allocation strategies: (1) Precise matching strategy: For accounts with a clear remaining term, 100% of the total amount is allocated to the unique term bucket matched by the red-black tree index; (2) Model allocation strategy: For accounts without a fixed term, such as demand deposits and revolving loans, the allocation is performed according to their historical average term or the term distribution model preset by the regulator. Neither strategy requires hardcoding the number or name of buckets; it is entirely driven by the term structure configuration. When the term structure changes, both strategies automatically adapt to the new structure. If all accounts in the current scheme have a clear maturity date, the system does not perform any proportional allocation operation across term buckets.

[0057] II. Solution Level The scheme layer sits above the configuration layer. Its responsibility is to combine the three types of configurations stored independently in the configuration layer into an executable logical unit according to business intent, and to provide the execution layer with a unique scheme identifier and a complete configuration context.

[0058] The scheme layer includes a scheme binding module. This module provides a scheme table, where each record binds a stress scenario configuration, a mitigation scenario configuration, and a timeline configuration to an executable scheme. The scheme table contains the following fields: scheme code, scheme name, data date, stress scenario code, mitigation scenario code, and timeline identifier. The timeline identifier field explicitly binds the timeline configuration record used by the scheme. For example, scheme PLAN_20260715 has the scheme code PLAN_20260715, the scheme name "July 2026 Regular Stress Test Scheme", the data date July 15, 2026, the stress scenario code pointing to the standard three-level stress scenario in the stress configuration module, the mitigation scenario code pointing to the standard mitigation scenario in the mitigation configuration module, and the timeline identifier pointing to the TS_2026_001 record in the timeline main table.

[0059] When a single legal entity maintains multiple term structure configurations, the scheme binding module displays a list of all available term structure configurations under that legal entity through its configuration interface. The scheme creator then selects one of these as the term structure configuration for that scheme. The scheme binding module performs a validation operation when the scheme is saved, verifying that the selected term structure identifier is not empty and that the legal entity identifier of the term structure configuration matches the scheme's legal entity. If the validation fails, the save is rejected and a prompt message is returned. Through this explicit binding mechanism, different schemes under the same legal entity can independently select different term structures, and the calculations of each scheme do not interfere with each other. When executing a scheme, the execution layer only loads the corresponding term structure definition based on the term structure identifier in the scheme table, eliminating the need to write conditional branches for specific legal entities in the code.

[0060] III. Execution Layer The execution layer is the computational core of the system. It is responsible for receiving the scheme identifier from the scheme layer, loading the complete configuration context from the configuration layer, performing multi-scenario coupled stress test calculations, and generating structured calculation results. This layer includes a calculation engine, a summary module, and a lifecycle calculation module.

[0061] (a) Computing Engine The calculation engine is used to perform calculations based on the configuration bound to the scheme table. The calculation engine contains a loading unit, a first calculation unit, a second calculation unit, and a summarizing unit.

[0062] The loading unit is the entry point of the execution layer. For example... Figure 3 As shown, when a user triggers scheme execution, the loading unit first reads the complete scheme record from the scheme table based on the scheme code and extracts the term structure identifier. Then, the loading unit calls the index building unit of the configuration layer structure module, passing in the term structure identifier, triggering the loading of the term structure definition and the construction of the red-black tree index. After the index is built, the loading unit encapsulates the constructed red-black tree index, the number of term buckets, the coverage days of each bucket, the total number of observation windows, and the display labels of each bucket into a term structure context object. Simultaneously, the loading unit reads the corresponding parameter sets from the pressure configuration module and the mitigation configuration module, respectively, based on the stress scenario code and the mitigation scenario code in the scheme record. The loading unit then passes the term structure context object, the stress parameter mapping table, and the mitigation parameter mapping table to the downstream first and second computing units, ensuring that all computing units use a unified configuration context throughout the entire scheme execution.

[0063] The first calculation unit is responsible for calculating cash flow loss under stress scenarios. This unit iterates through all accounting items involved in the scheme. For each item, it first obtains the balance of that item under the current baseline scenario. Then, based on the current calculated stress level, it reads the loss rate of that item under that stress level from the stress parameter mapping table passed by the loading unit. The loss amount equals the item balance multiplied by the loss rate. This unit calls the proportional allocation unit in the configuration layer mitigation configuration module to allocate all the loss amount to all term buckets according to the proportion of each bucket's coverage days in the current term structure context. Taking the "three-month fixed deposit" item as an example, the balance of this item is 2 billion yuan, and the loss rate is 20% under mild stress, so the total loss amount is 400 million yuan. The proportional allocation unit allocates 400 million yuan to 9 term buckets according to the proportion of days in 9 buckets. This unit performs the above calculations for the four stress levels: baseline scenario, mild stress scenario, moderate stress scenario, and severe stress scenario, generating 4 sets of first calculation results. Each set of results contains a numerical sequence with the same number of term buckets as the current number.

[0064] The second calculation unit is responsible for calculating asset sell-offs under mitigation scenarios. This unit reads the mitigation scenario parameters bound to the current scheme from the mitigation configuration module, obtains the discount rate and sell-off rate under the current stress level, and the total amount of high-quality liquid assets. The sell-off amount equals the amount of mitigable assets multiplied by the sell-off rate and then multiplied by the discount rate. Subsequently, the second calculation unit calls the proportional allocation unit to linearly allocate the calculated total sell-off amount to each term bucket according to the proportion of the coverage days of each term bucket to the total number of days in the observation window. This unit performs the above calculations for mild stress, moderate stress, and severe stress scenarios, generating three sets of second calculation results. It should be noted that the baseline scenario (i.e., the no-stress scenario) does not involve the sell-off of mitigated assets; therefore, the second calculation unit does not generate calculation results for the baseline scenario, but only generates three sets of results to be paired and accumulated with the results of the corresponding stress level in the first calculation unit.

[0065] The aggregation unit receives the outputs from the first and second calculation units and performs a double accumulation operation. First, at the leaf account level, the aggregation unit adds the outflow amount allocated to a certain term bucket by the first calculation unit to the sell-off amount allocated to the same term bucket by the second calculation unit, obtaining the net impact value of that account in that term bucket. Then, the aggregation unit recursively aggregates from the leaf nodes upwards according to the system's pre-defined account hierarchy tree structure. Each node in the account hierarchy tree contains an account code, a parent node code, and a list of child nodes. The mathematical rule for aggregation is: the aggregated value of a parent node at bucket number j is equal to the sum of the aggregated values ​​of all its direct child nodes at bucket number j. This unit processes the account tree using a post-order traversal algorithm, processing all child nodes first, then the parent nodes. For the aggregation of each parent node, it traverses all bucket numbers from 1 to the current number of term buckets N, summing the child node values ​​for each bucket number. Throughout the aggregation process, the term buckets of all nodes are strictly accumulated one-to-one according to their bucket numbers.

[0066] (II) Summary Module The aggregation module receives the net cash flow gap values ​​for each time period bucket generated by the calculation engine and performs a time-dimensional refinement operation. For the i-th bucket in the time period bucket sequence, its coverage days are d_i, and the total gap value within the bucket is V_i. The aggregation module calculates the daily average cash flow value for this bucket as V_i divided by d_i. This value is used as the daily cash flow value for each day covered by this bucket. After each bucket is expanded sequentially according to its bucket number, the aggregation module generates a daily cash flow sequence covering the entire observation window. This sequence is a one-dimensional array of length D, where the t-th element represents the net cash flow value for day t of the observation window.

[0067] (III) Survival Calculation Module The lifespan calculation module takes the daily cash flow sequence generated by the summary module as input, and reads the available stable funds balance of the legal entity associated with the scheme on the stress test start date as the starting balance. This module performs iterative calculations starting from day 1 of the observation window: the current balance is initialized as the starting balance; for t, it iterates from 1 to D, updating the current balance to the current balance plus the t-th value in the daily cash flow sequence; it checks if the current balance is less than or equal to zero, and if it is, it terminates the loop and returns t as the shortest lifespan; if the current balance is still greater than zero after the loop ends, it returns the total number of days in the observation window D as the shortest lifespan.

[0068] IV. Output Layer The output layer is responsible for persistently storing the massive computation results generated by the execution layer and providing a unified and dynamic data view based on different needs for front-end display, data import, and data export. This layer includes a storage module and a metadata generation module.

[0069] (a) Storage module The storage module provides a row-based persistent structure separating the main table and the term bucket sub-table. The main table stores account-level information and aggregate fields that remain unchanged regardless of the term bucket. Account-level information includes data date, scheme code, account code, legal entity identifier, and analysis identifier. The aggregate fields include the sum of all term bucket values ​​for that account under the baseline scenario, the aggregate value under the mild stress scenario, the aggregate value under the moderate stress scenario, and the aggregate value under the severe stress scenario. The number and structure of fields in the main table remain constant regardless of the number of term buckets in the current term structure. The term bucket sub-table stores the specific values ​​of each term bucket in row-based storage. This sub-table contains four core fields: foreign key from the main table, stress level, bucket number, and bucket value. It also redundantly stores the data date, scheme code, legal entity identifier, and analysis identifier fields to simplify deletion operations.

[0070] The storage module comprises write and delete units, which work collaboratively within the same database transaction. When the write unit writes the calculation results to the database, it executes the following sequence of atomic operations: First, it constructs a list of records in the main table and writes them in batches to the main table; the database automatically generates and backfills the primary key for each main table record. Then, based on the backfilled primary key, it constructs a list of records in the sub-table. For each main table record, it iterates through all stress levels; for each stress level, it iterates through all expiration buckets, constructing sub-table records. Each sub-table record contains a foreign key from the main table, the stress level, the bucket number, and the bucket value. Finally, it writes all sub-table records in batches to the expiration bucket sub-table. If any of the above operations fails, the entire transaction is rolled back, and no persistent data is generated.

[0071] The delete unit performs old data cleanup before writing new data. The delete unit first constructs deletion conditions based on the scheme code and data date, prioritizing the deletion of historical records in the period bucket sub-table by directly locating the records using redundantly stored scheme code and data date fields in the sub-table, and then deleting the historical records from the main table.

[0072] (ii) Metadata Generation Module The metadata generation module is used to dynamically generate column metadata in response to changes in the term structure configuration, thereby driving the automatic adaptation of the front-end presentation layer, data import layer, and data export layer.

[0073] The metadata generation module provides a column metadata retrieval interface, which accepts the scheme code as an input parameter. When this interface is invoked, the module loads the corresponding term structure context based on the scheme code, iterates through all term bucket definitions in the context, and generates a column metadata record for each term bucket. Each column metadata record contains at least three attributes: bucket number, display label, and coverage days. For complex scenarios such as cash flow calculation, the column metadata also includes a stress level field.

[0074] After the front-end presentation layer retrieves the column metadata list via asynchronous requests, it uses the front-end framework's loop rendering command to dynamically render each record in the column metadata list as a table column. The number of table columns, column header text, and column order are all entirely driven by the column metadata. When the deadline structure changes from 9 buckets to 7 buckets, the length of the column metadata list changes from 9 to 7, and the number of columns in the front-end table automatically changes from 9 to 7, without requiring any modification to the front-end template code.

[0075] When the data import template is generated, the system calls the column metadata retrieval interface to obtain column metadata and dynamically creates a spreadsheet document using a runtime document generation library. When creating the header row of the spreadsheet document, the system writes the column names sequentially according to the column metadata order, and also writes fixed columns such as "Serial Number" and "Item". During data import parsing, the parser reads the header row of the imported file, normalizes the column names in the header by removing spaces, unifying full-width and half-width characters, converting them to lowercase, and establishing a mapping relationship between normalized column names and column indices. Then, it searches for the corresponding column index according to the preset list of expected column names and reads the value of the corresponding cell in the data row based on the found index.

[0076] When generating the data export report, the system dynamically determines the writing position of each data column based on the column metadata. The export program sequentially increments the cell column index according to the column metadata order, writing the value of the corresponding bucket number in the calculation result into the corresponding cell. When the time frame structure changes, the number of columns, column headers, and column order of the exported report automatically adapt to the new structure.

[0077] Example 2 This embodiment provides an automated method for liquidity risk stress testing that supports dynamic configuration of maturity structure. This method is implemented based on the system architecture described in Embodiment 1, as follows: Figure 4 As shown, the method includes the following steps.

[0078] Step S1: Read the term structure identifier bound to the scheme table. The scheme table pre-binds a set of stress scenario configurations, a set of mitigation scenario configurations, and a set of term structure configurations into an executable scheme. The scheme table contains a term structure identifier field. Based on the read term structure identifier, load the corresponding term structure definition and term bucket details from the database. The term structure definition contains all metadata information for that term structure, and the term bucket details contain definition records for all term buckets under that term structure. Each term bucket definition record contains a bucket number, a lower term limit, a lower term limit unit, a higher term limit, and a higher term limit unit. The term bucket definitions are stored in rows, with each term bucket stored as an independent record. The number of term buckets is not limited by the number of columns in the data table.

[0079] Extract the start and end dates of each term bucket from the loaded term bucket details data. Using the start date of each term bucket as the key, construct a term interval index based on a red-black tree in memory. During the red-black tree construction process, when keys are equal, sorting is performed using the end date as a secondary comparison criterion. Standard red-black tree self-balancing operations are performed during construction, including left rotation, right rotation, and color correction operations. Simultaneously, load the stress scenario configuration and mitigation scenario configuration bound to the scheme. The stress scenario configuration contains the attrition rate parameters for each subject at each stress level, and the mitigation scenario configuration contains the discount rate and sell-off rate parameters for each stress level. Pass the constructed term structure context to subsequent steps. This term structure context includes at least the number of term buckets, the coverage days of each term bucket, the total number of days in the observation window, and red-black tree index references.

[0080] Step S2: Parse the expiration information of the raw data and convert it into standardized days. The expiration information of the raw data includes two types: non-standardized expiration descriptions in text form and structured expiration data in date form. For the text information of non-standardized expiration descriptions, a regular expression rule base is used for parsing. The regular expression rule base matches keywords in priority order. Keywords include "day," "week," "month," "quarter," and "year," as well as their corresponding plural forms or synonyms. When the keyword "week" is matched, the value associated with the keyword is multiplied by 7 to convert it to days; when the keyword "month" is matched, the value is multiplied by 30 to convert it to days; when the keyword "quarter" is matched, the value is multiplied by 90 to convert it to days; and when the keyword "year" is matched, the value is multiplied by 365 to convert it to days. For date fields, the date difference function is called to calculate the remaining days between the current date and the expiration date. The parsed standardized days are used as the lookup key, and a binary search operation is performed using a red-black tree index to match the corresponding expiration bucket. Specifically, the search is performed in the red-black tree using the standardized number of days as the search key. The search key is compared with the start date of the current node. Based on the comparison result, it is decided whether to enter the left subtree or the right subtree to continue the search until the first node with a start date not greater than the search key and an end date not less than the search key is found. The bucket number corresponding to that node is then returned.

[0081] Step S3: For each subject, read the churn rate parameter under the corresponding pressure level according to the pressure scenario configuration. The churn rate parameter includes at least the churn rate under the mild pressure level, the churn rate under the moderate pressure level, and the churn rate under the severe pressure level. Calculate the churn amount, which is equal to the current balance of the subject multiplied by the churn rate under the corresponding pressure level. Allocate the churn amount to each term bucket according to the proportion of the actual number of days in each term bucket to the total number of days in the observation window. The total number of days in the observation window is equal to the sum of the coverage days of all term buckets, dynamically summed from the configuration data. The allocation formula is: the amount allocated to the i-th term bucket is equal to the total churn amount multiplied by the coverage days of the i-th term bucket divided by the total number of days in the observation window. Perform the above churn amount calculation and allocation operations for the baseline scenario, mild pressure scenario, moderate pressure scenario, and severe pressure scenario respectively.

[0082] Step S4: Based on the mitigation scenario configuration, read the discount rate and sell-off rate for the corresponding stress level. The discount rate and sell-off rate must include the corresponding values ​​for the mild stress level, the moderate stress level, and the severe stress level. Calculate the sell-off amount, which equals the mitigable asset amount multiplied by the sell-off rate and then multiplied by the discount rate. Allocate the sell-off amount to each term bucket according to the proportion of the actual number of days in each term bucket to the total number of days in the observation window, using the same proportional allocation method as in Step S3. Perform the above sell-off amount calculation and allocation operations for the mild, moderate, and severe stress scenarios respectively.

[0083] Step S5: Add the allocation results from Step S3 and Step S4 to the cash flow. The accumulation method is as follows: at each term bucket position, add the amount allocated to that term bucket in Step S3 to the amount allocated to that term bucket in Step S4. Aggregate recursively from bottom to top according to the account hierarchy tree. The account hierarchy tree is composed of the parent-child relationships between accounting accounts, with leaf nodes representing the finest-grained accounts and parent nodes representing the account summary nodes. During aggregation, first locate all leaf nodes, complete the above accumulation operation on the leaf nodes, and then pass the accumulation result of the leaf nodes to their parent nodes. The parent node adds the values ​​of all child nodes with the same bucket number to obtain the summary value of the parent node at that bucket number, and continues to pass upwards until the root node.

[0084] Step S6: The cash flow gap values ​​within each term bucket are uniformly refined into daily values. For the i-th term bucket with a coverage period of d, the total cash flow gap value within that term bucket is divided by d to obtain the average daily cash flow value within that term. The daily average cash flow values ​​of each term bucket are arranged sequentially according to their chronological order, forming a daily cash flow sequence covering the entire observation window. The daily net cash flow is incrementally accumulated in chronological order. Specifically, starting from the beginning of the observation window, the daily net cash flow in the daily cash flow sequence is accumulated with the current balance, and the closing balance for each day is determined after each accumulation. When the closing balance is not greater than zero for the first time, the number of days elapsed from the beginning to that day is recorded as the shortest survival period. If the closing balance is always greater than zero throughout the entire observation window, the total number of days in the observation window is returned as the shortest survival period.

[0085] Step S7: Store the calculation results using a row-based storage structure that separates the main table and the term bucket sub-table. The main table stores the subject dimension and total fields that do not change with the term bucket. The subject dimension fields include at least the data date, scheme code, subject code, legal entity identifier, and analysis identifier. The total fields include at least the baseline scenario total value, the mild stress scenario total value, the moderate stress scenario total value, and the severe stress scenario total value. The term bucket sub-table stores the calculated values ​​of each term bucket under each stress level in row format, including the main table foreign key, stress level, bucket number, and bucket value fields.

[0086] Within the same transaction, first, write records to the main table in batches. After writing the main table records, wait for the database to automatically populate the primary keys of the main table records into the corresponding memory objects. Based on the populated primary keys, construct the batch write data for the term bucket sub-tables. Each sub-table record contains the corresponding main table foreign key, stress level, bucket sequence number, and bucket value. Batch write the term bucket sub-table records. The sub-table records also include the data date, scheme code, legal entity identifier, and analysis identifier as redundant fields. When deleting old data, perform cascading deletions in the order of term bucket sub-tables taking precedence over the main table. Use the redundant dimension fields in the sub-tables to construct deletion conditions to directly delete the sub-table records, and then delete the main table records.

[0087] Step S8: Dynamically generate column metadata based on the term structure definition. Column metadata includes at least the bucket number, display label, and coverage days. It may also include the field mapping name and the associated stress level. The front-end presentation layer dynamically generates table columns using a loop instruction driven by the column metadata. Specifically, after obtaining the column metadata list, the front-end rendering engine performs a loop rendering operation for each column metadata entry to generate the corresponding table column. The column's display label is taken from the display label in the column metadata, and the column's order is determined by the bucket number.

[0088] The data import template dynamically generates header rows based on column metadata using a runtime document generation library. During template generation, header cells are created according to the order of buckets in the column metadata list, and display labels are written to the corresponding cells. During import parsing, the header rows of the imported file are read, and the names of each column in the header are normalized to establish a mapping between normalized column names and column indices. The corresponding column index is then searched according to the preset list of expected column names, and the corresponding cell value from the data row is read based on the found column index.

[0089] The data export report dynamically writes data to cells based on column metadata. When the report is generated, the column index of the cell is determined according to the order of each bucket in the column metadata list, and the corresponding calculated value is written to the cell at that column index position. The column index of the cell changes dynamically with the length of the column metadata list.

[0090] Example 3 This embodiment takes the scenario where the same legal entity maintains multiple time-limited structures and different schemes are selected respectively as an example to illustrate the specific implementation of the scheme-level explicit binding mechanism in the technical solution of this application.

[0091] A commercial bank entity, BANK002, faced both regulatory reporting requirements and internal management analysis needs, and maintained two maturity structure schemes in the system. The first maturity structure, named the "Regulatory Four-Barrel Scheme," includes four maturity barrels: the next-day barrel covers 1 day, the 2-7 day barrel covers 6 days, the 8-30 day barrel covers 23 days, and the 31-90 day barrel covers 60 days, with a total observation window of 90 days. The second maturity structure, named the "Management Seven-Barrel Scheme," includes seven maturity barrels: the next-day barrel covers 1 day, the 2-3 day barrel covers 2 days, the 4-7 day barrel covers 4 days, the 8-15 day barrel covers 8 days, the 16-30 day barrel covers 15 days, the 31-60 day barrel covers 30 days, and the 61-90 day barrel covers 30 days, with a total observation window of 90 days.

[0092] The configuration records for both maturity structures are stored in the main maturity structure table and the maturity bucket detail sub-table. In the main maturity structure table, the legal entity identifier field for both records is BANK002. In the maturity bucket detail sub-table, the "Regulatory Four Buckets Scheme" corresponds to 4 maturity bucket detail records, and the "Management Seven Buckets Scheme" corresponds to 7 maturity bucket detail records, all stored in row-based format.

[0093] A business user creates Plan A, named "January 2026 Regulatory Submission Plan". In the plan editing form's term structure dropdown menu, the system filters by legal entity identifier BANK002, displaying all two term structure plans under that legal entity. The business user selects "Regulatory Four-Barrel Plan", and the term structure identifier field in the plan table records the unique structural identifier STR_004 for the "Regulatory Four-Barrel Plan". When the plan is saved, the system verifies that the legal entity identifier BANK002 in the term structure configuration matches the legal entity identifier BANK002 in the plan, and the verification passes.

[0094] Business personnel create Plan B, named "Internal Management Analysis Plan for January 2026". In the term structure dropdown menu, they select "Management Seven Buckets Plan". The term structure identifier field in the plan table records the unique structural identifier STR_007 for the "Management Seven Buckets Plan". When the plan is saved, a legal entity consistency check is performed, and the check passes.

[0095] Business personnel execute both Plan A and Plan B simultaneously. When executing Plan A, the loading unit reads the term structure identifier STR_004 of Plan A, accurately loads the four term bucket details under the "Regulatory Four-Bucket Plan" from the database, and constructs a red-black tree index containing four nodes. The calculation engine completes all calculations according to the four-bucket structure, generating result data with a four-bucket structure. When executing Plan B, the loading unit reads the term structure identifier STR_007 of Plan B, accurately loads the seven term bucket details under the "Management Seven-Bucket Plan" from the database, and constructs a red-black tree index containing seven nodes. The calculation engine completes all calculations according to the seven-bucket structure, generating result data with a seven-bucket structure.

[0096] The calculation results of the two schemes are stored independently in a main table and a term bucket sub-table. In the result storage of Scheme A, the bucket number of each result record in the term bucket sub-table ranges from 1 to 4. In the result storage of Scheme B, the bucket number of each result record in the term bucket sub-table ranges from 1 to 7. The results of the two schemes do not interfere with each other and are stored in row-based storage. The scheme code field is redundantly written into the sub-table records to facilitate data querying and deletion by scheme code.

[0097] When displaying the results of Scheme A, the front-end presentation layer calls the column metadata retrieval interface to pass the code of Scheme A. The metadata generation module loads the term structure definition of the "Regulatory Four-Barrel Scheme" based on the code of Scheme A, generating a list containing four column metadata entries. The front-end page renders four term bucket columns. When displaying the results of Scheme B, the metadata generation module loads the term structure definition of the "Management Seven-Barrel Scheme" based on the code of Scheme B, generating a list containing seven column metadata entries. The front-end page renders seven term bucket columns. When the same user views the results of different schemes within the same system, the number of columns on the page automatically adapts to the respective bound term structures.

[0098] Example 4 This embodiment takes the scenario of automatic template adaptation after a change in the term structure as an example to illustrate the specific implementation of the dynamic generation module for column data in the technical solution of this application.

[0099] At a certain point in time, the maturity structure configured in the system of a commercial bank entity BANK003 is a 5-bucket structure, with each bucket covering 1 day from the next day, 6 days from the 2nd to the 7th day, 23 days from the 8th to the 30th day, 30 days from the 31st to the 60th day, and 30 days from the 61st to the 90th day, for a total observation window of 90 days. The system has completed multiple stress test calculations according to this maturity structure, and the results data are stored in the main table and the maturity bucket sub-tables.

[0100] Business personnel need to export stress test results data for a certain period to a spreadsheet report. The export program calls the metadata generation module to obtain column metadata. The metadata generation module loads the current 5-bucket term structure definition according to the scheme code, generating a list containing 5 column metadata entries. The display labels for each column metadata entry are "Next Day", "2-7 Days", "8-30 Days", "31-60 Days", and "61-90 Days". The export program creates 5 data columns in the spreadsheet according to the order of the 5 column metadata entries, and writes the calculated values ​​of each term bucket into the corresponding cells in sequence. The exported report is generated successfully.

[0101] On the same day, regulatory authorities issued new time limit classification requirements, merging the original "31-60 day" and "61-90 day" buckets into a single "31-90 day" bucket, and adding a new "91-180 day" bucket. Business personnel logged into the system and accessed the time limit structure configuration interface. In the "5-bucket structure" scheme, they adjusted the time limit bucket definitions: deleting the "31-60 day" bucket record with bucket number 4, deleting the "61-90 day" bucket record with bucket number 5, adding a new "31-90 day" bucket record with bucket number 4 (lower limit 31 days, upper limit 90 days), and adding a new "91-180 day" bucket record with bucket number 5 (lower limit 91 days, upper limit 180 days). All operations were completed through a graphical interface; the system automatically updated the records in the time limit bucket details sub-table, without requiring the execution of data table structure change commands.

[0102] After the business personnel saved the changed term structure configuration, the system was not restarted and the code was not modified. The business personnel then accessed the export report function again, selecting to export the stress test results data for the same period. The export program again called the metadata generation module to retrieve column metadata. The metadata generation module loaded the changed 5-bucket term structure definition according to the scheme code, generating a list containing 5 column metadata entries. The display labels for each column metadata were updated to "Next Day," "2-7 Days," "8-30 Days," "31-90 Days," and "91-180 Days." The export program created 5 data columns according to the new column metadata and read the corresponding bucket values ​​from the term bucket sub-table, writing them into the cells.

[0103] Business personnel also need to import the new period's basic data. The import template generation program calls the metadata generation module to obtain column metadata and dynamically generates the import template through the runtime document generation library. In the template's header row, the column headers corresponding to the time period buckets are "Next Day", "2-7 Days", "8-30 Days", "31-90 Days", and "91-180 Days". After business personnel fill in the data in the import template, they execute the import operation. The import parser reads the template header row and establishes a mapping relationship between normalized column names and column indices. The parser looks up the column indices of each column according to the expected column name list and correctly writes the data into the corresponding fields.

[0104] Example 5 This embodiment takes the specific application of the proportional redistribution algorithm in the calculation of sustained-release scenarios as an example to illustrate the specific implementation of the decoupling of the sustained-release scenario simulation module and the term structure in the technical solution of this application.

[0105] A commercial bank entity, BANK004, has a maturity structure comprising five maturity buckets. The coverage days are as follows: Bucket 1 covers 1 day (next-day bucket), Bucket 2 covers 6 days (2-7 day bucket), Bucket 3 covers 23 days (8-30 day bucket), Bucket 4 covers 30 days (31-60 day bucket), and Bucket 5 covers 30 days (61-90 day bucket). The total observation window, D, equals 1 + 6 + 23 + 30 + 30 = 90 days.

[0106] During the stress test calculations, the second calculation unit calculated the total sell-off amount under a mild stress scenario to be 245 million yuan. The proportional allocation unit received the total sell-off amount of 245 million yuan, the coverage days of each of the five term buckets, and the total observation window of 90 days as input parameters. The allocation amount for Bucket 1 was 245 million yuan multiplied by 1 and divided by 90, equaling 27.2 million yuan. The allocation amount for Bucket 2 was 245 million yuan multiplied by 6 and divided by 90, equaling 16.33 million yuan. The allocation amount for Bucket 3 was 245 million yuan multiplied by 23 and divided by 90, equaling 62.6 million yuan. The allocation amount for Bucket 4 was 245 million yuan multiplied by 30 and divided by 90, equaling 81.67 million yuan. The allocation amount for Bucket 5 was 245 million yuan multiplied by 30 and divided by 90, equaling 81.67 million yuan. The sum of the allocation amounts for the five buckets was 245 million yuan, consistent with the total sell-off amount.

[0107] In subsequent term structure adjustments, the business personnel changed the term structure from 5 buckets to 6 buckets, splitting the original "31-60 days" bucket into "31-45 days" and "46-60 days" buckets. The coverage days for each bucket became: Bucket 1 covers 1 day, Bucket 2 covers 6 days, Bucket 3 covers 23 days, Bucket 4 covers 15 days, Bucket 5 covers 15 days, and Bucket 6 covers 30 days. The total observation window days D were updated to 1 + 6 + 23 + 15 + 15 + 30 = 90 days. After the term structure adjustment was saved, the proportional allocation unit required no code modification. During the next execution of the plan, the proportional allocation unit automatically calculated the allocation ratio for each bucket based on the new term structure. The total sale amount of RMB 245 million was allocated to the six barrels according to the new proportion: RMB 27.2 million to barrel 1, RMB 16.33 million to barrel 2, RMB 62.6 million to barrel 3, RMB 40.83 million to barrel 4, RMB 40.83 million to barrel 5, and RMB 81.67 million to barrel 6.

[0108] If the business personnel further extend the observation window from 90 days to 365 days, adding three buckets: "91-180 days", "181-270 days", and "271-365 days", the total number of days covered by all buckets, D, becomes 365 days. The proportional allocation unit automatically reads the new total number of days in the observation window, 365 days, as the denominator, and allocates the sales amount to each bucket according to the proportion of its covered days to the 365 days.

[0109] Example 6 This embodiment uses the matching performance of a red-black tree index under different number of time-limited buckets as an example to illustrate the technical effect of the index building unit in the technical solution of this application.

[0110] A commercial bank entity, BANK005, has configured a term structure in the system that includes 94 term buckets, covering the entire observation window from the next day to 5 years. The detailed records of the 94 term buckets are stored in a term bucket detail sub-table in row storage, with one record per bucket, for a total of 94 records.

[0111] During scheme execution, the loading unit loads 94 records from the term bucket detail sub-table based on the term structure identifier bound to the scheme. The index building unit traverses these 94 records to construct a red-black tree index. The 94 records are then sorted by start date and inserted into the red-black tree sequentially. During insertion, a standard red-black tree self-balancing operation is performed. The red-black tree maintains balance through left rotation, right rotation, and color correction operations, keeping its height within twice the base-2 logarithm of 95, i.e., no more than 14 levels.

[0112] The basic data contains approximately 12,000 cash flow records. Each cash flow record is converted to a standardized number of days by a period parsing unit, and then a binary search is performed in the red-black tree index using the standardized number of days as the lookup key. For a red-black tree with a height of 14 levels, each search involves a maximum of 14 comparison operations. The total number of comparisons for 12,000 records is approximately 168,000. During the binary search, the lookup key is compared with the key value of the current node. If they are equal, the bucket number corresponding to that node is returned; if it is less than the key value of the current node, the search continues in the left subtree; if it is greater than the key value of the current node, the search continues in the right subtree. Each node stores the start date and end date. During the search, it is simultaneously determined whether the lookup key falls within the interval formed by the start date and end date. If it falls within the interval, the bucket number corresponding to that node is returned.

[0113] If a field-by-field traversal search method is used, for 94 time buckets, each cash flow record requires a maximum of 94 comparisons to determine its bucket, resulting in a total of approximately 1,128,000 comparisons for 12,000 records. The red-black tree index method reduces the number of comparisons to about one-seventh of that required by the field-by-field traversal method.

[0114] Example 7 This embodiment uses a row storage structure with separate result storage main table and expiration bucket sub-table as an example to illustrate the workflow of the storage module in the technical solution of this application during data writing and deletion operations.

[0115] After a certain period of stress testing calculations is completed, the results include the values ​​for each term bucket for 500 subjects under four stress levels: baseline scenario, mild stress scenario, moderate stress scenario, and severe stress scenario. The current scheme's term structure includes 9 term buckets.

[0116] The write unit performs write operations after a database transaction begins. The write unit first constructs a list of records in the master table, which is the `alm_stress_testing_cash` table. Each master table record contains a data date field, a scheme code field, a subject code field, a legal entity identifier field, a baseline scenario total value field, a mild stress scenario total value field, a moderate stress scenario total value field, and a severe stress scenario total value field. 500 master table records are written to the database using a batch insert method. After the database performs the batch insert, it automatically generates the primary key identifier for each record and populates it back into the corresponding memory object.

[0117] The write unit then constructs a list of term bucket sub-table records, using the `alm_stress_testing_cash_bucket` table. For each of the 500 main table records, the write unit iterates through 4 stress levels, and for each stress level, iterates through 9 term buckets, constructing 500 x 4 x 9 = 18,000 sub-table records. Each sub-table record includes: a main table foreign key field populated with the corresponding main table record's backfilled identifier value; a stress level field populated with the stress level identifier; a bucket number field populated with bucket numbers 1 to 9; a bucket value field populated with the calculated value of the subject for that term bucket under that stress level; a redundant data date field populated with the data date; a redundant scheme code field populated with the scheme code; and a redundant legal entity identifier field populated with the legal entity identifier. These 18,000 sub-table records are written to the database using a batch write method. The write operation is completed within the same transaction. If the main table write succeeds but the sub-table write fails, the transaction is rolled back, the records already written to the main table are undone, and no residual data is generated in the database.

[0118] The deletion unit performs old data cleanup before writing new data. The deletion unit receives the scheme code and data date as deletion conditions. First, the deletion unit constructs deletion conditions for the sub-table `alm_stress_testing_cash_bucket`, where the scheme code equals the current scheme code and the data date equals the current data date. The deletion unit then executes the sub-table deletion operation, deleting all records that meet the conditions. After the sub-table deletion is complete, the deletion unit constructs deletion conditions for the main table `alm_stress_testing_cash` and executes the main table deletion operation.

[0119] Example 8 This embodiment uses the parsing and processing of various non-standardized term information formats by the term parsing unit as an example to illustrate the specific implementation of the term parsing unit in the technical solution of this application.

[0120] The due date information for each subject in the original data exists in multiple formats. The due date parsing unit needs to be uniformly converted into standardized days so that a lookup can be performed in the red-black tree index.

[0121] The first record is a personal current deposit account, with the maturity date field stored as the text "seven calendar days". The regular expression rule base of the maturity parsing unit scans the text according to priority, first matching the keyword "day", extracting the associated value 7, and outputting 7 as the standardized number of days.

[0122] The second record is a fixed deposit account, with the maturity date field stored as the text "two weeks". The regular expression rule base scans the text, matches the keyword "week", extracts the associated value 2, then multiplies 2 by 7 to get 14, and outputs 14 as the standardized number of days.

[0123] The third record is a large-denomination certificate of deposit account, with the maturity date field stored as the text "three months". The rule base matches the keyword "month", extracts the associated value 3, multiplies 3 by 30 to get 90, and outputs 90 as the standardized number of days.

[0124] The fourth record is a wealth management product category, with the maturity date field stored as the text "one quarter". The rule base matches the keyword "quarter", extracts the associated value 1, multiplies 1 by 90 to get 90, and outputs 90 as the standardized number of days.

[0125] The fifth record is a bond investment account, and the maturity date field is stored as the text "half a year". The rule base first matches the keyword "year" but does not find it, and continues to match the "half a year" pattern. It recognizes that "half a year" is equivalent to 0.5 years, multiplies 0.5 by 365 to get 182.5, rounds it to the nearest integer to 183, and outputs 183 as the standardized number of days.

[0126] Record number six is ​​an interbank certificate of deposit account, with the maturity date field stored as the text "one year". The rule base matches the keyword "year", extracts the associated value 1, multiplies 1 by 365 to get 365, and outputs 365 as the standardized number of days.

[0127] The seventh record is a loan subject, and the maturity date field is stored as a date type value "2027-01-15". The term parsing unit recognizes this field as a date type, obtains the current system date 2026-07-15, calls the date difference function to calculate the number of days between the two dates as 184 days, and outputs 184 as the standardized number of days.

[0128] Record number 8 is a commercial paper account, with the maturity date field stored as the text "indefinite term". The regular expression rule base scans this text and finds no matching keywords. The term parsing unit marks this record as an abnormal record, writes it to the abnormal log, and classifies it into the overdue bucket or the maximum term bucket according to the preset default processing strategy.

[0129] Example 9 This embodiment uses the bottom-up recursive aggregation process of the subject hierarchy tree as an example to illustrate the specific implementation of the summarization unit in the technical solution of this application.

[0130] The leaf nodes of the account hierarchy tree contain the following accounts and their corresponding cash flow gap values ​​for the nine term buckets: personal demand deposits, personal time deposits, corporate demand deposits, corporate time deposits, interbank deposits, and borrowed funds. These leaf node accounts belong to the second-level parent node "Deposits". "Deposits" belongs to the first-level parent node "Total Liabilities". The leaf nodes of another branch contain loans, bond investments, interbank deposits, and borrowed funds, belonging to the second-level parent node "Assets". "Assets" belongs to the first-level parent node "Total Assets".

[0131] The aggregation unit first accumulates the allocation results of the first and second calculation units at each leaf node. Taking the leaf node for personal current deposits as an example, the accumulated values ​​of the nine term buckets at this node are as follows: Bucket 1: 1 million yuan; Bucket 2: 5 million yuan; Bucket 3: 20 million yuan; Bucket 4: 50 million yuan; Bucket 5: 80 million yuan; Bucket 6: 100 million yuan; Bucket 7: 120 million yuan; Bucket 8: 150 million yuan; Bucket 9: 200 million yuan. For the leaf node for personal time deposits, the values ​​of the nine term buckets are as follows: Bucket 1: 2 million yuan; Bucket 2: 6 million yuan; Bucket 3: 30 million yuan; Bucket 4: 60 million yuan; Bucket 5: 90 million yuan; Bucket 6: 110 million yuan; Bucket 7: 140 million yuan; Bucket 8: 160 million yuan; Bucket 9: 210 million yuan. The nine term bucket values ​​for the leaf nodes of corporate demand deposits are as follows: Bucket 1: RMB 1.5 million; Bucket 2: RMB 4 million; Bucket 3: RMB 15 million; Bucket 4: RMB 40 million; Bucket 5: RMB 60 million; Bucket 6: RMB 80 million; Bucket 7: RMB 100 million; Bucket 8: RMB 120 million; and Bucket 9: RMB 180 million.

[0132] The aggregation unit passes the values ​​of the three leaf nodes to the "Personal Deposits" parent node. The aggregation method for the "Personal Deposits" parent node is as follows: For bucket number 1, add the bucket value of 1 million yuan for personal current deposits (1 million yuan) to the bucket value of 2 million yuan for personal time deposits (2 million yuan) to the bucket value of 1.5 million yuan for corporate current deposits (1.5 million yuan), resulting in a bucket value of 4.5 million yuan for the personal deposit node. For bucket numbers 2 to 9, the same corresponding accumulation method is used, and the value of the parent node's bucket number j is equal to the sum of the bucket numbers j of all child nodes.

[0133] The "Personal Deposits" parent node continues to propagate upwards to the "All Deposits" parent node. The "All Deposits" node simultaneously receives values ​​from the "Personal Deposits" node, the "Interbank Deposits" leaf node, and the "Borrowed Funds" leaf node. The "All Deposits" node aggregates values ​​by adding the corresponding bucket numbers. After aggregation, the "All Deposits" node propagates upwards to the "Total Liabilities" parent node. The "All Assets" node in the other branch aggregates leaf node values ​​layer by layer upwards in the same way, ultimately propagating to the "Total Assets" parent node.

[0134] The root node "Net Cash Flow" receives the values ​​from the "Total Liabilities" node and the "Total Assets" node. According to the rule that the cash flow gap equals the outflow minus the inflow, the asset value of the corresponding bucket number is subtracted from the liability value to obtain the final cash flow gap value of the 9 buckets of the root node.

[0135] Example 10 This embodiment uses the process of the lifespan calculation module refining the time bucket gap value into daily cash flows and calculating the shortest lifespan as an example to illustrate the specific implementation of the lifespan calculation module in the technical solution of this application.

[0136] After the summary module completes the recursive aggregation of the subject hierarchy tree, the cash flow gap values ​​of the nine term buckets at the root node are as follows: Bucket 1 covers the next day and covers 1 day with a gap value of -5 million yuan, indicating a net outflow of 5 million yuan; Bucket 2 covers 2-7 days and covers 6 days with a gap value of -30 million yuan, indicating a total net outflow of 30 million yuan within those 6 days; Bucket 3 covers 8-30 days and covers 23 days with a gap value of -250 million yuan; Bucket 4 covers 31-60 days and covers 30 days with a gap value of -300 million yuan; Bucket 5 covers 61-90 days and covers 30 days with a gap value of -200 million yuan; Bucket 6 covers 91-180 days and covers 90 days with a gap value of -100 million yuan; Bucket 7 covers 181-270 days and covers 90 days with a gap value of 50 million yuan, indicating a net inflow; Bucket 8 covers 271-365 days and covers 95 days with a gap value of 80 million yuan; and Bucket 9 covers 366-730 days and covers 365 days with a gap value of 150 million yuan.

[0137] The lifespan calculation module receives the gap values ​​of the above nine term buckets as input. First, the module calls the refinement function of the aggregation module to evenly refine the total gap value of each term bucket to the daily net cash flow: Bucket 1's -5 million yuan covers one day, serving as the first day's value; Bucket 2's total gap value of -30 million yuan divided by the coverage days of 6 yields a daily net cash flow of -5 million yuan, corresponding to the daily values ​​for the 6 days from the 2nd to the 7th of the observation window. Bucket 3's total gap value of -250 million yuan divided by the coverage days of 23 yields a daily net cash flow of approximately -10.87 million yuan, corresponding to the daily values ​​for the 23 days from the 8th to the 30th. Bucket 4's total gap value of -300 million yuan divided by the coverage days of 30 yields a daily net cash flow of -10 million yuan, corresponding to the daily values ​​for the 30 days from the 31st to the 60th. Bucket 5's total gap value of -200 million yuan divided by the coverage days of 30 yields a daily net cash flow of approximately -6.67 million yuan, corresponding to the daily values ​​for the 30 days from the 61st to the 90th. The total shortfall of Bucket 6, -100 million yuan, divided by the coverage period of 90 days, yields a daily net cash flow of approximately -1.11 million yuan, corresponding to the daily values ​​for days 91 to 180. The total shortfall of Bucket 7, 50 million yuan, divided by the coverage period of 90 days, yields a daily net cash flow of approximately 560,000 yuan, corresponding to the daily values ​​for days 181 to 270. The total shortfall of Bucket 8, 80 million yuan, divided by the coverage period of 95 days, yields a daily net cash flow of approximately 840,000 yuan, corresponding to the daily values ​​for days 271 to 365. The total shortfall of Bucket 9, 150 million yuan, divided by the coverage period of 365 days, yields a daily net cash flow of approximately 410,000 yuan, corresponding to the daily values ​​for days 366 to 730.

[0138] The lifespan calculation module arranges the above daily cash flow sequence in chronological order, forming a complete sequence from day 1 to day 730. The lifespan calculation module reads the initial balance as 3 billion yuan. Starting from day 1, the current balance is added to the net cash flow of the day to obtain the final balance for that day. The balance on day 1 is 3 billion yuan minus 5 million yuan, which equals 2.995 billion yuan. The balance on day 2 is 2.995 billion yuan minus 5 million yuan, which equals 2.99 billion yuan. From day 3 to day 7, the balance decreases by 5 million yuan each day. From day 8 to day 30, the balance decreases by approximately 10.87 million yuan each day. From day 31 to day 60, the balance decreases by 10 million yuan each day. From day 61 to day 90, the balance decreases by approximately 6.67 million yuan each day. From day 91 to day 180, the balance decreases by approximately 1.11 million yuan each day.

[0139] The survival period calculation module continued to accumulate until day 218, when the current balance was approximately -2 million yuan, marking the first time the balance was not greater than zero. The survival period calculation module recorded 218 days as the shortest survival period under this stress scenario.

[0140] It should be noted that the above embodiments are merely preferred embodiments of the present invention, used to help those skilled in the art understand and implement the technical solutions of the present invention, and are not intended to limit the scope of protection of the present invention. Various equivalent substitutions, modifications, and improvements that can be made by those skilled in the art based on the technical solutions disclosed in the present invention without creative effort should all fall within the scope of protection of the present invention.

[0141] The numerical values, proportions, specific programming languages, database types, front-end frameworks, etc. involved in the technical solutions of this invention are only illustrative examples. In practical applications, they can be adaptively adjusted according to specific business scenarios and system environments. These adjustments do not change the technical essence of this invention and should still fall within the protection scope of this invention.

[0142] The modules and units of this invention can be deployed in a centralized manner on a single server or in a distributed manner on a cluster system composed of multiple servers. They can run as independent systems or as plug-ins or components embedded in existing asset and liability management systems. These variations in deployment do not constitute a substantial change to the technical solution of this invention.

[0143] The conventional technical means not shown in detail in the specification and embodiments of this invention are all implemented using technical methods known in the art, and their specific implementation details do not affect the sufficiency and feasibility of the technical solution of this invention.

Claims

1. A liquidity risk stress testing system that supports dynamic configuration of maturity structure, characterized in that: It includes a configuration layer, a solution layer, an execution layer, and an output layer; The configuration layer is located at the bottom layer to provide metadata definitions; the scheme layer is built on top of the configuration layer, combining various configurations into executable schemes and providing scheme identifiers; the execution layer is coupled to the configuration layer and the scheme layer respectively, loads the configuration according to the scheme identifier and performs stress test calculations, and outputs the results to the output layer; the output layer is located at the top layer, stores the calculation results and drives the front-end display according to the term structure definition; The configuration layer includes a structure configuration module, which provides term structure definitions and term bucket definitions. Term buckets are stored independently, and the term structure definition and term bucket details are loaded based on the term structure identifier. A red-black tree-based term interval index is built in memory, and a binary search is performed in the red-black tree using the standardized number of days as the lookup key to match term buckets. The configuration layer also includes a stress configuration module and a mitigation configuration module, which store stress parameters and discount rates and sell-off rates, respectively. The mitigation configuration module is also used to match cash flows with a clear remaining term to a unique corresponding term bucket based on their remaining days using the red-black tree index. For cash flows without a clear maturity date or recurring items, allocation is performed according to their historical average term or a preset term structure model. The solution layer includes a solution binding module, which provides a solution table to bind stress scenario configuration, mitigation scenario configuration, and term structure configuration into an executable solution. The solution table includes a term structure identifier field. The execution layer includes a calculation engine, a summary module, and a lifetime calculation module; the calculation engine is used to load stress parameters and perform term bucket allocation calculations, and summarizes and generates cash flow gap values ​​for each term bucket. The summary module is used to refine the gap value into a daily cash flow sequence; the survival calculation module is used to calculate the shortest survival based on the daily cash flow sequence. The output layer includes a storage module and a metadata generation module; The storage module is used to provide a row-based storage structure that separates the main table from the expiration bucket sub-tables; The metadata generation module is used to dynamically generate column metadata to drive front-end display, data import, and data export.

2. The liquidity risk stress testing system supporting dynamic configuration of maturity structure according to claim 1, characterized in that, The structure configuration module includes an index building unit. Before the calculation starts, the index building unit loads the corresponding term structure definition and term bucket details according to the term structure identifier bound to the current scheme, builds a red-black tree index in memory, and responds to the term matching request of cash flow data by performing term bucket matching with the red-black tree index.

3. The liquidity risk stress testing system supporting dynamic configuration of maturity structure according to claim 1, characterized in that, The computing engine comprises a loading unit, a first computing unit, a second computing unit, and a summarizing unit; When the calculation starts, the loading unit reads the term structure identifier of the scheme table, verifies that the legal entity identifier of the term structure configuration is consistent with the scheme legal entity, calls the structure configuration module to load the corresponding term structure definition and build a red-black tree index, and loads the stress scenario parameters and mitigation scenario parameters. The completed term structure context is then passed through to each downstream calculation unit. The first calculation unit traverses each subject, reads the churn rate parameter under the corresponding stress level from the stress configuration module, calculates the churn amount, and calls the allocation processing unit to allocate the churn amount to the corresponding term bucket based on the remaining term characteristics of the subject. For accounts with a clear maturity date, a unique term bucket is directly matched using a red-black tree index; for accounts without a maturity date, the amount is allocated according to a preset term structure model; the second calculation unit reads the discount rate and sell-off rate from the mitigation configuration module, calculates the sell-off amount, and calls the allocation processing unit to allocate the sell-off amount to the corresponding term bucket based on the remaining maturity characteristics of the mitigated assets, with matching rules consistent with the first calculation unit; the aggregation unit adds the first calculation result and the allocation result of the second calculation unit, and recursively aggregates them from bottom to top according to the account hierarchy tree, where the term buckets of parent and child nodes are accumulated one by one according to the bucket number.

4. The liquidity risk stress testing system supporting dynamic configuration of maturity structure according to claim 2, characterized in that, When constructing the red-black tree index, the index building unit uses the start date of each expiration bucket as the key value of the red-black tree node and the complete information of the expiration bucket as the value of the node. When key values ​​are equal, the end date is used as a secondary comparison criterion for sorting. After the insertion operation is completed, the red-black tree balance correction algorithm is executed. When matching expiration buckets, a floor search is performed in the red-black tree using the normalized number of days as the lookup key. After locating the node, it is further verified whether the end date of the expiration bucket represented by the node is greater than or equal to the lookup key. If the verification is successful, the bucket number corresponding to the node is returned. If the verification fails, it is determined that the expiration does not belong to any defined expiration bucket and is handled according to the system's preset exception handling strategy.

5. The liquidity risk stress testing system supporting dynamic configuration of maturity structure according to claim 1, characterized in that, The structure configuration module includes a term parsing unit, which has a built-in regular expression rule library. This unit is used to perform regular expression matching and standardization of days for non-standardized term information in the original imported data, as well as to calculate the remaining days for date fields. The regular expression rule library is organized according to keyword priority. Keywords include day, week, month, quarter, year and their corresponding synonyms.

6. The liquidity risk stress testing system supporting dynamic configuration of maturity structure according to claim 1, characterized in that, The scheme binding module displays a list of all available term structure configurations under the current legal entity name through the configuration interface. The scheme creator selects one of these as the term structure configuration for the scheme. When saving the scheme, the scheme binding module verifies that the selected term structure identifier is not empty and that the legal entity identifier of the term structure configuration is consistent with the legal entity of the scheme. If the verification fails, the module refuses to save and returns a prompt message.

7. The liquidity risk stress testing system supporting dynamic configuration of maturity structure according to claim 1, characterized in that, The aggregation module evenly refines the cash flow gap values ​​within each term bucket into daily values. Specifically, for the i-th term bucket with a coverage period of d, the total cash flow gap value within that term bucket is divided by d to obtain the average daily cash flow value within that term. After each term bucket is expanded sequentially according to its bucket number, a daily cash flow sequence covering the entire observation window is generated.

8. The liquidity risk stress testing system supporting dynamic configuration of maturity structure according to claim 1, characterized in that, The storage module includes a write unit and a delete unit. When the write unit writes the results to the database, it first writes the main table records in batches within the same transaction, and then writes the sub-table records in batches based on the backfilled primary key. When deleting old data, the delete unit deletes the sub-table records in a cascading manner, prioritizing the main table. It uses the scheme code and data date field of the redundant storage in the sub-table to directly locate the sub-table records.

9. The liquidity risk stress testing system supporting dynamic configuration of maturity structure according to claim 1, characterized in that, The metadata generation module loads the corresponding term structure context based on the scheme code, traverses all term bucket definitions in the context, and generates a column metadata record for each term bucket. The column metadata includes at least the bucket number, display label, and coverage days. The front-end presentation layer dynamically generates table columns through the column metadata-driven loop instruction. The data import template dynamically generates header rows based on column metadata using a runtime document generation library; the data export report dynamically writes cells according to column metadata.

10. A liquidity risk stress testing method supporting dynamic configuration of term structure, characterized in that, The method is implemented based on the system of claim 1, and the method includes the following steps: Step S1: Read the term structure identifier bound to the scheme table, load the corresponding term structure definition and term bucket details according to the term structure identifier, build a term interval index based on a red-black tree in memory, and load the stress scenario configuration and mitigation scenario configuration bound to the scheme. Step S2: Parse the expiration information of the original data and convert it into standardized days. Use the standardized days as the lookup key and match the corresponding expiration bucket using a red-black tree index. Step S3: For each subject, read the churn rate under the corresponding pressure level according to the pressure scenario configuration, calculate the churn amount, and determine the term bucket allocation based on the remaining term information of the subject: for subjects with a clear expiration date, allocate all churn amounts to the unique term bucket matched by the red-black tree index; for subjects without a clear expiration date, allocate according to the preset term structure model. Step S4: Based on the mitigation scenario configuration, read the discount rate and sell-off rate under the corresponding pressure level, calculate the sell-off amount, and execute the same time bucket ownership determination logic as in step S3 based on the remaining maturity characteristics of the mitigation assets. Step S5: Add the allocation results from step S3 and step S4 to the cash flow, and recursively aggregate from bottom to top according to the account hierarchy tree. Step S6: Evenly refine the cash flow gap value in each period bucket into daily values, and incrementally accumulate the daily net cash flow in chronological order. When the end balance of the day is not greater than zero for the first time, record the number of days elapsed as the shortest survival period. Step S7: Store the calculation results in a row storage structure that separates the main table and the time-limited bucket sub-table. Write the main table records in batches within the same transaction, and then write the sub-table records in batches according to the backfilled primary key. Step S8: Dynamically generate column metadata based on the term structure definition to drive front-end display, data import, and data export to dynamically render based on column metadata.

Images