Rewards conformance and points liability assurance
Your points liability rests on a configuration nobody has ever checked against your contract.
Legal writes the terms. A platform team configures them, years later and several revisions on. Finance books the accrual off whatever that configuration produced. Nothing in that chain compares the system to the document.
We encode the published terms so they execute, recompute every transaction against them, and price the difference.
…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.
And the second one is not a single document.
What a card programme actually publishes sits in three layers. Only the bottom one is written per product — which is why the obligations that govern the most cards are the ones least likely to have been read recently.
Cardholder agreement
The governing contract. Referenced by everything below it, rarely revisited, and almost never supplied when someone asks for “the terms”.
Summary terms
The consolidated fee, charge and earn schedule — the key-facts or most-important-terms document. Usually one file for the entire book, often only as a scan.
Product terms
The card-specific rates, caps, accelerators and milestones. This is the layer everyone means when they say terms and conditions, and the only one anyone routinely checks.
One of many
Where the shared layers are configured once and inherited, a single defect reaches the entire portfolio. Where they are restated product by product, they are as many chances to diverge as you have cards. Either way nobody has tested them — and either way they only need encoding once, which is why the second product costs a fraction of the first.
What it does to the accrual
A configuration defect does not just cost money. It corrupts the estimate that measures what it cost.
Each period you charge the cost of points earned, carry the balance of points outstanding, and write that balance down by the share you expect will never be redeemed. All three numbers come out of the same system. A defect in that system reaches all three.
01
The periodic charge
Points awarded beyond what the terms require are expensed as though they were owed. The monthly cost of rewards is overstated by exactly the size of the defect, every month it runs.
Hits P&L02
The carried balance
Those same points sit in outstanding member balances. The liability is overstated by the portion not yet redeemed. That is a balance sheet misstatement, not a timing difference — it does not unwind on its own.
Hits the balance sheet03
The breakage rate
This is the one nobody sees. Points awarded in error are points no member knows they have, so they are never redeemed. They land in the denominator of your observed redemption rate and flatter your breakage assumption — which is the rate used to value everything else.
Hits the estimateBreakage is derived from a redemption population that the defect itself has contaminated. The error is measuring itself.
Revisions to a breakage assumption run through current-period earnings. So a defect that has been running for years does not sit quietly in a balance sheet line — it corrects into the income statement in whatever period somebody finally finds it.
Recomputation separates the two halves, because it knows which of the over-issued points were actually spent: the share still outstanding overstates the liability, and the share already redeemed is a cost that has already gone through.
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.
And what it does to the estimate
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 earnings. It is produced by a model rather than derived from the redemption population it describes — a population that the defect has already contaminated. So the error is not a one-off misstatement. It corrects into earnings, in whatever period somebody finds it.
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 finance and controls practitioner, not a loyalty vendor.
Thirty years in risk and control at global banks — counterparty credit, regulatory capital, algorithmic trading controls — and a prior CFO and COO seat at a wholesale bank. 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