Morgan Stanley halved daily P&L reconciliation with FIXR, agents that turn controllers’ decisions into fixed rules

In two sentences

Morgan Stanley uses an internal multi-agent system called FIXR to work through the thousands of mismatches in its daily P&L reconciliation: the agents propose, controllers approve or correct every proposal, and anything that keeps being resolved the same way is turned into a fixed rule that no longer needs the model. The bank says this halved the time per book, and the most useful lesson for any finance team is the design choice behind it: less autonomy for the model, more deterministic rules, and humans who stay accountable.

Who does it and why it matters

The source is a VentureBeat article by Taryn Plumb, published on 30 June 2026, based on what Todd Johnson, a managing director at Morgan Stanley, said at one of VentureBeat’s AI Impact events. VentureBeat’s own speaker announcement describes him as Managing Director and Head of Process Engineering, Automation and AI Application, and Crain’s New York Business listed him in 2024 as head of strategic design and process on the bank’s AI team. His role is designing processes and automation, and he is not a vendor: Morgan Stanley built FIXR for its own use and does not sell it.

Three things make the case worth a place in this directory:

• It is in production, at scale, in a control process. P&L reconciliation and sign-off is one of the most accuracy-critical and deadline-bound jobs in a bank. Most agent stories are pilots in low-risk areas; this one is not.
• It argues against the fashion for full autonomy. VentureBeat’s headline says it plainly: the bank got there “by making its agents less autonomous”. The model handles the judgement calls; everything that can be made repeatable is moved into rules.
• The pattern scales down. Any company with a recurring reconciliation (bank, intercompany, subledger to general ledger, payment provider to ledger) has “breaks”, people who know how to clear them, and the same explanations repeated month after month.

We could not find a Morgan Stanley publication about FIXR. Other outlets that covered it repeat VentureBeat’s article; a few give the three agents names that are not in the original, which we leave out.

The problem: hundreds of thousands of attributes before a morning deadline

Every trading day, the bank’s desks deal in products such as cash equities and debt. At the end of the day, controllers must reconcile the P&L across four families of systems: Finance, Risk, Operations and Trade Capture. According to the article, hundreds of thousands of attributes frequently fail to match. Each mismatch is a “break” that a controller must investigate, decide whether to adjust, and ideally sign off before the number goes to the desk the next morning.

Before FIXR, Johnson said, this could take up to six hours for a single book. About 100 controllers do this work across the Americas, Europe and Asia, which is why his team chose it: a use case repeated by hundreds of people globally can be proven once and then extended.

How FIXR works

After the nightly P&L calculations finish, the system analyses the breaks and proposes resolutions based on the rules it has learned. The article describes several agents working together:

1. An interpreter of past guidance, which uses previous instructions and decisions to prepare start-of-day resolutions.
2. A learner, which watches what controllers do and documents the rules they apply.
3. A rule builder, which converts repeated patterns into durable, automated logic.

For each break, the system then does one of four things: it auto-clears breaks it has seen before, suggests a solution for less familiar ones, asks for help when it is unsure, or flags the item for human investigation. Controllers review, approve or correct every recommendation, and their decisions feed the next run. “It’s much more like a co-worker than a copilot,” Johnson said.

The design choices behind the result

Process before agents. Before any AI, Johnson’s team ran what he called a “very thorough” process intelligence assessment, mapping and mining the workflow to decide, step by step, whether the answer was an agent, traditional automation or simply re-engineering an inefficient step. “If we can fix that first before we add agents to the problem, then we really will be transforming the opportunity,” he said.

Deterministic by design. The team deliberately limited how much of the workflow depends on the model’s judgement. Johnson’s reasoning, in his words: making things “very prescribed and repeatable” is “cheaper in terms of token consumption” and “more repeatable in terms of controls”, leaving the language model for the parts where a deterministic workflow is not needed. When a given type of break has received enough controller feedback, it becomes a fixed rule instead of a model decision.

Humans own the behaviour. Johnson compares the agent to a junior controller working with a senior one: the senior does not give up responsibility because someone is helping. “There always has to be human accountability, even if there’s a degree of automation,” he said. Technical teams remain responsible for guardrails such as firewalls and encryption; the business users who rely on the agent are responsible for its performance.

Trust is what unlocks the gains. He also warned that efficiency will not come if everyone checks everything an agent does. The way out is not to skip review, but to move reviewed patterns into rules whose behaviour is known in advance.

Evaluation never ends. Because models keep changing, Johnson joked that agents will need ongoing training: there is no point at which you can say all the testing is done and “let it go”.

What is not disclosed

The article does not say which models or vendors FIXR uses, where it runs, how rules are stored or approved, how many breaks are cleared automatically, how long the build took or what it cost. We do not know what share of the time saved comes from the agents and what share from the process fixes made beforehand. Treat the architecture below as the pattern described, not as Morgan Stanley’s implementation.

Step by step to replicate the pattern at a smaller scale

These steps are ours, adapted from the article for a mid-sized finance team reconciling, for example, the payment provider against the ledger or intercompany balances.

