OpenAI’s October 2 account of Chatham Financial’s AI work reports that a trade-validation review fell from about 30 minutes to under four in early measurement. The useful lesson is not that every financial team should buy the same AI. Chatham defined the evidence a reviewer needs, the discrepancies worth flagging, and the point where a person must decide. Then it built around that decision.
That order matters. If your team wants to try something similar this week, choose one review task and write down what must be checked before anyone can approve it. Do that before choosing software.
The fastest review is not the one with the fewest people. It is the one that gives the right person the right evidence at the right moment.
A four-minute result needs a closer look
Chatham advises clients on capital-markets decisions. According to OpenAI’s customer story, the firm used Codex to develop an application that gathers supporting transaction evidence, compares important terms, and flags discrepancies for review. OpenAI says early measurements put the review at under four minutes, down from around 30. That is a reported result from a vendor-published case study, not an independently audited average across every trade or every client.
The distinction is worth keeping. A time saving in an early workflow does not tell us how often exceptions occur, what happens when evidence is missing, or how the team handles a bad comparison. It does show a more interesting design choice: the application does the repetitive collection and comparison; a reviewer gets the exception rather than having to reconstruct the whole file.
OpenAI describes Chatham’s “Process Zero” approach as starting with the outcome, identifying the minimum inputs and evidence required, and deciding where human judgment is essential. This is much more precise than asking a team which tasks it wants AI to do. People can answer that question all day. It rarely tells you what constitutes a safe handoff.
Where the handoff actually lives
Imagine a team that checks incoming contracts against a signed order before billing. A normal review may involve opening two documents, finding the same fields in both, checking dates and amounts, and asking a colleague about a mismatch. An AI assistant could collect the documents and compare the fields. But somebody still has to determine whether a mismatch is a typo, an agreed exception, or a reason to stop the invoice.
That is an illustrative workflow, not a claim about Chatham’s contracts. The point is to separate comparison from authority. “The numbers differ” is a finding. “Bill the customer anyway” is a decision. An implementation becomes dangerous when a tool quietly crosses that line because nobody bothered to name it.
For a manager, the first design document can fit on a page. Name the record that counts as the source of truth. List the fields that must agree. Say what happens when one is blank. Define which discrepancies can be resolved by a named reviewer and which require escalation. Keep the evidence attached to the final disposition so another person can reconstruct what happened later.
Only then ask whether AI can reduce the time spent finding and comparing evidence. Without that page, a fast demo can just make an ambiguous process run faster.
Measure the whole job, not the click
The 30-to-under-four-minute figure is an attractive headline. It is not, by itself, a business case. A team could save time on routine cases and lose it back on exceptions, rework, or quality checks. Leaders need a baseline that includes the entire job.
Track how long a case takes from arrival to final approval, not just the time spent inside the AI application. Record the share of cases sent to a human, the reasons they were escalated, corrections made after approval, and the time a reviewer spends verifying the tool’s evidence. Compare a representative sample with the old process. If the work is regulated or financially consequential, the audit trail belongs in the definition of “done,” not in a later cleanup project.
This does not require a company-wide transformation program. Run a bounded test with one team, one class of transaction, and a person accountable for the exception queue. Make the person who owns the outcome sign off on the decision rules. Let the people doing the review challenge the rules before you automate them. They usually know which apparent mismatches are harmless and which tidy-looking records are not.
A practical threshold for expansion is not “the demo worked.” It is that the team can explain, from actual cases, what the system got right, what it missed, how often a person had to intervene, and whether total time and error rates improved. The answer may be to automate less than expected. That is still a useful result.
The part worth copying
Chatham’s case is striking because it applies AI to a high-stakes review without making human judgment disappear from the description. OpenAI’s account says the workflow begins by determining where that judgment is essential. The product is built around that boundary.
Most organizations have their own version of trade validation: claims intake, invoice matching, vendor onboarding, contract review, or a monthly reconciliation somebody holds together through experience. Pick one. Ask its owner to show you the last difficult case, not the cleanest one. Map the evidence needed to resolve it, then test whether AI can assemble that evidence without deciding what only a person is authorized to decide.
The four-minute number may not travel to your business. The boundary can.
Research and structure: Mai. Direction and voice: John Lipe. Source: OpenAI, “Chatham scales its capital markets expertise with OpenAI,” October 2, 2026.