How our AI works
The domain approach behind Chargeflow's evidence agents: an industry-agnostic data foundation, then dispute execution by an orchestrator delegating to specialised agents with a QA agent in front of submission.
Chargeflow's AI is built around a domain model, not an industry list. A travel dispute and a SaaS dispute look different on the surface and are the same underneath: a commercial promise, a financial transaction, and a record of what happened. Model that once and every vertical works. Model each vertical separately and you maintain forever.
That choice is the whole architecture. It runs in two phases.
Phase 1: the data foundation
Industry-agnostic on purpose, in three steps.
Ingest. Structured and unstructured data together: order rows and tracking numbers, but also support threads, receipts, screenshots, and terms of service.
Understand. Everything is interpreted against a domain schema, the model of what a transaction, a fulfilment, a customer, and a promise are. This is the part that transfers across industries, and it is the moat: the schema is what lets a new vertical work on day one instead of after a bespoke integration.
Contextualise. The result is not a pile of fields but a commercial and financial story: what was sold, what was delivered, what the customer did afterwards, and what they were told along the way.
Phase 2: dispute execution
Read the reason code and select a playbook. Reason codes are not interchangeable. Visa 13.1 asks whether the item arrived; a CE 3.0 fraud claim asks whether the cardholder is the person who has been shopping with you all year. Different questions need different evidence, so the playbook is chosen before anything is written. See Reason codes.
Draft the narrative strategy. The argument is decided before the paragraphs: which claim to refute, in what order, with which artefacts as the spine of the case.
Delegate to specialised agents. An orchestrator assigns the work: a transactions agent for payment and account history, a behaviour agent for how the customer actually used the product, a delivery agent for fulfilment proof, plus specialised agents where the case needs them. Each writes the part it is trained for.
QA before submission. A QA agent checks three things: are the facts supported by the collected data, does the case meet the card network's rules for this reason code, and is it structured the way the issuer expects. Anything failing goes back to the responsible agent for up to three rounds. If it still does not pass, a human on the Chargeflow team is alerted rather than a weak case being submitted.
Learn from the outcome. The issuer's letter and the win/loss result feed back into playbook selection and drafting for the next dispute of that type.
Why this beats a template
Templates encode last year's winning argument and apply it to this year's dispute. An agent that reads the reason code, the evidence available, and the customer's actual behaviour writes a case for the dispute in front of it. The side-by-side is in Evidence generation, and worked examples are in Evidence examples by reason code.