Contract integrity & program intelligence for loyalty programs
You know what your contract says. You have never seen what it did.
Your points engine implements the agreement. Nothing checks it against the agreement. We turn the contract into rules, run them against every transaction, and price every clause.
…the Issuer shall accrue points at ten (10) points per USD 100 of Net Eligible Spend, provided the effective accrual shall not exceed fourteen (14) points per USD 100 in any calendar month. Tier multipliers apply to Base Earn only, and promotional accrual is excluded from the cap in Clause 4.2…
Rules extracted 0
Base earn10 pts / USD 100 Cap14 pts / USD 100, monthly Multiplier scopeBase earn only ExclusionPromotional accrualEvery rule keeps the words it came from. Hover one.
The problem
Nobody compares the document to the data.
Commercial signs the contract. A vendor builds the rules. Finance pays the invoice. No one holds both ends.
The annual audit checks a few hundred. We check all of them.
A misimplemented rule is not an error — it is a consistent difference applied to every transaction it touches. Sampling cannot find it. It shows up as divergence.
Sec 3.3 — Points rounded down to the whole pointIssuance engine rounds up on 100% of fractional rows, zero exceptions
Issuer
0
0
Every month, every categorySchedule A — Qualifying dining at 2.0 pts per USDOne of four merchant codes paid at half rate from April onward
Cardholders
0
0
310,828 transactions, April to DecemberSec 4.6 and 4.2 — Annual price cap and tier selectionPrices above the ceiling all year; one month billed a tier late as a knock-on
Issuer
0
0
All three tiers, twelve of twelve months$0 found — and that is the floor, not the total.
Two of these findings are almost certainly larger. The price cap was measured against the 3% ceiling because the inflation series wasn’t in the file, and a fourth clause — the one that reprices the whole year when a volume tier is crossed — couldn’t be priced at all, because the settlement worksheet was never supplied.
So it flagged the breach, named the missing document, and stopped.
A number you can hand an auditor, and a silence you can trust.
Where the complexity lives
The difficulty is not the arithmetic. It is the count.
Every rate, cap, tier and exclusion below is contractually defined — and implemented by hand, once, years ago.
Card issuers
One agreement, deep clause structure. Caps, tier multipliers, promotional overlays, funding rates.
1 partner × 60+ clausesAirline and hotel
One currency sold to many partners at many prices, with liability carried on your balance sheet.
1 currency × 20+ rate cardsCoalition
Every partner both issues and redeems. Obligations run in both directions and net against each other.
12 partners × 132 positionsProgramme platforms
Operators running the same infrastructure across many bank programmes, each configured from its own documents.
1 platform × 20+ programsBuilt for any programme that awards a currency under written terms — issuers, airlines, hotels, coalitions, retail — and the platforms that operate them. Wherever a contract sets the rate and a system does the issuing, the two can diverge.
Divergence
A variance is an error. A trend is a term you no longer have.
Both parties are losing money, in opposite directions, and neither is made whole by the other. Through the first quarter the issuer overpays about $6K a month on rounding and price. In April a category mapping changes and cardholders begin losing roughly $28K a month. By December the two sides total $327,875 — nine months after the first invoice that would have shown it. Tier I measures and projects it.
A further tier-repricing credit is obliged by the contract but cannot be priced from the data supplied. It is excluded rather than estimated. Figures throughout are from a synthetic corpus built to validate the engine, not a client engagement.
Drift
What the contract requires against what the system issued, period over period. No model and no assumptions — it falls out of the document and the transaction file.
Breakage
Points that will never be redeemed, estimated from your own history rather than carried at a flat assumed rate. Needs data, not just the contract.
Which document
Two documents govern. Neither is ever checked.
Every programme runs on a written promise. Sometimes it is made to a partner, sometimes to a customer. In both cases a system implements it, and in both cases nobody holds the two side by side.
01
The partner agreement
Someone else calculates what you owe and renders a settlement. Tiered rates, category rules, caps, effective dates that shift each time terms are renegotiated. What arrives is a total.
Issuers buying miles · hotel and airline partners · coalition operators · franchise reimbursement
02
Your published terms
What you promised your own customers. Earn rates, exclusions, caps, expiry, milestone thresholds — drafted by legal, published by marketing, then configured by hand into a platform that nobody re-checks against them.
Any programme with its own currency · the platforms that configure them
Same failure either way: a document determines what should happen, a system does something, and no one compares them.
What it is worth
A miscoded rule is a recurring cost that runs until someone finds it.
Every point issued beyond what the governing document requires is a direct cost — an overpayment on a partner invoice, or an over-award against your own published terms. The exposure is a function of portfolio size and the size of the error, and it accrues every month until it is corrected.
Arithmetic, not a claim. The relevant question is which column a programme is in, and no one currently measures it.
The other side of the ledger
Breakage is not in the contract. It is management’s estimate of the points that will never be redeemed — revised every period, with revisions running through current-period revenue. It is produced by a model rather than derived from the redemption population it describes, which means an error is not a one-off misstatement. It corrects into earnings.
Movement in the liability for a 1, 3 or 5 percentage point error in the assumed redemption rate, at an assumed 80% redemption. Arithmetic again — but the assumption is the programme’s own, and the population that would settle it is already in the ledger. Tier II derives it.
Beyond the invoice
Once the contract is executable, it answers more than one question.
Recomputing the invoice is the first output, not the only one. The same encoded agreement and the same recomputed population answer a set of questions that are otherwise unanswerable — because until the contract is executable, there is nothing to ask.
All Tier I · available in the first engagementWhat each clause cost
The same rules run against the same year, reported clause by clause rather than as a total. Which terms fired, how often, and what each one cost or saved.
Tier 2 pricing applied in three months of twelve and cost $2.1m. The category cap bound twice and saved $340k.
Why the number moved
A settlement collapses volume, mix, currency, promotional overlays and rate into one figure. Separated, each movement is attributable — and each has a different answer.
Up $1.8m. Volume $0.7m, mix $0.5m, currency $0.4m, promotion $0.3m — and $0.1m at a rate the agreement does not support.
What happens next
The same rules read forwards. Where cumulative volume stands against a threshold, when a notice period falls due, which commitments are measured and when.
At current run rate you cross the next pricing tier in month eight, not month nine. Two partners reach a band they did not reach last year.
What other terms would have cost
Change one parameter and run the same year again. The transactions are fixed; only the terms move. Not a forecast — the same history under a term you did not sign.
At a 400m threshold the crossing moves forward two months, saving $310k. Applied retroactively rather than prospectively, the same clause is worth $1.5m.
The value is rarely the number. It is knowing which clause is worth spending negotiating capital on — and no programme knows that today, because nobody has priced their own terms against their own transactions.
These hold member behaviour constant: what the same year would have cost under different terms, against the same transactions. Where a term is visible to members, behaviour would itself have changed. That is stated, never modelled.
All of it comes from work already done. The agreement is encoded once and the population recomputed once. These are further questions asked of the same two things.
What we build
Two tiers. The second earns the first.
Nothing in the outer ring can be sold without the ring inside it. That is the constraint, not the pitch.
Conformance and drift
Your contract becomes executable. Then every transaction can be checked against it, every clause priced, and any change tested before it ships.
- Full population — no sampling
- Every variance traced to its clause
- Monthly files. No integration
- Clause attribution, scenario modelling, campaign pre-flight
Program intelligence
Questions that need your history, not just your contract.
- Breakage and liability, modelled
- Partner rate benchmarking across programmes
- Redemption-mix and cost-per-point derivation
Who does this
Built by a controls practitioner, not a loyalty vendor.
Thirty years in risk and control at global banks — counterparty credit, regulatory capital, algorithmic trading controls. The discipline is the same one applied here: a published obligation, a system that implements it, and evidence that the two agree.
- Independent of
- Every loyalty platform
- Method
- Full population, no sampling
- Findings validated
- With your team, before issue
The first engagement
One document. Four to six weeks.
Send one live agreement, or one programme’s published terms, with the records for the period it governs. You get the rederivation and the divergence read.
- You provide
- One contract, under NDA
- And
- Transaction files
- Duration
- Four to six weeks
- Integration
- None
- Live access
- None
- Your engineering time
- None