WO2025091027A1 - Collateral management - Google Patents

Abstract

Techniques, performed by a computing system, for performing collateral optimization are provided. A method includes: (a) displaying, to a user, an initial allocation of assets into source and use categories; (b) receiving a plurality of objectives; (c) operating an MILP taking the plurality of objectives, a plurality of constraints, and the initial allocation of assets as inputs, the MILP being configured to generate an optimized allocation of assets in place of the initial allocation of assets by optimizing the plurality of objectives in view of the plurality of constraints in a concurrent manner; (d) generating a list of actions to transform the initial allocation into the optimized allocation; (e) displaying the list of actions to the user; and (f) in response to the user executing one or more of the actions of the list of actions, creating and displaying to the user an updated allocation of assets in real-time.

Description

COLLATERAL MANAGEMENT

CROSS REFERENCE TO RELATED APPLICATIONS

This Application claims priority to U.S. Provisional Patent Application No. 63/593,796 filed on October 27, 2023, entitled, “COLLATERAL MANAGEMENT”, the contents and teachings of which are hereby incorporated by reference in their entirety.

BACKGROUND

A collateral management process may be performed in the securities financing business as well as other related industries. One objective is to allocate assets efficiently to cover margin exposures across multiple counterparties whilst adhering to various constraints from counterparties' agreements and user specific preferences. These constraints may include, for example, diversifying collateral across asset types with maximum limits for each type and setting individual security limits to reduce idiosyncratic risk. In addition, assets can be transformed to meet eligibility requirements or generate additional revenue, both in the context of downgrades or other securities financing opportunities.

The existing work on collateral management frameworks focuses mainly on margin optimization. Various solutions achieve results by focusing on a simplified version of the problem, featuring limited constraints and a single objective, e.g., cheapest to deliver. Many current solutions handle the problem through a step-by-step, iterative approach, solving individual optimization problems sequentially and using the output from one step as input for the next.

SUMMARY

Unfortunately, the above-described approaches suffer from deficiencies. One way to implement such a solution might include using a generic framework based on an integer linear program that includes concentration limits on asset types and individual securities as constraints. While some models are tested with hypothetical datasets, they lack real collateral position data, thus making them difficult to implement in a production environment. Despite limitations, this approach allows for simulating various scenarios not observed in real data, making it useful for stress-testing and sensitivity analysis, but not as a production solution for the optimal management of collateral.

Thus, it would be desirable to implement collateral management in a manner that captures all possible states of the world, including facilitating trade-offs between different objectives, leading to a more robust and comprehensive solution for collateral management optimization. This may be accomplished by maximizing a multiple objective function and considering various constraints concurrently to capture all possible states of the world. This solution avoids the limitations of sequential approaches by generating a comprehensive action set, encompassing all possible uses of individual securities based on eligibility criteria. No other one factor approach can provide such insights. Even if other tools may be able to look at more than one objective, they cannot calculate trade-offs or opportunity costs based on an iterative/step-by step process where the output of an objective is a given meaning that becomes an input to the next problem/objective.

Embodiments of the present disclosure offer an analytical approach to solving the collateral management problem. It can be applied in both one-time optimization scenarios (where no prior exposure to counterparties exists) and ongoing posting and recalling situations due to mark-to-market and daily transactions. A technique efficiently manages collateral requirements, including initial margin for newly initiated transactions and variation margin to adjust for changes in collateral value over time.

This approach serves as a comprehensive collateral management framework within the securities financing business. It optimizes asset allocation to meet collateral obligations while maximizing asset liquidity, minimizing cost, and maximizing revenue opportunities. Cost-effectiveness is a consideration, and the approach identifies the cheapest securities for delivery, optimal collateral transformations (upgrades, downgrades), and funding opportunities to avoid having idle assets in inventory. This approach of solving all constraints concurrently is unique in its methodology. The complexity increases exponentially, taking multiple problem sets, including trade-offs/interdependencies, in a holistic manner into consideration; this cannot be done by a human.

The approach’s versatility allows it to address various collateral management-related problems based on different inputs and objectives. It can handle specific collateral requirements, providing optimal portfolios for different counterparties and margin types. Additionally, the approach suggests optimal allocation of assets, including funding when eligible securities are unavailable in inventory, or utilizing idle securities for collateral transformations and securities financing actions to generate revenue.

