Proven on a tier-one cross-border payments business
FeeVerify ran on real production data for a tier-one cross-border payments business operating across multiple markets, with blended and IC++ acquiring. It turned 100+ contract packages into 228 expected-fee rules, re-costed 44M+ transactions from one month of data and traced a six-figure recurring variance to a single contract clause, 30 days from data ingestion.
What the engagement produced
From one month of production data, FeeVerify re-costed more than 44 million transactions against 228 expected-fee rules built from over 100 contract packages. In the first market, 92% of invoice lines tied out to a rule. More than 60 reports were written with every number linked to its source, and the diagnostic was ready 30 days after the data arrived.
The table sets out each figure with where it comes from. The largest single finding was a six-figure recurring variance, traced to one clause in one contract.
| Figure | What it counts | Provenance |
|---|---|---|
| 44M+ | Transactions re-costed against the rulebook, from one month of data | Engagement records, anonymised |
| 228 | Expected-fee rules extracted from the contracts, each carrying the excerpt it came from | Engagement records, anonymised |
| Over 100 | Contract packages: processing agreements with their schedules, addenda and amendments | Engagement records, anonymised |
| 92% | Invoice lines in the first market that tied out to an expected-fee rule | Engagement records, Market 1, anonymised |
| 60+ | Reports produced, every number linked to a clause or data row | Engagement records, anonymised |
| 6-figure | The recurring variance, traced to one contract clause | Engagement records, Market 1, anonymised |
| 30 days | From data ingestion to a diagnostic on real production data | Engagement records, anonymised |
What arrived
The business sent the material any multi-market payments business holds: processing agreements and addenda, invoices, transaction-level cost data and reconciliation files. The contracts came in several languages, some as scans and some with redlines still visible, and one month of data held more than 44 million transactions across blended and IC++ acquiring.
Nothing arrived in a form ready to check. Each contract package combined a main agreement with schedules, addenda and amendments, so the rate for a given transaction could depend on reading several documents together. The transaction and reconciliation files used their own codes and layouts, which had to be defined before any row could be priced.
What was rebuilt
FeeVerify rebuilt the business's expected cost from the contracts outward. Every fee the contracts permitted became a rule with its excerpt, 228 in all, and each transaction was then priced against the rules that governed it. In the first market, each billed invoice line was matched to the rule that permits it, and 92% tied out.
Pricing a transaction meant applying the right rate on the right basis: the processing fee, scheme and interchange pass-through, other charges and the tax on fees. Each rule kept the excerpt it came from, so a reviewer could check the reading against the contract wording. The Rulebook and Transaction Review agents did the high-volume work, and payments specialists checked the readings that mattered.
What was found
The largest finding was a six-figure recurring variance in the first market. It was traced from individual transactions back to a single clause that did not allow the charge as it was billed. Because the error sat in the monthly billing basis, it recurred every month until it was found.
The detail of the finding, like the client's name, stays confidential under our agreement with them. The findings shown elsewhere on this site use a fictional tenant, Meridian Payments, with synthetic figures, and none of them is drawn from this engagement.
How the findings were reviewed
Every finding went to the client with its evidence attached: the clause in its original language, the transactions behind it, the amount and a confidence grade. Because each rule carried its source excerpt, a reviewer could check a finding against the contract wording directly, without relying on anyone's summary of it.
That review step is a gate. AI does the high-volume analysis, material findings land in needs review, and an experienced payments specialist signs them off before anyone acts on them. No new headcount is needed on the client side. The governance page sets out who signs off and what is logged.
What the client kept
The client kept the rulebook of 228 sourced expected-fee rules, the variance analysis and the 60+ source-linked reports. The rulebook describes what the processor should be paying under its own contracts, so it can be run again on each new month of data instead of being rebuilt from scratch.
The engagement went from data ingestion to diagnostic in 30 days. A 30-day diagnostic on your own data is how a pilot starts: you see verified recoveries before any recurring fee, and continuous assurance is optional once the value is proven.
What this means for issuers
This engagement was on the acquiring side. Issuers ask whether the same method applies to them, and it does: scheme billing and interchange are rules-driven in the same way as acquirer pricing. The rules come from the scheme agreement and the published fee schedules, and every fee line is re-costed against them, exactly as here.
FeeVerify has not yet run in production for an issuer, and says so. The issuing banks page sets out what an issuer diagnostic covers: scheme billing, interchange earned on every cleared transaction, and incentives owed.
Start with one month of your own data.
A pilot begins with the agreements that protect both sides, then your contracts and one month of settlement data, scoped with a payments specialist on the first call. The 30-day diagnostic re-costs every transaction against them and shows each variance with its clause, before any recurring fee.