When No Portfolio Satisfies the Mandate: Using AI to Diagnose Optimization Infeasibility

Portfolio optimization problems do not always have a solution. For a complex mandate, diagnosing infeasibility can become a substantial part of the portfolio construction workflow. In that circumstance, the combination of specialized optimizer diagnostics and generative AI can materially change the user experience.

A portfolio manager can specify a perfectly reasonable objective and a set of individually sensible constraints, yet the combination may be impossible to satisfy. A maximum position size can conflict with a minimum number of sectors represented. Tight benchmark-relative bounds can conflict with a cardinality limit. A turnover cap can prevent the portfolio from reaching the required risk or factor exposure. In fixed income, duration, rating, issuer, liquidity, and lot-size requirements can interact in similar ways.

When this happens, the optimizer may correctly report the problem is infeasible. Mathematically, that answer is precise. Operationally, it is only the beginning.

The investment professional still needs to know: Why is the problem infeasible? Which requirements are in conflict? How far are we from feasibility? And which change would restore a solution while preserving as much of the original investment intent as possible?

Across investment organizations, significant time can be spent identifying and resolving optimization infeasibility. Portfolio managers, quantitative researchers, implementation teams, and support specialists may need to inspect constraints one by one, remove or relax them, rerun the optimization, compare outputs, and repeat the process until the source of the conflict becomes clear.

This is the third article in our series on the next generation of portfolio construction.

• The first explored conversational portfolio construction and the combination of AI, integrated investment data, and a rigorous optimization engine. (From Investment Intent to Portfolio: The Rise of Conversational Portfolio Construction)

• The second argued that easier natural-language access makes optimization more important, not less. (Why AI Makes Your Portfolio Optimization Engine More Important, Not Less)

In this analysis, we focus on what happens when the portfolio requested by the user cannot be constructed as specified.

A Reasonable Request Can Still Be Impossible

Consider this example investment request: “Replicate the S&P 500 with no more than 20 stocks, keep every sector within 0.5% of the benchmark, cap every security at 3%, and keep predicted tracking error below 50 basis points.”

Each requirement has a clear investment rationale. The portfolio should be compact. Sector exposures should remain close to the benchmark. No single position should dominate. Tracking error should remain low.

But the requirements are mutually inconsistent in more than one way. The most basic conflict is arithmetic: 20 holdings capped at 3% each can hold at most 60% of the portfolio, so it cannot be fully invested. Even if that conflict were removed, 20 names may not be enough to keep every sector within ±0.5% of the benchmark, and the 50-basis-point tracking-error limit may be impossible at that level of concentration.

As a result, the optimizer is correctly identifying that no portfolio exists inside the feasible region the user defined.

Infeasibility Is Usually About Interactions, Not a Single “Bad” Constraint

One reason infeasibility can be difficult to diagnose manually is that individual constraints often look perfectly acceptable in isolation. The conflict emerges only when several are imposed simultaneously. Infeasibility can also be layered: resolving the most visible conflict may simply expose the next one, as the 20-stock example shows.

This is why a simple error message rarely provides enough information. The user needs diagnostics that reason about the structure of the problem, not merely a statement that no feasible point was found.

The Traditional Troubleshooting Loop Can Be Expensive

Incremental experimentation is a common way to investigate infeasibility. For example, remove a constraint and rerun. If the problem becomes feasible, add the constraint back in with a wider bound and try another constraint. Compare the new solution and repeat until the source of the conflict is apparent.

The method works, but it can be slow and misleading because a constraint that appears responsible after being removed may only be one member of a larger conflicting set. Relaxing one requirement aggressively may restore feasibility even though a smaller change to another requirement would better preserve the mandate.

Our earlier guidance on optimizer selection notes that users can incrementally add constraints and rerun an optimization to understand their effect. That approach is useful for research and troubleshooting, but conversational diagnostics create an opportunity to make the process much more systematic and accessible.

The Optimizer Must Diagnose the Conflict

The core diagnosis must come from the optimization system itself. Dedicated routines can examine the mathematical problem and generate structured evidence about why feasibility failed.

Depending on the problem, useful diagnostics steps may include:

• Identify the smallest group of requirements that cannot be satisfied together.

• Quantify how far each requirement would need to move for a feasible portfolio.

