When I read the CFPB's October 2024 consent order against Apple and Goldman Sachs, I was expecting to find a system failure — a crash, a data corruption, some catastrophic technical event nobody anticipated. What I found instead were three words in the description of the routing workflow: "known technological issues."
Not unforeseen edge case. Not undetected failure. Known. The routing gap between Apple's system and Goldman's had been documented. The engineers had identified it. Thousands of consumers had valid billing error notices filed and silently abandoned between the two systems — and the institution knew the architecture had this property before the CFPB's examiners reconstructed the state machine trace. The $89 million in combined penalties wasn't for negligence in the ordinary sense. It was for a known dead state that nobody stopped to formally prove out of existence.
That's what drove us to build Veriprajna's financial compliance formal verification system for dispute workflows. But understanding what "formally prove out of existence" actually means — and why it's a fundamentally different claim than "we tested it" — took longer to explain than I expected.
The Spreadsheet That Governs $89 Million Risk
I was sitting with a compliance officer at a mid-size card issuer walking through how they managed Reg Z deadline tracking. The case management system had calendar flags. There were two spreadsheets two people maintained. Team training covered the 30-day acknowledgment requirement and the 90-day resolution window. They had passed their most recent CFPB examination.
My question was different: could they prove the workflow structurally couldn't miss a 30-day acknowledgment — not that it hadn't missed one, but that the architecture made it impossible under any failure condition? They thought about it for a moment, then said something to the effect that they'd know when the CFPB told them.
I went back and looked at the market data after that conversation. The Wolters Kluwer Q1 2026 Banking Compliance AI survey found that 42% of institutions "often" rely on manual compliance processes for exactly these workflows, with another 31% doing so "sometimes." Those aren't edge cases — that's the majority of the industry's current practice for workflows carrying $89 million enforcement consequence. The technology gap between what the customer operations system does and what the compliance team can actually verify about it is where the Apple-Goldman problem lived. It's not a unique failure; it's the design of the current system.
Why the Bridge Analogy Finally Worked
I spent months explaining formal verification in software QA terms — better test coverage, more edge cases, extended scenario libraries. It didn't land. The buyer heard "more tests" and thought about their QA team's backlog.
The analogy that finally worked was structural engineering. When you certify a bridge, you don't prove it's safe by sending trucks across it. You model the load distribution mathematically and prove that the structure satisfies safety constraints under all possible load configurations — including configurations no truck has ever produced in practice. The model either satisfies the constraint in all reachable states, or it gives you a specific failure case that shows exactly what condition would break it.
A dispute workflow is a state machine. Reg Z's 30-day acknowledgment deadline is a temporal logic property. The verification engine either proves that no reachable state can violate that property — across every possible submission timing, routing failure, system state, and third-party handoff — or it produces a counterexample: the exact execution sequence that leads to a deadline miss. The Apple-Goldman routing gap would have produced a counterexample. The test suite didn't exercise the path where the Apple-side intake logged the notice but the forwarding to Goldman silently failed.
That's the distinction that matters when the compliance officer is thinking about the examiner: a test result says the workflow worked for the paths you ran. A formal proof says the workflow can't fail for any path. Those are different evidential claims, and regulators are increasingly asking for the second one.
Testing tells you what happened in the paths you chose. Proof tells you what can't happen in any path, including the one you didn't think to test.
The Imandra Map That Told Me Where We Were
I assumed early on that FINBOA and Quavo would be the closest vendors to position against. Both operate in dispute resolution: FINBOA's Reg E tracking reduces processing time by 90% according to their published case studies, and Quavo achieved an 87% automation rate at a regional credit union within one month — 42% of disputes resolved without human intervention, 500% ROI documented at a regional bank. Meaningful results.
What clarified the actual market position was noticing Imandra. Imandra is the only company doing formal verification in financial services — Goldman Sachs, Itiviti, and OneChronos are clients. Imandra verifies trading algorithm correctness and exchange matching logic, the capital markets infrastructure where formal methods have been applied for decades. What I noticed was that Goldman Sachs is simultaneously an Imandra client for trading system verification and a $45 million enforcement action target for consumer dispute system failures. Goldman uses formal verification for its exchange matching engine and spreadsheets (or something close to them) for its Reg Z dispute routing. That's not a Goldman-specific failure — it's the state of the art. Capital markets have had formal verification for years. Consumer banking compliance workflows don't have it yet.
The OCC Memo That Gave the Conversation a Framework
I stopped leading with the technical explanation after I read OCC Bulletin 2025-26. The OCC's framing — that any quantitative method materially influencing compliance decisions is a "model" requiring SR 11-7 validation — gave me a framework banks already had. They have model governance committees. They have SR 11-7 validation processes. The question isn't whether to validate the automated dispute decisioning system; it's what validation standard to apply.
SR 11-7 validation has historically meant back-testing and performance monitoring, which evaluate what the model did on historical data. I now frame formal verification as the stronger validation: instead of evaluating past performance, prove what the system can and can't do on all future inputs. That framing resonates with CROs who already understand what SR 11-7 requires — it's not a new compliance burden, it's the strongest answer to one they already have.
The EU AI Act's August 2, 2026 deadline for high-risk AI in financial services adds a timeline. AI systems influencing credit and payment services must demonstrate documented, provable accuracy and robustness properties for banks operating in EU markets. The demand for formal verification evidence isn't just coming from the pitch — it's coming from the rulemaking, and the clock is running.
What I Think About When the Workflow Changes
I keep returning to one thing: the pace of change in dispute workflows is accelerating faster than the market's verification practices. Global chargeback volumes are projected at 337 million annually by 2026 (Chargebacks911) with a 24% increase through 2028 (BankInfoSecurity), partly from new dispute types created by AI-agent-initiated transactions that existing process designs don't handle. Card networks are updating timeline requirements. New payment processors are being integrated. Each change modifies the state machine governing deadline compliance.
Standard regression testing doesn't catch the compliance violation that surfaces only under the specific multi-system failure sequence no one modeled. The Apple-Goldman routing gap had been documented — it still wasn't tested for, because no one built the test case for the sequence of events that triggered it.
The question I'd ask any compliance officer whose institution is modifying its dispute workflow in the next 18 months: when the CFPB examiner reconstructs your state machine traces in the next examination cycle, which execution path are you most uncertain about? If the answer involves a third-party routing handoff, a legacy integration, or a sequence of events that requires two systems to fail in a specific order — that's the path formal verification would find for you first.
The alternative is finding out the way Goldman did.