Thus, embodiments as disclosed are superior to conventional techniques because they allow many more factors to be considered and balanced than was previously possible, and they do this concurrently in an efficient manner that allows for real-time interaction with a user.

In one embodiment, a method of performing collateral optimization is performed by a computing system. The method includes: (a) displaying, to a user, an initial allocation of assets into source and use categories; (b) receiving a plurality of objectives; (c) operating a mixed integer linear program (MILP) taking the plurality of objectives, a plurality of constraints, and the initial allocation of assets as inputs, the MILP being configured to generate an optimized allocation of assets in place of the initial allocation of assets by optimizing the plurality of objectives in view of the plurality of constraints in a concurrent manner; (d) generating a list of actions to transform the initial allocation of assets into the optimized allocation of assets; (e) displaying the list of actions to the user; and (f) in response to the user executing one or more of the actions of the list of actions, creating and displaying to the user an updated allocation of assets in real-time. A corresponding system, apparatus, and computer program product for performing this method and similar methods is also provided according to various embodiments. Other methods, systems, apparatuses, and computer program products are also provided for techniques according to other embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features, and advantages will be apparent from the following description of particular embodiments, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of various embodiments.

Fig. 1 illustrates an example logical arrangement according to one or more embodiments.

Fig. 2 illustrates an example logical arrangement according to one or more embodiments. Fig. 3 illustrates an example logical arrangement according to one or more embodiments.

Fig. 4 illustrates an example logical arrangement according to one or more embodiments.

Figs. 5A-5B illustrate an example display according to one or more embodiments.

Figs. 6A-6B illustrate an example display according to one or more embodiments.

Fig. 7 illustrates an example display according to one or more embodiments.

Fig. 8 illustrates an example display according to one or more embodiments.

Fig. 9 illustrates an example display according to one or more embodiments.

Figs. 10A-10C illustrate an example display according to one or more embodiments.

Fig. 11 illustrates an example system, apparatus, computer program product, and related data structures according to one or more embodiments.

Fig. 12 illustrates an example method according to one or more embodiments.

Fig. 13 depicts example code according to one or more embodiments.

Fig. 14 depicts example code according to one or more embodiments.

DETAILED DESCRIPTION

Techniques described herein take a holistic approach, solving the collateral management actions problem in one optimization step. The problem involves balancing multiple objectives, including liquidity, risk, funding and margin costs, as well as revenuegenerating actions like asset downgrades and securities financing activities. The approach seeks the optimal asset allocation that satisfies margin requirements, maximizes liquidity, minimizes costs, and maximizes revenue opportunities.

The model further allows the user to dynamically consider other objectives concurrently such as minimizing posting costs to find the most cost-effective funding options. The model also takes into account the changes in asset valuations, as the value of posted collateral is mark-to-market daily. Haircuts are applied to mitigate the risk of falling asset values, which can impact collateral requirements. To ensure a feasible and effective allocation, the collateral management optimization problem must be well-defined and incorporate different types of constraints. These constraints fall into three distinct categories: eligibility constraints, accounting constraints, and efficiency constraints.

1. **Eligibility Constraints**: These constraints are derived from both margin schedules and business agreements. They are important to ensure that the allocation model complies with the specific agreements among all counterparties involved in the transactions. Eligibility constraints define which assets can be used to meet collateral requirements and which actions are permissible based on contractual obligations. These are uniquely captured and dynamically maintained in the solution.

2. **Accounting Constraints**: These constraints are based on asset availability and their designated uses. Since the optimization technique solves multiple problems concurrently, accounting constraints facilitate the interactions between different sets of actions. These constraints ensure that the allocation of assets is consistent with the overall accounting and bookkeeping procedures, avoiding conflicts or discrepancies in asset usage and availability.

3. **Efficiency Constraints**: To prevent the wasting of scarce resources, the optimization technique aims to minimize overallocation of collateral, avoid overpaying for funding opportunities, and capitalize on revenue-generating actions. Efficiency constraints help the technique make optimal decisions, considering tangible costs, opportunity costs, and potential benefits. One essential efficiency constraint is the regularization constraint, which penalizes a large number of trades. This encourages the optimizer to find a solution with the least number of transactions, thereby reducing trading costs and streamlining the overall collateral management process.