• Propose alternative changes and confirm that a proposed change actually restores feasibility.

• Distinguish genuine conflicts in the mandate from data or configuration issues.

In optimization more broadly, well-established diagnostic techniques include irreducible infeasible subsystems (IIS) and elastic or minimum-norm constraint relaxations. When the problem includes discrete decisions such as cardinality limits, diagnosis can become a harder combinatorial problem in its own right, which is why it calls for dedicated routines rather than generic solver output.

FactSet Portfolio Optimizer provides dedicated infeasibility diagnostics that both express conflicts from the user’s requirements and that state which parts of a problem were not analyzed. The key design principle is the optimizer should produce the evidence, and the LLM should interpret and act on it.

The LLM Turns Diagnostics into a Conversation

Raw optimizer diagnostics can be highly technical. A portfolio manager does not necessarily want a list of internal constraint identifiers or solver statistics. The useful output is an explanation in the language of the mandate.

A live example makes the point. The second article in our series built a portfolio from a single instruction: tilt toward momentum and profitability inside a 3% active-risk budget, a 20% two-way turnover limit, sector bands of ±2%, and a 5% cap on any single position. The optimizer delivered it, but the tilt came out lopsided with active momentum exposure reaching +0.25 while profitability moved only to +0.05.

The natural next request is to ask for both explicitly: momentum of at least +0.25 and profitability of at least +0.15, with everything else unchanged. That request has no solution, and the diagnostics explain why.

The value is the prose grounded in quantitative diagnostics generated by the optimization workflow.

The user can then continue with natural-language requests: “Keep the 5% cap. How much turnover would I need?” or “Keep the cap and the turnover budget. What is the highest pair of floors I can reach?”

Each question becomes another optimization or diagnostic calculation rather than an ungrounded conversational suggestion.

A Good Fix Preserves Investment Intent, Not Just Mathematical Feasibility

Restoring feasibility is not the ultimate objective. Almost any difficult problem can be made feasible by relaxing enough constraints. The more important question is which change makes sense economically.

In the example above, the diagnostics identify several ways forward—raise the position cap, raise the turnover budget, or lower the factor floors—and quantify the change required in each case to restore a solution.

Those changes are not interchangeable. The position cap expresses how much concentration the portfolio is willing to carry, the turnover budget expresses how much trading the mandate permits, and the factor floors express the investment thesis itself. A useful conversational system makes those trade-offs explicit rather than presenting one mechanically feasible solution as the answer.

The LLM can also contribute context such as relating each mathematical relaxation back to the original instruction, identifying which user-stated preference it changes, and asking the user to choose when the trade-off is genuinely a matter of investment judgment. It’s an advantage of diagnostic resolution when priorities are not known in advance because the system can first identify the conflict and quantify the alternatives, and the investor can then decide which requirement is most appropriate to relax.

Diagnosing the Conflict Rather Than Prespecifying the Relaxation

Another way to handle infeasibility is to define a relaxation hierarchy in advance:

• The user specifies which constraints may be relaxed and assigns priorities among them.

• Constraints outside the hierarchy remain hard.

If the original problem is feasible, the hierarchy has no effect. If it is infeasible, the system restores feasibility in this order:

• Higher-priority requirements are protected as much as possible.

• Lower-priority requirements absorb the relaxation first.

• After the required relaxations are determined, the original investment objective is optimized.

That is a useful mechanism when the hierarchy of requirements is already known. A regulatory, legal, or client-imposed constraint may be non-negotiable while a preferred number of holdings, turnover targets, or benchmark-relative bands may have more flexibility. It also maintains the separation between feasibility restoration and the investment objective because the optimizer is not trading constraint violations against expected utility through a penalty term.

The limitation is that an important decision must be made before the optimization runs: the user must confirm which constraints are allowed to move and in what order. In many real portfolio construction problems, that is precisely what is not known. The conflict may involve several interacting requirements, and the economically preferable relaxation may not become clear until the problem has been diagnosed.

The diagnostic approach described here starts from the opposite direction. Rather than requiring a predefined relaxation order, the optimizer first analyzes the infeasible problem itself. It identifies the requirements involved in the conflict, quantifies candidate relaxations, and tests alternative ways to restore feasibility. The LLM then translates the alternatives into investment language and lets the user decide which trade-off best preserves the original mandate.

