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 how Chatham defined the evidence a reviewer needs, the discrepancies worth flagging, and the point where a person must decide. It built around that decision. Other financial teams can examine those boundaries before choosing AI for their own work.
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.
Design the review to give the right person the right evidence at the right moment, then measure the time through approval.
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 reported result comes from a vendor-published case study. Establishing an average across every trade or every client would require an independent audit.
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 workflow is hypothetical. 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
The 30-to-under-four-minute figure is an attractive headline. A business case also needs to account for the rest of the work. 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, including the time spent inside and outside 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, include the audit trail in the definition of “done” so it is ready at approval.
Begin with a bounded test involving 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.
Before expanding, require the team to 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, with the complications intact. 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.