By incorporating these three categories of constraints, the optimization problem forms a convex set of potential solutions, enabling the optimizer to efficiently search for the minimum point, i.e., the most favourable allocation strategy for collateral management. These constraints together create a well- structured and comprehensive framework to address potentially exponential complexities of collateral management optimization and yield a feasible and viable solution for collateral portfolio actions.

Once the set of optimal actions is selected, the approach then maximizes the liquidity of margin requirements. For example, it considers counterparties’ eligibility templates for all possible margin types and provides a feasible solution where each counterparty allocation is optimal, i.e. maximizing liquidity of allocated collateral.

Framework set up

The model uses several inputs that are fully flexible and customizable based on user preferences. These inputs may alternatively be determined by market forces. These inputs can be divided into three distinct categories:

1. Static: inputs that are not expected to change on a day-to-day basis: a. Collateral eligibility templates. b. Transformations eligibility templates. c. Benchmark and portfolio weights.

2. Dynamic: inputs that are likely to change daily, and potentially intraday. a. Available assets in inventory. b. Counterparties’ margin requirements. c. Rates and fees for transformations.

3. Parameters: describe general information for the model to use, such as HTTP parameters, saving optimization parameters, request types, recompute value, etc.

Inputs are then transformed for the model to consume in terms of specific data frames and hash tables. A collateral management object is created with attributes that correspond to parameters and data inputs. Fig. 1 shows, in transformation 100, how inputs 110 (depicted as inputs 110(a)- 110(e) and verification 115) are transformed with an extract, transform, load (ETL) process 120 to generate an instance of the collateral object class 130, with appropriate attributes 140 (depicted as attributes 140(a)- 140(f)) that map to various inputs 110.

Once the collateral object 130 is instantiated, the approach generates appropriate actions for all uses of securities in the collateral portfolio. These actions are driven by data inputs and correspond to distinct sets of uses for specific assets depending on their eligibility. Fig. 2 presents the main set 200 of actions 210 (depicted as actions 210(a)-210(f)) that can be generated. The total number of actions 210 is determined by the total number of counterparty and margin type pairs, total number of transformations for upgrades and downgrades as defined in eligibility templates, as well as revenue opportunities derived from securities financing templates. Even if another tool or vendor had access to the same data sets and inputs, it would not be able to analyze it in the same manner at the same time with optimized outputs, trade-offs, revenue opportunity, up-/downgrades, etc., as mentioned above. The framework flexibility allows the introduction of additional actions as required, thus introducing trade-offs for all possible securities uses.

Once actions are generated, the model creates an optimization problem to find the best possible allocation of assets given competing objectives and constraints. Fig. 3 depicts an example optimization problem/solution 300 in which a collateral management optimization 310 is defined by objectives 320 and constraints 330 for the actions allocation problem, together with the final optimized counterparty margin allocation 340 generated in response. As depicted, objectives 320 include liquidity 322(a), cheapness to deliver 322(b), revenue 322(c), and opportunity cost 322(d), although these are by way of example only, and other objectives 320 may also be defined and used by users. As depicted, constraints 330 include regularizer 332(a), accounting 332(b), efficiency 332(c), and eligibility 332(d), although these are by way of example only, and other constraints 330 may also be defined and used by users.

Once the problem is defined, the model solves it through a mixed integer linear program (MILP) to find the optimal trade-offs between all securities in the collateral portfolio. Moreover, it guarantees satisfying eligibility requirements as well as funding transformations. This is particularly relevant for the collateral management process given the need to raise cash or ‘transform’ assets to meet margin requirements. The integration of multiple problems into one holistic approach prevents the need to worry about sequential optimization problems, especially when there are several ‘actions’ to be taken. With previous iterative approaches, the computational load increases exponentially. Current market offers are based on quite basic and simple waterfall algorithms. By including trade-offs or potential uses of securities, embodiments of the present approach may lead to capturing previously unseen opportunities.