1. Pick one recurring reconciliation and measure it. Hours per run, number of breaks, and how they are resolved today. Without that baseline you will not be able to say whether anything improved.
2. Map the process before the model. List each step and label it: delete, fix at source, plain automation (a query, a matching rule) or judgement. Only the last group needs an agent.
3. Create a break register. One row per break: date, source A and B, key, field that differs, amounts, break type, proposed resolution, who proposed it (rule, model or person), decision (approved, corrected, escalated), final resolution, reviewer, reason for the correction.
4. Let the model propose, never post. Give it the break, the history of similar resolved breaks and your written guidance, and ask for a proposal with its reasoning and a confidence label. It drafts; a controller decides.
5. Record every decision and why. Corrections are the most valuable data you have: they are your controllers’ knowledge, written down.
6. Promote patterns to rules with a written criterion. For example: the same break type, with the same resolution, approved at least N times over at least M separate days, with no corrections. The rule is written in plain code or SQL, reviewed by someone other than its proposer, tested on past breaks and given an owner.
7. Demote rules automatically. If a controller corrects a rule’s outcome, the rule stops auto-clearing and goes back to review.
8. Measure and widen gradually. Track hours per run, breaks cleared by rules, by model proposal and by hand, and corrections per week. Extend to the next book or entity only when the numbers hold.

Concrete example: a triage prompt and a promotion rule

Our own prompt for the proposal step, for any capable assistant your company has approved (no confidential data in tools you are not allowed to use):

You help a controller clear reconciliation breaks between {{SOURCE_A}} and
{{SOURCE_B}} for {{ENTITY}} on {{DATE}}. You never post, adjust or approve
anything. For each break below, return a table with: break ID, likely cause,
proposed resolution, evidence used (cite the guidance section or the IDs of
similar past breaks), confidence (high / medium / low) and the action you
recommend: "propose", "ask" (say exactly what information you need) or
"flag for investigation". Use "flag" if the amount is above {{THRESHOLD}},
if no past break is similar, or if the guidance does not cover the case.
Do not invent account numbers, trade IDs or amounts that are not in the input.

Written guidance:
{{GUIDANCE}}

Similar past breaks with their final resolution and reviewer comments:
{{HISTORY}}

Today's breaks:
{{BREAKS}}

And a minimal promotion and demotion rule over the break register (Python, our own sketch; thresholds are illustrative and should be set by your controllers and auditors):

from collections import defaultdict

MIN_APPROVALS, MIN_DAYS = 20, 10  # illustrative, not Morgan Stanley's

def candidate_rules(register):
    """Group decided breaks by (type, resolution) and propose rules
    only where controllers approved the same answer repeatedly."""
    groups = defaultdict(list)
    for b in register:
        if b["decision"] in ("approved", "corrected"):
            groups[(b["break_type"], b["proposed_resolution"])].append(b)
    for (btype, resolution), items in groups.items():
        corrections = [b for b in items if b["decision"] == "corrected"]
        days = {b["date"] for b in items}
        if not corrections and len(items) >= MIN_APPROVALS and len(days) >= MIN_DAYS:
            yield {"break_type": btype, "resolution": resolution,
                   "evidence": [b["id"] for b in items],
                   "status": "pending human approval"}  # a person signs it off

def demote_if_contradicted(rule, decision):
    if decision == "corrected":
        rule["status"] = "suspended: back to review"
    return rule

The code proposes rules; it does not activate them. A person approves each rule, and the rule itself is plain logic that runs without the model, which is the point of the pattern.

Results, as stated by the source

• Time per book: from up to six hours to two to three hours (Johnson).
• Scale: about 100 controllers in the Americas, Europe and Asia; about 1,500 hours saved per week (Johnson). Our own arithmetic shows the two figures are consistent: three hours saved per controller per trading day over five days is 15 hours a week, times 100 controllers.
• Qualitative: controllers spend the time on “more value-added analysis” and “deeper risk consideration” (Johnson).
• Not given: accuracy, auto-clearance rates, errors caught or missed, costs, the build timeline or an independent review.

Limitations and risks

• One talk, one article. Everything comes from a managing director speaking at an industry event, reported by the outlet that organised it. The figures are stated, not audited, and we found no Morgan Stanley document about FIXR.
• Rules can freeze mistakes. If controllers approve the same wrong resolution often enough, it becomes a rule. Promotion needs a second reviewer and periodic sampling of auto-cleared breaks.
• Drift. Upstream systems, products and models change. A rule or a prompt that was right last quarter may be wrong now; Johnson’s point that evaluation never ends applies to both.
• Audit trail. A regulated firm must be able to show who approved each resolution and each rule, and why. Build the register first, not as an afterthought.
• Data and confidentiality. Trade and P&L data are highly sensitive; use only approved models and environments, with access limited to the data each step needs.
• Scale assumptions. The economics of a bank with 100 controllers are not those of a ten-person finance team. The pattern travels; the hours saved do not.

Common mistakes

• Adding an agent to a broken process. Morgan Stanley mapped and fixed the workflow first.
• Letting the model decide what a rule could decide. Every break type that can be prescribed should be, for cost and for control.
• Approving in bulk. Review without recording corrections teaches the system nothing and leaves no trail.
• Rules without owners. Each promoted rule needs an owner, a test and a way to be suspended.
• Counting only the time saved. Also measure corrections and items that slipped through, or you will not know whether to trust the next extension.

Conclusions

FIXR is a large bank’s system, but its central idea is simple and transferable: use the model to read guidance, learn from people and propose; let people decide; and turn what they decide repeatedly into rules that are cheap, predictable and auditable. The reported result, half the time on a daily control process for some 100 controllers, comes from that combination, not from letting agents run alone. For a smaller team, the place to start is not the model but the break register and the written criterion for when a decision becomes a rule.