Abstract: Conventionally, credit limits across products maintained in multiple systems are managed manually or using a fixed limit tree structure making it non-fungible, involves high turnaround time and high maintenance cost and entails a high probability of error. The present disclosure effects a functionality to model complex fungible limit tree structure not restricted to any number of levels with dynamic credit limit aggregation and exposure computation with minimal human intervention. The credit limits are initialized such that pre-defined business rules are validated to maintain sanity of the fungible limit tree. A holistic view of linked credit limits, associated counterparties and availed facilities may be generated and is capable of being drilled down to a detailed facility view. [To be published with FIG.2 ]
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See Section 10 and Rule 13)
Title of invention:
FLEXIBLE LIMIT SETUP WITH DYNAMIC CREDIT LIMIT AGGREGATION
AND EXPOSURE COMPUTATION
Applicant
Tata Consultancy Services Limited A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India
Preamble to the description:
The following specification particularly describes the invention and the manner in
which it is to be performed.
TECHNICAL FIELD
[001] The disclosure herein generally relates to setting credit limits, and,
more particularly, to systems and computer implemented methods for effecting flexible credit limit setup with dynamic credit limit aggregation and exposure computation.
BACKGROUND
[002] Currently fungibility or interchangeability of credit limits is not
leveraged in most financial institutions. In such a case, credit limit assigned to a counterparty on a product, if partially utilized, cannot be reallocated. This leads to blocking of capital, which if freed, can be utilized for other investments. Traditionally, credit limits are maintained in multiple systems and fungibility across the systems is handled in an offline mode leading to high maintenance cost, high turnaround time for limit allocations, loss in business opportunities and a high probability of errors.
SUMMARY
[003] Embodiments of the present disclosure present technological
improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems.
[004] In an aspect, there is provided a processor implemented method
comprising the steps of: creating, by one or more hardware processors, a fungible limit tree having at least three levels being a group level, a counterparty level and a leaf level leading to n levels of hierarchy in the fungible limit tree, wherein each of the at least three levels is characterized by one or more nodes and wherein the fungible limit tree is based on a Multi-Option Facility (MOF), credit limits associated with the one or more nodes being fungible and having a cap on maximum utilization; initializing the credit limits for each of the one or more nodes, by the one or more
hardware processors, wherein the initializing starts with the group level and ends with the leaf level and wherein the credit limits are based on one or more facilities at the one or more nodes on the leaf level and an associated counterparty credit limit; and dynamically performing, by the one or more hardware processors, at least one of: computing aggregation of the credit limits at each of the n levels of the hierarchy; and computing an Availability for Apportionment of Sanctioned Limit (AASL) based on the credit limit at each of the nodes in the fungible limit tree to obtain exposure at leaf nodes in the one or more nodes, upon at least one of initializing the credit limits and restructuring of the fungible limit tree at runtime.
[005] In another aspect, there is provided a system comprising: one or more
data storage devices operatively coupled to one or more hardware processors and configured to store instructions configured for execution by the one or more hardware processors to: create a fungible limit tree having at least three levels being a group level, a counterparty level and a leaf level leading to n levels of hierarchy in the fungible limit tree, wherein each of the at least three levels is characterized by one or more nodes and wherein the fungible limit tree is based on a Multi-Option Facility (MOF), credit limits associated with the one or more nodes being fungible and having a cap on maximum utilization; initialize the credit limits for each of the one or more nodes wherein the initializing starts with the group level and ends with the leaf level and wherein the credit limits are based on one or more facilities at the one or more nodes on the leaf level and an associated counterparty credit limit; and dynamically perform at least one of: computing aggregation of the credit limits at each of the n levels of the hierarchy; and computing an Availability for Apportionment of Sanctioned Limit (AASL) by using the credit limit at each of the nodes in the fungible limit tree to obtain exposure at leaf nodes in the one or more nodes, upon at least one of initializing the credit limits and restructuring of the fungible limit tree at runtime.
[006] In yet another aspect, there is provided a computer program product
comprising a non-transitory computer readable medium having a computer readable program embodied therein, wherein the computer readable program, when executed on a computing device, causes the computing device to: create a fungible limit tree having at least three levels being a group level, a counterparty level and a leaf level leading to n levels of hierarchy in the fungible limit tree, wherein each of the at least three levels is characterized by one or more nodes and wherein the fungible limit tree is based on a Multi-Option Facility (MOF), credit limits associated with the one or more nodes being fungible and having a cap on maximum utilization; initialize the credit limits for each of the one or more nodes wherein the initializing starts with the group level and ends with the leaf level and wherein the credit limits are based on one or more facilities at the one or more nodes on the leaf level and an associated counterparty credit limit; and dynamically perform at least one of: computing aggregation of the credit limits at each of the n levels of the hierarchy; and computing an Availability for Apportionment of Sanctioned Limit (AASL) by using the credit limit at each of the nodes in the fungible limit tree to obtain exposure at leaf nodes in the one or more nodes, upon at least one of initializing the credit limits and restructuring of the fungible limit tree at runtime.
[007] In accordance with an embodiment of the present disclosure, the
fungible limit tree comprises one or more families, each of the one or more families being defined by a parent and one or more children in the n levels of hierarchy.
[008] In accordance with an embodiment of the present disclosure, the
restructuring of the fungible limit tree comprises performing at runtime, one or more of (i) modifying the one or more nodes by modifying attributes associated thereof, (ii) vertically expanding the fungible limit tree by adding one or more intermediate levels in the fungible limit tree leading to the n levels of hierarchy, to either cap the credit limit of underlying levels or to group the one or more facilities having identical genres, (iii) horizontally expanding the fungible limit tree by adding one or more
nodes at one or more of the at least three levels, (iv) delinking one or more facilities from the one or more nodes at the leaf level to serve as one or more standalone facilities, (v) linking one or more standalone facilities as one or more nodes at the leaf level of the fungible limit tree and (vi) deleting the one or more nodes in the fungible limit tree.
[009] In accordance with an embodiment of the present disclosure, the step
of initializing the credit limits comprises validating the initialized credit limits using pre-defined business rules to maintain sanity of the fungible limit tree, and wherein the business rules are based on attributes of the one or more facilities.
[010] In accordance with an embodiment of the present disclosure, the one
or more hardware processors are configured to dynamically compute aggregation at each of the n levels by iteratively performing: extracting an initialized credit limit at each of the one or more nodes; summing the credit limit values at each child level in the fungible limit tree; comparing the summed credit limit value at each child level with an associated parent level credit limit value; and identifying a minimum of the compared summed credit limit value at each child level and the associated parent level credit limit value as an aggregated value at the associated parent level.
[011] In accordance with an embodiment of the present disclosure, the
aggregation of the credit limits is converted from the n levels of hierarchy to third level of hierarchy for management summary reporting, and wherein the management summary reporting is either product based or classification based.
[012] In accordance with an embodiment of the present disclosure, the one
or more hardware processors are configured to dynamically compute an Availability for Apportionment of Sanctioned Limit (AASL) based on the credit limit at each of the nodes in the fungible limit tree by: identifying the one or more nodes in the fungible limit tree except the leaf nodes, starting with one or more counterparty nodes in the one or more nodes, as either one or more funded nodes, one or more non-funded nodes or one or more hybrid nodes on the basis of an associated family and an
associated facility; iteratively distributing an apportioned difference at each parent node of the one or more families to an immediate child node in the hierarchy up to the leaf nodes, based on at least one of: an apportioning precedence given to the one or more nodes; and a ratio of the AASL of the child nodes if more than one node exists on the same precedence level, wherein the AASL at each node is a difference between an effective limit at a node and an availed limit; and wherein the effective limit is a minimum of at least one of a sanctioned limit being the credit limit, a loaded limit and a drawing power associated with the node, such that the apportioned difference at any node does not exceed the AASL thereof; the apportioned difference is reduced to the AASL of the node if the AASL is less than the apportioned difference; and remaining difference is apportioned among the one or more nodes with subsequent apportioning precedence; computing an apportioned limit at each of the leaf nodes as a sum of the apportioned difference and outstanding at the node; and obtaining the exposure at each of the leaf nodes as a maximum of the apportioned limit and the outstanding at the node.
[013] In accordance with an embodiment of the present disclosure, the one
or more funded nodes are represented by all leaf nodes in an associated family being funded facilities; the one or more non-funded nodes are represented by all leaf nodes in an associated family being non-funded facilities; and the one or more hybrid nodes are represented by leaf nodes in an associated family being a mix of funded and non-funded facilities.
[014] In accordance with an embodiment of the present disclosure, the
apportioning precedence is given to the nodes in the order of the funded nodes followed by the hybrid nodes and further followed by the non-funded nodes.
[015] It is to be understood that both the foregoing general description and
the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS
[016] The accompanying drawings, which are incorporated in and constitute
a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles.
[017] FIG.1 illustrates an exemplary block diagram of a system for flexible
limit setup with dynamic credit limit aggregation and exposure computation, in accordance with an embodiment of the present disclosure.
[018] FIG.2 illustrates an exemplary flow diagram of a computer
implemented method for flexible limit setup with dynamic credit limit aggregation and exposure computation, in accordance with an embodiment of the present disclosure.
[019] FIG.3 illustrates an exemplary fungible limit tree, in accordance with
an embodiment of the present disclosure.
[020] FIG.4 illustrates another exemplary fungible limit tree, in accordance
with an embodiment of the present disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS
[021] Exemplary embodiments are described with reference to the
accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope and spirit being indicated by the following claims.
[022] Financial institutions service multiple products managed across
multiple systems. Accordingly, credit limits are set for the various products in the multiple systems. Typically interchangeability of limits is not leveraged and when done, it is manual or relies on a template based approach with fixed type of products or employs a fixed limit structure. Integrating the multiple products spread across multiple systems and supporting automatic fungibility of credit limits across the products and counterparties participating under a single limit tree structure is a technical problem addressed in the present disclosure. The various embodiments of the system and method of the present disclosure effect real time integration of the various products such that the credit limits of the different products are analyzed to unblock un-utilized capital for re-use. This ensures increase in revenue generation as the blocked capital is recycled for credit consumption within the same counterparty effectively with minimal manual intervention. In accordance with the present disclosure, the credit limits are made fungible across the limit tree structure, provides a scaling of limit nodes horizontally and vertically along with dynamic aggregation and apportioning calculation.
[023] Referring now to the drawings, and more particularly to FIG.1 through
FIG.4, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary system and/or method.
[024] FIG.1 illustrates an exemplary block diagram of a system 100 for
flexible limit setup with dynamic credit limit aggregation and exposure computation, in accordance with an embodiment of the present disclosure. In an embodiment, the system 100 includes one or more processors 104 being one or more hardware processors or one or more software modules or a combination thereof, communication interface device(s) or input/output (I/O) interface(s) 106, and one or more data storage devices or memory 102 operatively coupled to the one or more
processors 104. The one or more processors 104 can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, graphics controllers, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) are configured to fetch and execute computer-readable instructions stored in the memory. In the context of the present disclosure, the expressions ‘processors’ and ‘hardware processors’ may be used interchangeably. In an embodiment, the system 100 can be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices, workstations, mainframe computers, servers, a network cloud and the like.
[025] The I/O interface(s) 106 can include a variety of software and
hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface(s) can include one or more ports for connecting a number of devices to one another or to another server.
[026] The memory 102 may include any computer-readable medium known
in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, one or more modules (not shown) of the system 100 can be stored in the memory 102.
[027] FIG.2 illustrates an exemplary flow diagram of a computer
implemented method 200 for flexible limit setup with dynamic credit limit aggregation and exposure computation, in accordance with an embodiment of the present disclosure. In an embodiment, the system 100 includes one or more data storage devices or memory 102 operatively coupled to the one or more processors
104 and is configured to store instructions configured for execution of steps of the method 300 by the one or more processors 104. The steps of the method 200 will now be explained in detail with reference to the components of the system 100 of FIG.1. Although process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.
[028] In accordance with an embodiment of the present disclosure, the one
or more processors 104 are configured to create, at step 202, a fungible limit tree having at least three levels being a group level, a counterparty level and a leaf level leading to n levels of hierarchy in the fungible limit tree. Each of the at least three levels is characterized by one or more nodes, wherein the fungible limit tree is based on a Multi-Option Facility (MOF), credit limits associated with the one or more nodes being fungible and having a cap on maximum utilization. The MOF provides multiple types of lending and trade finance options within the fungible limit tree with one overall limit.
[029] In accordance with an embodiment of the present disclosure, the
fungible limit tree structure may be created using one or more user interfaces. In an embodiment, the one or more hardware processors 104 are configured to initialize the credit limits, at step 204, for each of the one or more nodes starting with the group level and ending with the leaf level. The credit limits are based on one or more facilities at the one or more nodes on the leaf level and an associated counterparty credit limit. In the context of the present disclosure, the expressions ‘credit limits’. ‘limits’ and ‘sanctioned limits’ may be used interchangeably. Likewise, ‘facilities’ and ‘credit lines’ may be used interchangeably
[030] Intermediate levels in the n levels of hierarchy are abstract but
indispensable for limit management in a real world scenario. In accordance with an embodiment, the intermediate levels are created to either cap the credit limit of underlying levels or to group the one or more facilities having identical genres. In accordance with the present disclosure, the identical genres may be determined based on business need, for instance products identified under a single sanctioned term or complying to a same sanction term (attributes like period, purpose of loan or credit line, and the like) may be considered as having identical genres.
[031] FIG.3 illustrates an exemplary fungible limit tree with 5 levels of
hierarchy (L1 through L5), in accordance with an embodiment of the present disclosure. The fungible limit tree, as illustrated in FIG.3, is characterized by one or more families, wherein each of the one or more families is defined by a parent and one or more children in the n levels of hierarchy. Each of the one or more families necessarily ends with a leaf node. For instance, the Group node (MOF) in FIG.3 represents a family with the MOF node serving as a parent and all the child nodes illustrated serving as children. Again, the Counterparty node (CP1) represents a family comprising the Intermediate nodes (IN1, IN2, IN11, IN12), the Facility nodes (F1 through F8) as children. Yet again, the Intermediate node (IN11) represents a family comprising the Facility Nodes (F1, F2), and so on.
[032] In accordance with an embodiment of the present disclosure, the step
of initializing the credit limits comprises validatiing the initialized credit limits using pre-defined business rules to maintain sanity of the fungible limit tree. The pre¬defined business rules may be direct rules such as child limit cannot exceed an associated parent limit or maturity of a child node cannot exceed maturity of an associated parent node, and the like. In an embodiment, the pre-defined business rules may be indirect rules that validate whether utilization exceeds a business requirement. For instance, a cap limit may be set for a facility from one family and another facility from another family. In accordance with the present disclosure, the business rules are based on attributes of the one or more facilities such as customer
type, customer identifier, credit limit amount, maturity date, credit risk attributes, credit line being sanctioned for various facilities like funded or non-funded and the like. In an embodiment, each node may be associated with a different set of attributes.
[033] In the fungible limit tree of FIG.3, the MOF node at level 1 is not
captured as a facility. Limited attributes are captured at this level such as amount and date. The Group node is an overall limit node for the fungible limit tree and has only counterparty limit nodes directly under it. The Counterparty nodes CP1, CP2 at level 2 are captured as limits. Validations based on the pre-defined business rules are performed when the level 2 is setup. The limits of the Intermediate nodes IN1, IN2, IN11, IN12, IN3 at level 3 are captured as facilities. Validations based on the pre-defined business rules are performed again with reference to associated parent level when the level 3 is setup. The Intermediate nodes may be created under either a Counterparty node like IN1, IN2 and IN3, or they may be created under an Intermediate node like IN11 and IN12. Limits of the leaf nodes F1 through F11 are also captured as facilities with validations performed based on the pre-defined business rules. The leaf nodes may be created under either a Counterparty node like F8 and F11 or they may be created under an Intermediate node like F1 through F7, F9 and F10. Accounts or drawdowns are attached to the leaf nodes in transaction systems and all transactions are captured at the leaf node level.
[034] In accordance with the present disclosure, the fungible limit tree may
be restructured in real time by various actions. For instance, attributes like the credit limits the maturity date, and the like may be modified. Alternatively, the fungible limit tree may be expanded vertically by adding one or more intermediate levels. Again, the fungible limit tree may be expanded horizontally by adding one or more nodes at one or more of the at least three levels. One or more facilities may be delinked from the one or more nodes at the leaf level to serve as one or more standalone facilities. Alternatively, one or more standalone facilities may be linked to the fungible limit tree as one or more nodes at the leaf level. Again, the one or more
nodes in the fungible limit tree may be deleted, wherein the associated business rules are also deleted along with the deletion of the nodes. In accordance with an embodiment of the present disclosure, the fungible limit tree structure may be restructured using one or more user interfaces.
[035] In an embodiment, the one or more hardware processors 104 are
configured to dynamically perform at least one of computing aggregation of the credit limits at each of the n levels of the hierarchy, at step 206, and computing an Availability for Apportionment of Sanctioned Limit (AASL) based on the credit limit at each of the nodes in the fungible limit tree, at step 208, to obtain exposure at leaf nodes in the one or more nodes. In accordance with the present disclosure the computing of aggregation and the AASL is performed in real time upon at least one of initializing of the credit limits at step 204 and restructuring of the fungible limit tree by any of the actions enumerated above.
[036] Some exemplary scenarios involving restructuring of the fungible
limit tree, thereby triggering a need for dynamically computing aggregation or AASL are shown below.
Scenario Description Business Inference
Creation of a new Facility and BANK without giving new limit to the
Intermediate Node under Borrower’s extending a new means to
Counterparty Node of existing utilize the available limit i.e. new
Scenario 1 Limit tree structure. product has been granted to the borrower to utilize the already existing limit. Also intermediate cap has been set up for the limits to be used against the product.
Creation of separate branch of BANK is allowing the relocation of
Scenario 2 different counterparty in the available limit to the new borrower
same limit tree structure i.e. which has been made the part of the
extending the tree structure Limit structure.
horizontally.
Creation of new product branch Similar to the Scenario 1 BANK is
Scenario 3 (say, Intermediate node and a facility) under a Counterparty granting new product, from different product group, to the Borrower to
Node utilize the existing limit available.
Extending an intermediate node Similar to the Scenario 3 BANK is
vertically by adding another granting new product to the Borrower
Scenario 4 intermediate node and leaf node below it to utilize the existing limit available on Borrower, but with an intermediate cap against limit utilization against the product.
[037] In accordance with the present disclosure, the Scenario 1 mentioned
above may be further discussed by way of an example for a single borrower showing vertical scalability. Multiple borrowers may be added to the fungible limit tree structure horizontally from its credit hierarchy where limits sanctioned to this borrower can be used by its own products. Say, a total credit limit of 100 Crore (also referred as 100 Cr) is sanctioned to a borrower. This amount is fully fungible between funded and non- funded products. The funded and non-funded limits are further divided into their products Cash Credit (CC), Working Capital Loan (WCL), Bill Discounting Debt and Letter of Credit (LC) products respectively. This business requirement is captured by the system and method of the present disclosure as follows.
- At Product Classification Level: A cap limit of 100 Cr for Fund Based and 100 Cr for Non Fund Based products have been sanctioned.
- At Product Level: Limit against Product CC and LC can be maximum up to 100 Cr each. The cap limit defined at this level can be further used by its sub products.
- At Sub Product Level: Limit for each sub product (Sub Product CC - Stock,
CC - Book, WCDL, Bill Discounting Debt, Sight LC) can be maximum up to
100 Cr and 80 Cr for Usance LC.
Although the aggregation of limits sanctioned to the leaf nodes is 600Cr (100(CC -
Stock) +100 (CC - Book) +100 (WCDL) +100 (Bill Discounting Debt) +100 (Sight
LC) +100 (Usance LC)) but actual limit available to borrower is 100 Cr.
[038] In an embodiment of the present disclosure, the step of dynamically
computing aggregation at each of the n levels comprises firstly iteratively extracting an initialized credit limit at each of the one or more nodes. The credit limits at each child level in the fungible limit tree are then summed. The summed credit limit value at each child level is compared with an associated parent level credit limit value to identify a minimum of the compared values as an aggregated value at the associated parent level. The computing of the aggregation at each of n levels is further explained with reference to the fungible limit tree of FIG.3.
[039] The fungible limit tree of FIG.3 is listed below to the nth level of
hierarchy.
Node Product Classification Node Type Level MOF Hierarchy Limit (in Millions)
MOF MOF 1 MOF 10
CP1 Counterparty 2 MOF/CP1 8
IN1 Intermediate Node 3 MOF/CP1/IN1 7
IN11 Intermediate Node 4 MOF/CP1/IN1/IN11 4
F1 Term Loan Lending Facility 5 MOF/CP1/IN1/IN11/ F1 3
F2 Letter of Credit Contingent Facility 5 MOF/CP1/IN1/IN11/ F2 2
IN12 Intermediate 4 MOF/CP1/IN1/IN12 5
Node
F3 Term Loan Lending Facility 5 MOF/CP1/IN1/IN12/ F3 1
F4 Term Loan Lending Facility 5 MOF/CP1/IN1/IN12/ F4 2
F5 Bank
Guarant
ee Contingent Facility 4 MOF/CP1/IN1/F5 1
IN2 Intermediate Node 3 MOF/CP1/IN2 6
F6 Letter of Credit Contingent Facility 4 MOF/CP1/IN2/F6 2
F7 Bank
Guarant
ee Contingent Facility 4 MOF/CP1/IN2/F7 1
F8 Term Loan Lending Facility 3 MOF/CP1/F8 1
CP2 Counterparty 2 MOF/CP2 5
IN3 Intermediate Node 3 MOF/CP2/IN3 5
F9 Term Loan Lending Facility 4 MOF/CP2/IN3/F9 1
F10 Bank
Guarant
ee Contingent Facility 4 MOF/CP2/IN3/F10 3
F11 Cash Credit Lending Facility 3 MOF/CP2/F11 2
[040] The child level (same level) limit values are summed and compared
with parent level limit value to identify the minimum of both as the aggregated value as shown below.
Product Facility Node Counterparty Level4 Aggregation Level3 Aggregation 6+1 = 7
1
2+2 = 4
1+1 = 2
3 2
Term Loan F1 (3) IN11 (4) IN1 (7) CP1 (8) MIN(F1,IN11) = 3 MIN(6,IN1) = 6
F3 (1) F4 (2) IN12 (5) IN1 (7)
MIN(SUM(F3+F4),IN1 2) = 3
F8 (1)
F8 = 1
F9 (1) IN3 (5) CP2 (5) MIN(F9,IN3) = 1
Letter of Credit F2 (2) IN11 (4) IN1 (7) CP1 (8) MIN(F2,IN11) = 2 MIN(2,IN1) = 2
F6 (2) IN2 (6)
MIN(F6,IN2) = 2
Bank Guarantee F5 (1) IN1 (7) CP1 (8) MIN(F5,IN1) = 1
F7 (1) IN2 (6)
MIN(F7,IN2) = 1
F10 (3) IN3 (5) CP2 (5) MIN(F10,IN3) = 3
Cash Credit F11 (2) CP2 (5) 2
The fungible limit tree of the present disclosure allows a structure up to nth level hierarchy. However, in accordance with an embodiment, the aggregation of the credit limits is converted from the n levels of hierarchy to third level of hierarchy for management summary reporting. At runtime when displaying limits on Management Summary and Product Group Overview (PGO) screens, the third level hierarchy aggregation is used with Counterparty and Group limits to derive and display values of limits for a customer. The third level hierarchy aggregation is stored for Product or Classification (grouping of products) based reporting. The benefit of this approach is that aggregation for all (n) levels hierarchy is not required to be performed on the fly when there is a requirement for displaying limits on the Management Summary or PGO screens and thereby improving runtime performance of the system of the present disclosure.
[041] A third level product based reporting after the third level aggregation,
in accordance with the present disclosure, is shown below.
Node Node Type Modified Hierarchy (Product) Limit (in Millions)
MOF MOF MOF 10
CP1 Counterparty MOF/CP1 8
Term Loan Product MOF/CP1/Term Loan 7
Letter of Credit Product MOF/CP1/Letter of Credit 4
Bank Guarantee Product MOF/CP1/Bank Guarantee 2
CP2 Counterparty MOF/CP2 5
Term Loan Product MOF/CP2/Term Loan 1
Bank Guarantee Product MOF/CP2/Bank Guarantee 3
Cash Credit Product MOF/CP2/Cash Credit 2
[042] A third level classification based reporting after the third level
aggregation, in accordance with the present disclosure, is shown below.
Classification Facility Node Counterparty Level4 Aggregation Level3 Aggregation 6+1 = 7
1+2 = 3
2+1+ 3 = 6
3
Lending F1(3) IN11(4) IN1(7) CP1(8) MIN(F1,IN11) = 3 MIN(6,IN1) = 6
F3(1) F4(2) IN12(5) IN1(7)
MIN(SUM(F3+F4), IN12) = 3
F8(1)
1
F9(1) IN3(5) CP2(5) MIN(F9,IN3) = 1
F11(2)
2
Contingent F2(2) IN11(4) IN1(7) CP1(8) MIN(F2,IN11) = 2 MIN(2,IN1) = 2
F5(1) IN1(7)
MIN(F5,IN1) = 1
F6(2) F7(1) IN2(6)
MIN(SUM(F6+F7),I N2) = 3
F10(3) IN3(5) CP2(5) MIN(F10,IN3) = 3
Node Node Type Modified Hierarchy (Classification) Limit (in Millions)
MOF MOF MOF 10
CP1 Counterparty MOF/CP1 8
Lending Classification MOF/CP1/Lending 7
Contingent Classification MOF/CP1/Contingent 6
CP2 Counterparty MOF/CP2 5
Lending Classification MOF/CP2/Lending 3
Contingent Classification MOF/CP2/Contingent 3
[043] To efficiently utilize capital and to provide flexibility to the customer
for utilizing limits based on the customer’s need, fungible limits are sanctioned to the customer with a total cap. In accordance with the present disclosure, such a structure is referred as the limit tree structure which indicates fungibility between different
limits and a cap on maximum utilization. FIG.4 illustrates another exemplary fungible limit tree, in accordance with an embodiment of the present disclosure. The leaf level limits are actually availed by the customer, provided the cap set at the parent level is not breached. This means the actual limits available to the customer (as shown in FIG.4) is not a linear summation of F6, F7, F8, F9, F12 and F13 which would be 580 Million in turn violating the counterparty level limit which is capped at 100 Million. Hence at leaf level, the actual limits available to the customer are lesser than their specified leaf-level limit nodes. While aggregation is based on the sanctioned limits at each node, the apportioned limit is that notional limit that is available at leaf level node which is actually being availed by the customer assuming multiple conditions for evaluating apportioned limit at leaf nodes as described hereinafter.
[044] Apportioned limits are only notional limits and may keep on changing
based on the structure of the fungible limit tree and the outstanding at any point of time. Apportioned limits may be used for reporting apportioned limits in a financial institution through say Bank entity wise exposure screens and reports where data is consolidated on parameters which are captured at facility level like Bank entity. Apportioned limits may not be pushed to any other system and there may not be any processing on the apportioned limits.
[045] In accordance with the present disclosure, a nested logic is provided
that checks the pre-defined business rules based validations and then computes the apportioned sanction or loaded limits from the computed sanctioned or loaded limits at the facility level. The computed sanctioned or loaded limit includes main limit with any ad hoc or intraday or seasonal limit that may have been defined at a particular node. The apportioning happens for each node from top to bottom. System apportions the limit for each node and then incrementally progresses one level down to compute apportioned limits for the leaf level.
[046] In accordance with an embodiment of the present disclosure, the step
of dynamically computing the AASL based on the credit limit at each of the nodes in the fungible tree is an iterative process starting with one or more counterparty nodes in the one or more nodes and is performed level by level from top to bottom of the fungible limit tree. The step of computing the AASL comprises firstly identifying one or more nodes in the fungible limit tree except the leaf nodes, starting with the one or more counterparty nodes in the one or more nodes, as either one or more funded nodes, one or more non-funded nodes or one or more hybrid nodes on the basis of an associated family and an associated facility. In accordance with the present disclosure, the one or more funded nodes are represented by all leaf nodes in an associated family being funded facilities; the one or more non-funded nodes are represented by all leaf nodes in an associated family being non-funded facilities; and the one or more hybrid nodes are represented by leaf nodes in an associated family being a mix of funded and non-funded facilities.
[047] In accordance with an embodiment, the step of dynamically computing
the AASL further comprises iteratively distributing an apportioned difference (or a difference to be apportioned) at each parent node of the one or more families to an immediate child node in the hierarchy up to the leaf nodes.
[048] In accordance with an embodiment of the present disclosure, the
iterative distributing of the apportioned difference is based on at least one of an apportioning precedence given to the one or more nodes and a ratio of the AASL of the child nodes, if more than one node exists on the same precedence level. In an embodiment, the apportioning precedence is given to the nodes in the order of the one or more funded nodes followed by the one or more hybrid nodes and further followed by the one or more non-funded nodes. In accordance with the present disclosure, the AASL at each node is a difference between an effective limit at a node and the availed limit and the effective limit is a minimum of the sanctioned limit, wherein the sanctioned limit may be at least one of the credit limit, the loaded limit and a drawing power associated with the node.
[049] In accordance with the present disclosure the distributing of the
apportioned difference is performed such that the apportioned difference at any node does not exceed the associated AASL; the apportioned difference is reduced to the AASL of the node if the AASL is less than the apportioned difference; and remaining difference is apportioned among the one or more nodes with subsequent apportioning precedence.
[050] Once the iterative distribution of the apportioned difference is
completed up to the leaf level, in accordance with the present disclosure, an apportioned limit is computed at each of the leaf nodes as a sum of the apportioned difference and outstanding at the node. Further, a maximum of the apportioned limit and the outstanding at the node is obtained as the exposure at each of the leaf nodes.
[051] The computing of the apportioned limits and the exposures is further
explained with reference to the fungible limit tree of FIG.4 and wherein the sanctioned limit is the credit limit. The facilities at various levels in the fungible limit tree of FIG.4 are as listed below.
Facility ID Parent facility Struct Loan Type Product Limit Availed Limit Outstanding Apportioned Diff Apportioned Limit Exposure
F1 ure
Limit
CP Revol 100 85 85 15
F2 F1 Limit Funde ving 100 85 85 15
Revol
F3 F2 d Cap Limit ving 100 55 55 15
Produ
F4 F3 ct Level
Cap Limit Revol ving CC Product 100 45 45 6.11 1.92
F6 F4 Actual
Facilit
y Revol ving CC Stock -
Sub Product 100 20 20
21.92 21.92
CC
F7 F4 Actual
Facilit
y Revol ving Book
Debt -
Sub
Product
Limit 100 10 10 2.16 12.16 12.16
WCDL
F8 F4 Actual
Facilit
y Revol ving ( All) -
Sub
Product
Limit 100 15 15 2.03 17.03 17.03
Produ Bill
ct Non Discou
F5 F3 Level
Cap Limit Revol ving nting -
Product
Limit 100 20 10 8.88
Bill
Actual Non Discou
F9 F5 Facilit y Revol ving nting (
All ) -
Sub 100 20 10 8.88 18.88 18.88
Product Limit
Non -
F10 F2 Funde d Cap Limit Revol ving 100 30 30 0
Produ
F11 F10 ct Level
Cap Limit Revol ving LC 100 30 30 0
0 0
F12 F11 Actual
Facilit
y Revol ving Sight LC 100 10 10
10 10
F13 F11 Actual
Facilit
y Revol ving Usance LC 80 20 20
20 20
Total
100.0 100.0
In the table above, the abbreviations used are as follows:
CC=Cash Credit
WLC=Working Capital Loan
LC=Letter of Credit
CP=Counterparty
O/S=Outstanding
ned e at CP
CP
Level Appo Differ
F6
Level Appo Differ
rtioned Level 5
Appo Limit
20 +
Node (AV AD = 1.92=
Limit: = 80) 6.11*(80/(80+85 20 21.92
100 F3 F4 =
100-20 +90))=1.92
CP
(AV F7 10 +
(AV = AD=
Node : 45) = 15*(55/(80 (AV AD = 2.16=1
A = 85 Funded (AD =15) 55) =10 0-45 +55))=6.11 =
90)=
100- 6.11*(90/(80+85 +90))=2.16 10 2.16
AD: 10
(100 – Funded F8 AD = 15 +
85) = would be (AV 6.11*(85/(80+85 15 2.03=1
15 given preferenc = 85) +90))=2.03 7.03
e) F5 10 +
(AV 8.88=1
= AD = F9 8.88
80) =
100-20 F11 15*(80/(80 +55))=8.88 (AV = 80)
F12 AD = 8.88 10
Non F10
10
Funded Family (AV = 70) (AD (AV = (AV = 0 0+10=
= 0) 70) (AD 90) 10
F13 0+20=
=0) (AV = 60) 20 20
In the table above, the abbreviations used are as follows:
A=Availed limit
AV=Available limit
AD=Apportioned difference
O=Outstanding
E=Exposure
AL=Apportioned limit
[052] As per the traditional method of handling credit limits, complex
structures are manually handled or handled using a system having a fixed limit structure. Most of the existing systems don't have the flexibility to setup complex limit structures as it is in the system. Some systems allow setting up fungible limit trees, but through very cumbersome processes and are template based. Fixed limit structure can be created up to a pre-defined level in the system. To extend the structure further requires reconfiguration or introduction of a separate structure in the system, wherein the user can create complex limit structure up to nth level. In accordance with the present disclosure, the fungible limit tree is not restricted to any level, and does not require any configuration change at the back end for modifications made to the limit tree structure. Also method and system of the present disclosure support automatic fungibility of limits across products and counterparties participating in the limit structure, which ensures minimal manual intervention and better turnaround time. The system and method of the present disclosure facilitate real time restructuring of the fungible limit tree that aligns to pre-defined business rules and system validations.
[053] Traditionally a bank has to manually obtain data at a periodic
frequency from associated product processors. The data has to be validated manually. This is a time consuming process and leads to a gap in the system since the limits may change on a daily basis. There may be complex tree structures or complex scenarios, for instance, when the limit is captured in the system but becomes effective after a certain time or gets expired after a certain period which cannot be accurately and reliably checked in a manual process. Also, manually consolidated data is prone to errors which may lead to inaccurate information for credit risk analysis resulting in a gap between actual and reported data. Such scenarios are effectively addressed by the system and method of the present invention in real time. Traditionally, there is no single system capable of capturing multiple products and further processing information in real time with accuracy and reliability. In accordance with the present disclosure, once the fungible limit tree is setup and authorized, the aggregation and apportioning are performed dynamically every time there is a restructuring of the tree structure. Again storing of aggregation at the third level of hierarchy improves performance of on-the-fly management summary reporting. Thus setting up of the fungible limit tree structure and the mathematical concepts of computing aggregation and AASL disclosed in the description of the method of the present disclosure are integrated into a practical application of leveraging fungibility of limits and effective utilization of un-utilized capital.
[054] The written description describes the subject matter herein to enable
any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined by the claims and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the claims if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language of the claims.
[055] It is to be understood that the scope of the protection is extended to
such a program and in addition to a computer-readable means having a message
therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[056] The embodiments herein can comprise hardware and software
elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[057] The illustrated steps are set out to explain the exemplary embodiments
shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as
the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[058] Furthermore, one or more computer-readable storage media may be
utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[059] It is intended that the disclosure and examples be considered as
exemplary only, with a true scope and spirit of disclosed embodiments being indicated by the following claims.
WE CLAIM:
1. A processor implemented method (200), the method comprising the steps of:
creating, by one or more hardware processors, a fungible limit tree having at least three levels being a group level, a counterparty level and a leaf level leading to n levels of hierarchy in the fungible limit tree, wherein each of the at least three levels is characterized by one or more nodes and wherein the fungible limit tree is based on a Multi-Option Facility (MOF), credit limits associated with the one or more nodes being fungible and having a cap on maximum utilization (202);
initializing the credit limits for each of the one or more nodes, by the one or more hardware processors, wherein the initializing starts with the group level and ends with the leaf level and wherein the credit limits are based on one or more facilities at the one or more nodes on the leaf level and an associated counterparty credit limit (204); and
dynamically performing, by the one or more hardware processors, at least one of:
computing aggregation of the credit limits at each of the n levels of the hierarchy (206); and
computing an Availability for Apportionment of Sanctioned
Limit (AASL) based on the credit limit at each of the nodes in the
fungible limit tree (208) to obtain exposure at leaf nodes in the one or
more nodes,
upon at least one of initializing the credit limits and restructuring of the
fungible limit tree at runtime.
2. The processor implemented method of claim 1, wherein the fungible limit tree comprises one or more families, each of the one or more families being defined by a parent and one or more children in the n levels of hierarchy.
3. The processor implemented method of claim 2, wherein the restructuring of the fungible limit tree comprises performing at runtime, one or more of (i) modifying the one or more nodes by modifying attributes associated thereof, (ii) vertically expanding the fungible limit tree by adding one or more intermediate levels in the fungible limit tree leading to the n levels of hierarchy, to either cap the credit limit of underlying levels or to group the one or more facilities having identical genres, (iii) horizontally expanding the fungible limit tree by adding one or more nodes at one or more of the at least three levels, (iv) delinking one or more facilities from the one or more nodes at the leaf level to serve as one or more standalone facilities, (v) linking one or more standalone facilities as one or more nodes at the leaf level of the fungible limit tree and (vi) deleting the one or more nodes in the fungible limit tree.
4. The process implemented method of claim 1, wherein the step of initializing the credit limits comprises validating the initialized credit limits using pre-defined business rules to maintain sanity of the fungible limit tree, and wherein the business rules are based on attributes of the one or more facilities.
5. The processor implemented method of claim 2, wherein the step of dynamically computing aggregation at each of the n levels comprises iteratively performing:
extracting an initialized credit limit at each of the one or more nodes;
summing the credit limit values at each child level in the fungible limit tree;
comparing the summed credit limit value at each child level with an associated parent level credit limit value; and
identifying a minimum of the compared summed credit limit value at each child level and the associated parent level credit limit value as an aggregated value at the associated parent level.
6. The processor implemented method of claim 5, wherein the aggregation of the credit limits is converted from the n levels of hierarchy to third level of hierarchy for management summary reporting, and wherein the management summary reporting is either product based or classification based.
7. The processor implemented method of claim 2, wherein the step of dynamically computing an Availability for Apportionment of Sanctioned Limit (AASL) based on the credit limit at each of the nodes in the fungible limit tree comprises:
identifying the one or more nodes in the fungible limit tree except the leaf nodes, starting with one or more counterparty nodes in the one or more nodes, as either one or more funded nodes, one or more non-funded nodes or one or more hybrid nodes on the basis of an associated family and an associated facility;
iteratively distributing an apportioned difference at each parent node of the one or more families to an immediate child node in the hierarchy up to the leaf nodes, based on at least one of:
an apportioning precedence given to the one or more nodes; and
a ratio of the AASL of the child nodes if more than one node exists on the same precedence level, wherein the AASL at each node is a difference between an effective limit at a node and an availed limit; and wherein the effective limit is a minimum of a
sanctioned limit being at least one of the credit limit, a loaded limit and a drawing power associated with the node,
such that the apportioned difference at any node does not exceed the AASL thereof; the apportioned difference is reduced to the AASL of the node if the AASL is less than the apportioned difference; and remaining difference is apportioned among the one or more nodes with subsequent apportioning precedence;
computing an apportioned limit at each of the leaf nodes as a sum of the apportioned difference and outstanding at the node; and
obtaining the exposure at each of the leaf nodes as a maximum of the apportioned limit and the outstanding at the node.
8. The processor implemented method of claim 7, wherein the one or more funded nodes are represented by all leaf nodes in an associated family being funded facilities; the one or more non-funded nodes are represented by all leaf nodes in an associated family being non-funded facilities; and the one or more hybrid nodes are represented by leaf nodes in an associated family being a mix of funded and non-funded facilities.
9. The processor implemented method of claim 7, wherein the apportioning precedence is given to the one or more nodes in the order of the one or more funded nodes followed by the one or more hybrid nodes and further followed by the one or more non-funded nodes.
10. A system (100) comprising: one or more data storage devices (102) operatively coupled to one or more hardware processors (104) and configured to store instructions configured for execution by the one or more hardware processors to:
create a fungible limit tree having at least three levels being a group level, a counterparty level and a leaf level leading to n levels of hierarchy in the fungible limit tree, wherein each of the at least three levels is characterized by one or more nodes and wherein the fungible limit tree is based on a Multi-Option Facility (MOF), credit limits associated with the one or more nodes being fungible and having a cap on maximum utilization;
initialize the credit limits for each of the one or more nodes wherein the initializing starts with the group level and ends with the leaf level and wherein the credit limits are based on one or more facilities at the one or more nodes on the leaf level and an associated counterparty credit limit; and dynamically perform at least one of:
computing aggregation of the credit limits at each of the n levels of the hierarchy; and
computing an Availability for Apportionment of Sanctioned
Limit (AASL) by using the credit limit at each of the nodes in the
fungible limit tree to obtain exposure at leaf nodes in the one or
more nodes,
upon at least one of initializing the credit limits and restructuring of the
fungible limit tree at runtime.
11. The system of claim 10, wherein the fungible limit tree comprises one or more families, each of the one or more families being defined by a parent and one or more children in the n levels of hierarchy.
12. The system of claim 11, wherein the restructuring of the fungible limit tree comprises performing at runtime, one or more of (i) modifying the one or more nodes by modifying attributes associated thereof, (ii) vertically expanding the fungible limit tree by adding one or more intermediate levels in the fungible
limit tree leading to the n levels of hierarchy, to either cap the credit limit of underlying levels or to group the one or more facilities having identical genres, (iii) horizontally expanding the fungible limit tree by adding one or more nodes at one or more of the at least three levels, (iv) delinking one or more facilities from the one or more nodes at the leaf level to serve as one or more standalone facilities, (v) linking one or more standalone facilities as one or more nodes at the leaf level of the fungible limit tree and (vi) deleting the one or more nodes in the fungible limit tree.
13. The system of claim 10, wherein the one or more hardware processors are further configured to validate the initialized credit limits using pre-defined business rules to maintain sanity of the fungible limit tree, wherein the business rules are based on attributes of the one or more facilities.
14. The system of claim 11, wherein the one or more hardware processors are further configured to dynamically compute aggregation at each of the n levels by iteratively performing:
extracting an initialized credit limit at each of the one or more nodes;
summing the credit limit values at each child level in the fungible limit tree;
comparing the summed credit limit value at each child level with an associated parent level credit limit value; and
identifying a minimum of the compared summed credit limit value at each child level and the associated parent level credit limit value as an aggregated value at the associated parent level.
15. The system of claim 14, wherein the one or more hardware processors are
further configured to convert aggregation of the credit limits from the n levels
of hierarchy to third level of hierarchy for management summary reporting,
wherein the management summary reporting is either product based or classification based.
16. The system of claim 11, wherein the one or more hardware processors are further configured to dynamically compute an Availability for Apportionment of Sanctioned Limit (AASL) based on the credit limit at each of the nodes in the fungible limit tree by:
identifying the one or more nodes in the fungible limit tree except the leaf nodes, starting with one or more counterparty nodes in the one or more nodes, as either one or more funded nodes, one or more non-funded nodes or one or more hybrid nodes on the basis of an associated family and an associated facility;
iteratively distributing an apportioned difference at each parent node of the one or more families to an immediate child node in the hierarchy up to the leaf nodes, based on at least one of:
an apportioning precedence given to the one or more nodes; and
a ratio of the AASL of the child nodes if more than one node
exists on the same precedence level, wherein the AASL at each
node is a difference between an effective limit at a node and an
availed limit; and wherein the effective limit is a minimum of at
least one of a sanctioned limit being the credit limit, a loaded limit
and a drawing power associated with the node,
such that the apportioned difference at any node does not exceed the
AASL thereof; the apportioned difference is reduced to the AASL of the node if
the AASL is less than the apportioned difference; and remaining difference is
apportioned among the one or more nodes with subsequent apportioning
precedence;
computing an apportioned limit at each of the leaf nodes as a sum of the apportioned difference and outstanding at the node; and
obtaining the exposure at each of the leaf nodes as a maximum of the apportioned limit and the outstanding at the node.
17. The system of claim 16, wherein the one or more funded nodes are represented by all leaf nodes in an associated family being funded facilities; the one or more non-funded nodes are represented by all leaf nodes in an associated family being non-funded facilities; and the one or more hybrid nodes are represented by leaf nodes in an associated family being a mix of funded and non-funded facilities.
18. The system of claim 16, wherein the one or more hardware processors are further configured to give the apportioning precedence to the nodes in the order of the one or more funded nodes followed by the one or more hybrid nodes and further followed by the one or more non-funded nodes.
| Section | Controller | Decision Date |
|---|---|---|
| # | Name | Date |
|---|---|---|
| 1 | 201921012443-Correspondence to notify the Controller [18-11-2024(online)].pdf | 2024-11-18 |
| 1 | 201921012443-STATEMENT OF UNDERTAKING (FORM 3) [29-03-2019(online)].pdf | 2019-03-29 |
| 2 | 201921012443-RELEVANT DOCUMENTS [18-11-2024(online)].pdf | 2024-11-18 |
| 2 | 201921012443-REQUEST FOR EXAMINATION (FORM-18) [29-03-2019(online)].pdf | 2019-03-29 |
| 3 | 201921012443-US(14)-HearingNotice-(HearingDate-21-11-2024).pdf | 2024-10-24 |
| 3 | 201921012443-FORM 18 [29-03-2019(online)].pdf | 2019-03-29 |
| 4 | 201921012443-FORM 1 [29-03-2019(online)].pdf | 2019-03-29 |
| 4 | 201921012443-FER.pdf | 2021-10-19 |
| 5 | 201921012443-FIGURE OF ABSTRACT [29-03-2019(online)].jpg | 2019-03-29 |
| 5 | 201921012443-CLAIMS [16-08-2021(online)].pdf | 2021-08-16 |
| 6 | 201921012443-DRAWINGS [29-03-2019(online)].pdf | 2019-03-29 |
| 6 | 201921012443-COMPLETE SPECIFICATION [16-08-2021(online)].pdf | 2021-08-16 |
| 7 | 201921012443-DRAWING [16-08-2021(online)].pdf | 2021-08-16 |
| 7 | 201921012443-DECLARATION OF INVENTORSHIP (FORM 5) [29-03-2019(online)].pdf | 2019-03-29 |
| 8 | 201921012443-FER_SER_REPLY [16-08-2021(online)].pdf | 2021-08-16 |
| 8 | 201921012443-COMPLETE SPECIFICATION [29-03-2019(online)].pdf | 2019-03-29 |
| 9 | 201921012443-OTHERS-180419.pdf | 2019-08-20 |
| 9 | 201921012443-Proof of Right (MANDATORY) [16-04-2019(online)].pdf | 2019-04-16 |
| 10 | 201921012443- ORIGINAL UR 6(1A) FORM 26-280619.pdf | 2019-07-12 |
| 10 | 201921012443-FORM-26 [26-06-2019(online)].pdf | 2019-06-26 |
| 11 | Abstract1.jpg | 2019-06-29 |
| 12 | 201921012443- ORIGINAL UR 6(1A) FORM 26-280619.pdf | 2019-07-12 |
| 12 | 201921012443-FORM-26 [26-06-2019(online)].pdf | 2019-06-26 |
| 13 | 201921012443-OTHERS-180419.pdf | 2019-08-20 |
| 13 | 201921012443-Proof of Right (MANDATORY) [16-04-2019(online)].pdf | 2019-04-16 |
| 14 | 201921012443-COMPLETE SPECIFICATION [29-03-2019(online)].pdf | 2019-03-29 |
| 14 | 201921012443-FER_SER_REPLY [16-08-2021(online)].pdf | 2021-08-16 |
| 15 | 201921012443-DECLARATION OF INVENTORSHIP (FORM 5) [29-03-2019(online)].pdf | 2019-03-29 |
| 15 | 201921012443-DRAWING [16-08-2021(online)].pdf | 2021-08-16 |
| 16 | 201921012443-COMPLETE SPECIFICATION [16-08-2021(online)].pdf | 2021-08-16 |
| 16 | 201921012443-DRAWINGS [29-03-2019(online)].pdf | 2019-03-29 |
| 17 | 201921012443-CLAIMS [16-08-2021(online)].pdf | 2021-08-16 |
| 17 | 201921012443-FIGURE OF ABSTRACT [29-03-2019(online)].jpg | 2019-03-29 |
| 18 | 201921012443-FER.pdf | 2021-10-19 |
| 18 | 201921012443-FORM 1 [29-03-2019(online)].pdf | 2019-03-29 |
| 19 | 201921012443-US(14)-HearingNotice-(HearingDate-21-11-2024).pdf | 2024-10-24 |
| 19 | 201921012443-FORM 18 [29-03-2019(online)].pdf | 2019-03-29 |
| 20 | 201921012443-REQUEST FOR EXAMINATION (FORM-18) [29-03-2019(online)].pdf | 2019-03-29 |
| 20 | 201921012443-RELEVANT DOCUMENTS [18-11-2024(online)].pdf | 2024-11-18 |
| 21 | 201921012443-STATEMENT OF UNDERTAKING (FORM 3) [29-03-2019(online)].pdf | 2019-03-29 |
| 21 | 201921012443-Correspondence to notify the Controller [18-11-2024(online)].pdf | 2024-11-18 |
| 1 | 2021-03-0317-07-28E_04-03-2021.pdf |