The two approaches are complementary. When a hierarchy is defined, the optimizer reports which requirements were relaxed and by how much. If feasibility still cannot be restored, the diagnosis addresses the remaining requirements.

That distinction is particularly useful in a conversational workflow. A predefined hierarchy answers “If something must give, which requirement should give first?” Diagnostic infeasibility analysis answers a different question: “What is actually causing the conflict, what are the available ways out, and what would each one change?” The latter does not require the investor to encode a complete ordering of constraints before knowing what the conflict will be.

From Error Message to Guided Resolution

The resulting workflow can be thought of as five steps:

Diagnostics Can Broaden Access Just as Much as a Natural-Language Setup

In the first article in our series, we argued that conversational portfolio construction can broaden access to optimization by reducing the expertise required to configure a strategy. Infeasibility diagnostics address the other side of the same problem.

It is not enough to make the first optimization easy to launch. The workflow also has to help users when the real world becomes complicated. A less experienced optimization user may be able to describe the desired portfolio perfectly well but may not know how to interpret a solver failure or which requirement should be tested first.

By combining quantitative diagnostics with a conversational explanation, the system can help more investment professionals work through these cases without requiring them to become optimization specialists.

Experienced quantitative users benefit from faster diagnosis, reproducible tests, and a structured way to compare alternative relaxations.

The Recommendation Must Remain Transparent

An AI-assisted diagnostic system should not silently relax constraints to produce a portfolio. Doing so would make the experience simpler at the expense of investment control.

The better approach: Identify the conflict, show the diagnostic evidence, quantify the proposed change, explain what investment requirement it affects, and let the user approve the modification.

The system should also distinguish between a hard mandate and a user preference. A regulatory, legal, or client-imposed constraint may not be negotiable. A desired number of holdings or a preferred tracking-error target may have more flexibility. Conversational interaction is particularly useful because the user clarifies those distinctions.

From Optimization Engine to Interactive Decision Support

FactSet Portfolio Optimizer (FPO) constructs multi-asset class portfolios according to custom objectives while adhering to specified constraints and costs. Our white paper, Multi-Asset Class Portfolio Construction, describes support for equity, fixed-income, fund-level, and true cross-asset workflows as well as both mean-variance and scenario-based Expected Tail Loss approaches.

Programmatic access through the FPO module allows optimizations and results to be integrated into broader workflows, while the FactSet Programmatic Environment provides a natural environment for combining FactSet data, analytics, Python workflows, and portfolio construction tools.

FPO's dedicated infeasibility diagnostics, combined with conversational intelligence, extend that architecture from execution toward interactive decision support. When the system cannot solve the portfolio, it helps the user understand the boundary between what was requested and what is mathematically achievable.

A Better Failure Mode

In sophisticated portfolio construction, infeasibility is not an exceptional software error. It is often useful information: the mandate, data, and investment opportunity set tell users that not every requirement can be satisfied at the same time.

The traditional experience often stops at that observation. The next generation of portfolio construction goes further.

Specialized optimizer routines determine why the mathematical problem has no solution. An LLM translates those diagnostics into investment language, guides the user through alternatives, and orchestrates new optimization runs. The user remains responsible for deciding which economic trade-off is acceptable.

That changes infeasibility from a dead end into a conversation for an alternative solution and from a time-consuming troubleshooting exercise into a structured part of the portfolio construction process.

The next article in our series will advance from the conversation to what follows it: how a workflow that has settled can be turned into a purpose-built interface while keeping the specifications underneath within reach.

To Learn More

FactSet Portfolio Optimizer: overview of FactSet's multi-asset class portfolio optimization capabilities.

FactSet Portfolio Optimizer API: programmatic endpoints for running optimizations, retrieving results, and integrating FPO into broader workflows.

FactSet Programmatic Environment: programmatic access to FactSet data and analytical applications in a JupyterLab-based quantitative research environment.

How to Select a Portfolio Optimizer that Supports Your Investment Priorities: earlier FactSet Insight discussion of optimizer capabilities, data integration, risk models, and platform flexibility.

This blog post is for informational purposes only. The information contained in this blog post is not legal, tax, or investment advice. FactSet does not endorse or recommend any investments and assumes no liability for any consequence relating directly or indirectly to any action or inaction taken based on the information contained in this article.