Fig. 4 shows an example optimal allocation 400 from the actions model, including satisfying counterparty/margin requirements. This, optimal allocation includes various actions 410 (depicted as actions 410(a)-410(d)). Moreover, the approach creates a ‘new’ problem every time data is changed, thus providing a dynamic real-time optimal allocation given the latest available information. Formulating the optimization problem

In an embodiment, the optimization technique is fully developed in Python and uses public libraries, as well as proprietary libraries designed specifically for this problem.

Find below an overview of the approach’s main components:

1. **Variable Definitions**: Two variables, 'w' and 'wn', are created. These variables represent the allocation weights for different assets, 'w' is constrained to be nonnegative, and 'wn' is constrained to be binary (i.e., boolean).

2. **Objective Function**: The objective function is a weighted sum of different terms, each representing a specific objective related to funding, liquidity, cost, and revenue generation. The objective function maximizes funding with maximum liquidity and minimizes costs while considering specific weightings for each objective. This function captures the existing trade-offs between the use of assets given eligible actions.

3. **Constraints**: Several constraints are defined to ensure that the allocations meet specific requirements:

Regularizer: The allocation weights ('w') should be less than or equal to the binary variable 'wn'. This is to say that a weight allocation is positive as long as wn is nonzero.

Elimination of ineligible assets: The weights for ineligible assets are set to zero.

Asset limit constraints: The weights for each asset should not exceed the available value for each specific asset.

Business value constraints: Constraints related to business-specific objectives, like funding (upgrade), downgrade, and securities financing.

Value matching obligations: Constraints to ensure that the value of assets matches the margin obligations for both initial margin (IM) and variation margin (VM).

Counterparty - asset type constraint: Constraints related to the type of assets allocated to different counterparties, considering limits for each asset type.

