What the risk industry needs;
The financial services industry loses billions each year not to fraud alone, but to the operational gaps surrounding it.
The initial intake forms that lack context, the dispute cases handled manually between agents and teams fraught with nuanced errors, the incidents that grow larger because no one had a shared room to work in.
I have worked inside these gaps. I watched disputes become a sidelined aspect of fraud, cases get grouped and lack of historical data
Fraud waves move faster than the humans coordinating the response. What I understood was not only a technical problem but a design one: the tools that exist were built for compliance and basic information collection, not for the people doing the work.
Covalence is a dispute operations suite I built in response to that. It moves a case from first contact to network submission— triage, documentation, batch filing, portfolio scoring, inter-institutional coordination, and fraud incident command. It has seven tools built into one workflow. Here’s a live working prototype.
001
Triage
On the cost of unstructured intake;
The first question a dispute touches determines everything that follows. Which regulation applies. Which network rule governs the timeline. Whether the cardholder's framing of the incident maps to a chargeback reason code or to something more complex — fraud, error, or a claim that will not survive arbitration. Most institutions receive these first contacts in free text: a phone call, a chat message, a form that asks only for the amount and the date.
What gets lost in that moment is not information but structure. By the time a case reaches a specialist, the intake framing has already narrowed what questions get asked.
Triage is the entry point for Covalence. It walks through the relevant fields — transaction type, reason code, dollar amount, product, filing window — and produces a structured handoff to the Dispute Desk. The intent is to make the first-touch conversation thorough enough that nothing needs to be reconstructed later. Filing windows in chargeback disputes are strict; context, unlike time, can be recovered.
002
Dispute Desk
On case lifecycle and the bottleneck of evidence;
A chargeback case is not an event. It is a sequence: intake, investigation, documentation, rebuttal, filing, outcome. The problem most dispute operations face is that this sequence is managed across disconnected systems — a CRM for the customer contact, a shared drive for the evidence, a spreadsheet for the status, email for the back-and-forth. Each handoff is a place where context falls out.
The Dispute Desk is a case management layer built around that reality. Each case carries its own timeline, reason code, status, evidence packet, and agent notes. Analysts can attach documents directly to a case, draft pre-arbitration rebuttals inside the interface, and escalate to batch filing without leaving the record.
The decision I kept returning to while building it: evidence should live with the case, not beside it. A document uploaded to a case in the Desk travels with that case into Multi, into filing, into the audit log. The record stays whole.
003
Multi
On the economics of scale in dispute operations;
One dispute costs roughly the same to work whether the recovery is forty dollars or four thousand. That asymmetry — fixed operational cost against variable recovery — is the core economics problem in dispute management. The answer the industry settled on is batching: aggregate similar cases, process them together, file as a group. The answer works. The tooling around it, less so.
Multi is the batch operations layer in Covalence. It groups cases by network — Visa, Mastercard, Amex, Discover — and surfaces the fraud queue and the service disputes queue separately, because they file under different rules and require different documentation. Analysts can review, assign, and advance cases as a group. When a case is ready to file, Multi generates a network-formatted submission package — all required fields, evidence manifest, case identifiers — as a downloadable text file.
The design choice here was to make the package generation a one-click action at the case level, not a batch-only operation. Because sometimes a single case needs to go now.
004
File
On audit trails and why the record after submission matters;
Filing a chargeback is not the end of a case. It is the beginning of a different kind of accountability. The network receives the package. A timer starts. If the merchant representments, a response is required — and the response needs to be grounded in the original submission. If a regulator asks for documentation of the dispute process, the submission record is what you produce.
The FILE module is a submission history log. Every case filed through Covalence leaves a record here: network, reason code, amount, filing timestamp, and the full package text. Agents can pull up any past filing, see the evidence manifest that accompanied it, and re-download the package if needed.
What I was trying to solve was the gap between the moment of filing and the moment of review — sometimes days, sometimes months — when the original context has left the person who filed it. The log makes the record self-contained. You should be able to open any past submission and understand exactly what was claimed, what evidence supported it, and when it went out.
005
DFA
On portfolio-level scoring and the gap in dispute receivables funding;
A dispute portfolio is an asset. The right to recover funds from a filed chargeback has economic value before the chargeback is won — and a significant secondary market has developed around the purchase of these claims at a discount. But the pricing of a dispute portfolio is opaque, inconsistent, and often tilted against the institution selling. Recovery rates, filing window proximity, reason code strength, merchant chargeback ratios, and documentation quality all affect fundability. Most sellers go in without a model.
The DFA — Dispute Funding Analyzer — scores individual claims and produces a portfolio-level assessment. Each claim is evaluated across those dimensions, graded A through D, and assigned an estimated advance rate. The portfolio view surfaces concentration risk, window risk, and the drag of low-grade claims on the aggregate score.
The intent is not to replace the pricing conversation with a funder but to enter it informed. A seller who understands their portfolio's grade distribution and can explain the basis for high-scoring claims is in a different negotiating position than one who cannot.
006
Duo
On inter-institutional coordination and the missing real-time layer;
Fraud does not stop at one institution. A card compromised in one breach surfaces at dozens of FIs within hours. A synthetic identity that passes one bank's onboarding passes another's the same week. The information that would interrupt these patterns — the breach, the mule account, the merchant — is distributed across institutions that have limited mechanisms for sharing it in time.
DUO is a real-time collaboration layer for two institutions working a shared case or fraud pattern. Both sides connect to a live session, contribute case data, and maintain a joint record. The session is synchronized through Supabase; changes made by one institution appear for the other without a page refresh.
The design assumption I made: the primary obstacle to inter-institutional coordination is not willingness but friction. If the session setup takes three minutes and the shared workspace requires no integration with either institution's core system, the bar to starting a joint investigation is low enough to cross.
007
Trio
On three-party fraud incidents and why war rooms need infrastructure;
The hardest fraud events to manage are the ones that involve three parties simultaneously: your institution, the receiving platform or financial institution where funds landed, and the cardholder population caught in between. A fraud wave of this kind — account takeover at scale, a synthetic ring that spanned onboarding, a merchant that processed thousands of unauthorized transactions — requires coordination across all three layers at once.
TRIO is an incident command module. An agent opens an incident when a wave is detected, links the relevant Dispute Desk cases, maps the transaction flow across the three parties, tracks SAR and STR filing obligations, and coordinates with the receiving FI. Other agents join the incident from their own sessions; the war room feed — a shared log of situation updates, decisions, and actions — is visible to all of them, synchronized in real time.
What I kept returning to while building it: fraud incidents at scale are not case management problems. They are coordination problems. The tool that solves them needs to be a room, not a record.
These seven tools are a working prototype, not a finished product. I am learning the domain as I build into it, and the design choices are being tested against real operational logic as I go. What you see at the link below is what exists today. What comes next depends on what the work reveals.