4. **Solving the Optimization Problem**: The problem is formulated with the objective function to be maximized and the defined constraints. The problem is then solved using an MILP specific solver. The optimal weights are then represented in a 1-d vector of length (n_assets x n _ports where each optimal weight is non-negative, w* >= 0, for all assets and actions. That is, the optimal value w* represents the marginal weight allocated to each asset i action j.

The eligibility criteria are given by the user agreements, and they are captured in specific Decision Model and Notation (DMN) templates. The information is provided as line items with predetermined attributes, and the output is a collection of data tables with eligible fields for each template. The model takes this information as inputs and then creates a comprehensive problem with all eligible securities for all defined templates. In turn, this information is used to create the optimal allocation problem with its respective constraints.

Figs. 5A and 5B show how inputs are provided to the DMN template in example embodiments. In Fig 5A, example screen 500 includes nine rows 502 (“Asset Type”), 504 (“Asset Sub-type”), 506 (“Cusip”), 508 (“Residual Maturity”), 510 (“Base Currency”), 512 (“Issue Currency”), 514 (“Issue Country”), 516 (“HQLA Level”), 518 (“Collateral Value %”), as well as 13 rows with various values for each column. In Fig 5B, example screen 500’ includes rows 502, 504, 508, 514 as well, but it also includes additional rows 511 (“Currency”), 513 (“Agreement Currency”), 520 (“Rating”), 515 (“Issuer”), 522 (“Rate Typey”), as well as 20 rows with various values for each column.

In some embodiments, as part of the inputs, the model uses analytics output from an Activity-Based Collateral Modeling (ABCM) module, as described in U.S. Patent No. 11,620,712 (which is hereby incorporated by reference herein by this reference), to generate the inventory portfolio. Fig. 6A shows a sample breakdown screen 600 of asset sources (depicted in rows 542-564) and uses (depicted in columns 502-522) by the patented ABCM techniques. Breakdown screen 600 also includes a total row 570, a total column 530, and a set of filled cells 572.

Fig. 6B shows more detail for the firm long assets (row 550) in the Box (column 504). As depicted in the screen 600’ of Fig. 6B, the firm long assets are divided by asset type into rows 580 (“Corporates”), 582 (“Sovereign”), 584 (“UST” for US Treasuries), which are used to generate eligibility criteria from DMN templates.

Fig. 7 shows different widgets 702 (depicted as widgets 702(a), 702(b), 702(c), 702(d)) from the Collateral Optimization landing page 700. The values of Key Performance Indicators in these widgets 702 are updated as soon as the model is run, thus providing real- time feedback to the user regarding relevant information, such as funding and investment requirements.

Moreover, the model is flexible in terms of the inputs for different allocations, thus providing a simple solution to scenario analysis. Fig. 8 shows a business selection menu 800, where the user can specify which businesses are eligible for a given optimization allocation.

The output of the model is a set of clear and specific allocations, each designed to be implemented as a standalone transaction, or they can be implemented simultaneously as an optimal portfolio for execution. The breakdown of specific allocations is given by the actions taken by the model, such as, for example, securities from inventory to use in meeting IM margin requirements for different counterparties. Moreover, the specific actions may result from combining different allocations, for example, using funding cash and inventory securities to meet VM margin requirements. A sample allocation can be seen in the screen 900 of Fig. 9. Screen 900 includes various columns 902-914 as well as line items 920 (depicted as line items 920(a), . . . , 920(i)).

Drilling down into the specific line items 920, there are clear and detailed instructions in terms of the securities and actions to execute. For example, screen 1000 of Fig. 10A shows the set of individual securities needed to raise USD using a specific business opportunity for transformations, namely a peer repo program that uses assets of type Corporates to raise cash in the form of USD (compare line item 902(i) from Fig. 9).

Another application is the use of securities for lending, especially important for Hard to Borrow and Special securities. The model incorporates this information as part of the actions set and thus compares the opportunity cost of financing a security to any other use, i.e., transformation, margin requirement, etc. This is particularly important to avoid having idle securities in the inventory, which otherwise could be generating additional revenue. Screen 1000’ of Fig. 10B shows the use of three different securities 1002 (depicted as securities 1002(a), 1002(b), 1002(c)) for Securities Financing business; the model also shows the collateral type being received, being Cash or Non-Cash, which in turn, can be further employed if rehypothecations is allowed.

A unique output of the model is an optimal funding requirement, i.e., cheapest funding available. If there is enough value in the inventory to satisfy margin requirements, but there are no eligible securities or cash, the approach searches for the best funding option to raise cash, then uses this cash to satisfy the margin requirements. Screen 1000” of Fig. 10C shows the use of Funding Cash to satisfy VM margin requirement for a given counterparty. Note that Cash was not available as an SOD position, but was funded with available repo programs.

System

Fig. 11 depicts an example system 30 for use in connection with various embodiments described herein. System 30 includes a computing device 32 operated by a user 36. Computing device 32 may be any kind of computing device, such as, for example, a personal computer, laptop, workstation, server, enterprise server, tablet, smartphone, etc. Computing device 32 includes processing circuitry 34 and memory 40. Computing device 32 also includes user interface (UI) circuitry 35. Computing device 32 may also include various additional features as is well-known in the art, such as, for example, a housing, interconnection buses, network interface circuitry, etc. Computing device 32 may be operated by a user 36 using one or more user input devices 37 and display screens 38. In some embodiments (not depicted), user 36 instead interacts with the one or more user input devices 37 and display screens 38 connected to a remote computing device (e.g., a personal computer, laptop, tablet, smartphone, etc.) that communicates with the computing device 32 over a network. In some embodiments (not depicted), the functionality of computing device 32 may be spread out over several computing devices connected using a network.

UI circuitry 35 may include any circuitry needed to communicate with and connect to one or more user input devices 37 and display screens 38. UI circuitry 35 may include, for example, a keyboard controller, a mouse controller, a touch controller, a serial bus port and controller, a universal serial bus (USB) port and controller, a wireless controller and antenna (e.g., Bluetooth), a graphics adapter and port, etc.

Display screen 38 may be any kind of display, including, for example, a CRT, LCD screen, LED screen, etc. Input device 37 may include a keyboard, keypad, mouse, trackpad, trackball, pointing stick, joystick, touchscreen (e.g., embedded within display screen 38), microphone/voice controller, etc. In some embodiments, instead of being external to computing device 32, the input device 37 and/or display screen 38 may be embedded within the computing device 38 (e.g., a cell phone or tablet with an embedded touchscreen).

Processing circuitry 34 may include any kind of processor or set of processors configured to perform operations, such as, for example, a microprocessor, a multi-core microprocessor, a digital signal processor, a system on a chip (SoC), a collection of electronic circuits, a similar kind of controller, or any combination of the above.

Memory 40 may include any kind of digital system memory, such as, for example, random access memory (RAM), read-only memory (ROM), one-time programmable (OTP) memory, and/or flash memory. Memory 40 stores an operating system (OS, e.g., a Linux, UNIX, Windows, MacOS, or similar operating system, not depicted) and various drivers (not depicted) and other applications and software modules configured to execute on processing circuitry 34.

Memory 40 stores a collateral optimizer program 41 that is configured to execute on processing circuitry 34. Collateral optimizer 41 operates to display an initial allocation of assets 44 (similar to screen 600 of Fig. 6A) to the user 36 as UI 39 on display screen 38. Collateral optimizer 41 also operates to generate an MILP call 42 using the initial allocation of assets 44, a set of constraints 46 (depicted as constraints 46(A), 46(B), . . .), and a set of objectives 48 (depicted as objectives 48(A), 48(B), . . .). Collateral optimizer 41 also operates to send the MILP call 42 to a MILP solver 50 that is configured to perform mixed integer linear programming to solve for an optimized allocation of assets 52 based on the initial allocation 44 and the objectives 48 as limited by the constraints 46. MILP solver 50 may be any program or module configured to perform MILP solving, such as, for example, the open- source SCIP solver or Gurobi or MOSEK. Collateral optimizer 41 also operates to generate a set 56 of actions 58 to be taken to reach the optimized allocation 52 from the initial allocation 44. The set 56 of actions 58 may be drawn from a set 53 of possible actions 54 (see Fig. 2). Collateral optimizer 41 also operates to cause the set 56 of actions 58 to be displayed to the user 36 as UI 39 on display screen 38. When the user 36 executes 60 one or more of the actions 58, collateral optimizer 41 creates an updated allocation of assets 62 in response in real-time.

Memory 40 of the computing device 32 may also store various other data structures used by the OS, collateral optimizer 41, MILP solver 50, and various other applications and drivers.

In some embodiments, memory 40 may also include a persistent storage portion. Persistent storage portion of memory 40 may be made up of one or more persistent storage devices, such as, for example, magnetic disks, flash drives, solid-state storage drives, or other types of storage drives. Persistent storage portion of memory 40 is configured to store programs and data even while the computing device 32 is powered off. The OS, collateral optimizer 41, MILP solver 50, and/or various other applications and drivers may be stored in this persistent storage portion of memory 40 so that they may be loaded into a system portion of memory 40 upon a system restart or as needed. The OS, collateral optimizer 41, MILP solver 50, and various other applications and drivers, when stored in non-transitory form either in the volatile or persistent portion of memory 40, each form a computer program product. The processing circuitry 34 running one or more applications thus forms a specialized circuit constructed and arranged to carry out the various processes described herein.

Method

Fig. 12 illustrates an example method 1200 performed by a system 30 for collateral optimization. It should be understood that any time a piece of software (e.g., OS, collateral optimizer 41, MILP solver 50, etc.) is described as performing a method, process, step, or function, what is meant is that a computing device (e.g., computing device 32) on which that piece of software is running performs the method, process, step, or function when executing that piece of software on its processing circuitry 34. It should be understood, that one or more of the steps or sub-steps of method 1200 may be omitted in some embodiments. Similarly, in some embodiments, one or more steps or sub-steps may be combined or performed in a different order. Dashed lines indicate that a step or sub-step is either optional or representative of alternate embodiments or use cases.

In step 1210, collateral optimizer 41 causes the initial allocation of assets 44 into source categories (e.g., categories listed in rows 542-564 of Fig. 6A) and use categories (e.g., categories listed in columns 502-522 of Fig. 6A) to be displayed to the user 36 in UI 39 of display screen 38 (see display 600 of Fig. 6A and display 600’ of Fig. 6B, for example).

In step 1220, collateral optimizer 41 receives a plurality of objectives 48 (see, e.g., objectives 322 of Fig. 3). Example objectives 48 may include:

• maximize the haircut for funding eligible securities

• maximize the haircut for initial margin (IM) eligible securities

• maximize the haircut for variable margin (VM) eligible securities

• minimize funding costs for funding eligible securities

• maximize model Rate for investment eligible securities

• maximize SecLending. In some embodiments, step 1220 may include sub-step 1225 in which collateral optimizer 41 receives a respective assigned weight for each objective 48.

Fig. 13 depicts an example objectives definition 1300 that includes a weight for each objective 48, summing various terms together. As depicted, some of the objectives 48 include haircut adjustments.

In step 1230, collateral optimizer 41 operates a MILP solver 50 to perform a mixed integer linear program optimization on MILP call 42. MILP call 42 includes the plurality of received objectives 48, a plurality of constraints 46, and the initial allocation 44 as inputs to the MILP solver 50. MILP solver 50 is configured to generate an optimized allocation 52 in place of the initial allocation 44 by optimizing the plurality of received objectives 48 in view of the plurality of constraints 46 in a concurrent manner (i.e., the MILP solver 50 concurrently adjusts different values of the optimized allocation 52 until the optimized solution is obtained).

The plurality of constraints 46 may include, for example:

• Allocated collateral for action < the available collateral for asset

• Sum of Variable Margin eligible securities collateral > Variable Margin requirement for counterparties

• Sum of Initial Margin eligible securities collateral > Initial Margin requirement for counterparties

• Funding Eligible securities available collateral > Haircut times collateral available

• Funding Eligible securities available collateral < 1.01 Haircut times collateral available

• Downgrade Eligible securities available collateral times Haircut > collateral value of downgraded securities

• Secluding Eligible securities available collateral times Haircut > collateral value of securities (secLending)

• Collateral value times haircut for initial and variable margin eligible securities for each counterparty > Counterparty margin requirement (Initial and Variable).

Fig. 14 depicts an example constraints definition 1400.

In some embodiments, step 1230 may include sub-steps 1232, 1234. In sub-step 1232, collateral optimizer 41 first directs MILP solver 50 to perform an optimization at a portfolio level. Then, in sub-step 1234, collateral optimizer 41 directs MILP solver 50 to perform an optimal counterparty allocation. For example, a second MILP call (similar to MILP call 42) may be used in sub-step 1234 that includes an objective 48 of maximizing a haircut for various securities and the following example constraints:

• Allocated collateral for each eligible security < Available collateral for each eligible security

• Available collateral for each eligible security > 0.

In an example use case, with reference to Fig. 6A, initial allocation 44 may have all (or most) assets initially placed in rows 550 (“Firm Long”) and 560 (“To be Actioned”) and in column 504 (“Box”). After optimization, optimized allocation 52 moves at least some assets from those cells 572 to cells 572 in other rows and columns.

It should be understood that the optimization using MILP is a complex process that cannot be performed by a human without the aid of a computer.

In step 1240, collateral optimizer 41 generates a list 56 of actions 58 (e.g., drawing from the set 53 of all possible actions 54) to transform the initial allocation 44 into the optimized allocation 52, and, in step 1250, collateral optimizer 41 operates to cause the set 56 of actions 58 to be displayed to the user 36 as UI 39 on display screen 38. See Figs. 9 and 10A-10C, for example.

In step 1260, in response to the user 36 executing 60 one or more of the actions 58, collateral optimizer 41 creates and displays an updated allocation of assets 62 in response in real-time.

Conclusion

Embodiments as disclosed provide a novel and holistic approach to Collateral Management where traditional collateral related functions are captured and optimized. Moreover, the problem definition is driven by data inputs, in such a way that it is fully optimizing the use of all securities by comparing the costs and benefits of all eligible actions in a dynamic and real-time manner. The output of the model allows a seamless execution of transactions that will satisfy daily margin requirements as well as increasing revenue by utilizing idle assets in the inventory. Last, the framework is flexible enough via user customization capabilities to extend to different sets of actions and simultaneously introduce additional objectives and constraints as required, thus guaranteeing meeting obligations and the efficient use of scarce resources.

While various embodiments of the invention have been particularly shown and described, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.

It should be understood that although various embodiments have been described as being methods, software embodying these methods is also included. Thus, one embodiment includes a tangible computer-readable medium (such as, for example, a hard disk, a floppy disk, an optical disk, computer memory, flash memory, etc.) programmed with instructions, which, when performed by a computer or a set of computers, cause one or more of the methods described in various embodiments to be performed. Another embodiment includes a computer which is programmed to perform one or more of the methods described in various embodiments. A computer, such as one programmed to perform one or more of the methods described in various embodiments, may include processing circuitry, network interface circuitry, user interface (UI) circuitry, memory, storage, interconnection circuitry, and support and containment structures.

Network interface circuitry may include one or more Ethernet cards, cellular modems, Fibre Channel (FC) adapters, InfiniBand adapters, wireless networking adapters (e.g., Wi-Fi), and/or other devices for connecting to a network.

Furthermore, it should be understood that all embodiments which have been described may be combined in all possible combinations with each other, except to the extent that such combinations have been explicitly excluded.

Finally, nothing in this Specification shall be construed as an admission of any sort. Even if a technique, method, apparatus, or other concept is specifically labeled as “background” or as “conventional,” Applicant makes no admission that such technique, method, apparatus, or other concept is actually prior art under relevant patent laws, such determination being a legal determination that depends upon many factors, not all of which are known to Applicant at this time.

Claims

CLAIMS What is claimed is:

1. A method, performed by a computing system, of performing collateral optimization, the method including: displaying, to a user, an initial allocation of assets into source and use categories; receiving a plurality of objectives; operating a mixed integer linear program (MILP) taking the plurality of objectives, a plurality of constraints, and the initial allocation of assets as inputs, the MILP being configured to generate an optimized allocation of assets in place of the initial allocation of assets by optimizing the plurality of objectives in view of the plurality of constraints in a concurrent manner; generating a list of actions to transform the initial allocation of assets into the optimized allocation of assets; displaying the list of actions to the user; and in response to the user executing one or more of the actions of the list of actions, creating and displaying to the user an updated allocation of assets in real-time.

2. The method of claim 1 wherein operating the MILP includes: performing an optimization at a portfolio level; and subsequent to performing the optimization at the portfolio level, performing an optimal counterparty allocation.

3. The method of claim 1 wherein receiving the plurality of objectives includes receiving a respective weight for each of the plurality of objectives.

4. A computer program product comprising one or more non-transitory computer- readable storage media storing instructions, which, when performed by a processing circuitry, cause a computing system to perform collateral optimization by: displaying, to a user, an initial allocation of assets into source and use categories; receiving a plurality of objectives; operating a mixed integer linear program (MILP) taking the plurality of objectives, a plurality of constraints, and the initial allocation of assets as inputs, the MILP being configured to generate an optimized allocation of assets in place of the initial allocation of assets by optimizing the plurality of objectives in view of the plurality of constraints in a concurrent manner; generating a list of actions to transform the initial allocation of assets into the optimized allocation of assets; displaying the list of actions to the user; and in response to the user executing one or more of the actions of the list of actions, creating and displaying to the user an updated allocation of assets in real-time.

5. The computer program product of claim 4 wherein operating the MILP includes: performing an optimization at a portfolio level; and subsequent to performing the optimization at the portfolio level, performing an optimal counterparty allocation.

6. The computer program product of claim 4 wherein receiving the plurality of objectives includes receiving a respective weight for each of the plurality of objectives.

7. A system comprising: user interface (UI) circuitry configured to display, to a user, an initial allocation of assets into source and use categories; processing circuitry coupled to memory configured to perform collateral optimization by: receiving a plurality of objectives; operating a mixed integer linear program (MILP) taking the plurality of objectives, a plurality of constraints, and the initial allocation of assets as inputs, the MILP being configured to generate an optimized allocation of assets in place of the initial allocation of assets by optimizing the plurality of objectives in view of the plurality of constraints in a concurrent manner; generating a list of actions to transform the initial allocation of assets into the optimized allocation of assets; causing the UI circuitry to display the list of actions to the user; and in response to the user executing one or more of the actions of the list of actions, creating an updated allocation of assets in real-time and causing the UI circuitry to display the updated allocation of assets to the user.

8. The system of claim 7 wherein operating the MILP includes: performing an optimization at a portfolio level; and subsequent to performing the optimization at the portfolio level, performing an optimal counterparty allocation.

9. The system of claim 7 wherein receiving the plurality of objectives includes receiving a respective weight for each of the plurality of objectives.