Why AML credits shouldn't expire
TL;DR
- Expiring credits create a structural tax on firms with lumpy onboarding — which is most small and mid-size Tranche 2 practitioners.
- The 'AML data goes stale' argument is about scan freshness, not credit freshness — a never-expiring credit does not force anyone to use a stale scan.
- Ironbark encodes never-expire at the database level. It's not a promotion. It's the product.
- If the policy ever changes, it goes through the same public change log as the Trust Score methodology.
The shape of a Tranche 2 workload
Accountants, lawyers, and real-estate principals do not onboard clients at a steady monthly rate. Onboarding peaks around end-of-financial-year for accountants, around settlement windows for real-estate agents, and around whatever court or commercial deadline is driving work for lawyers. The distribution is lumpy by nature.
A 50-credit pack bought in March with a June deadline might be half-spent by May and fully spent by July. A 50-credit pack bought in January with no March deadline might still have 35 credits on it come December — and if the provider runs a 12-month expiry, those 35 credits vanish at year-end. The firm then buys another pack.
The mathematical outcome: firms with steady, predictable workflows pay the advertised rate. Firms with lumpy workflows pay a premium because some portion of every pack is forfeited. The premium gets worse the smaller the firm.
The 'stale data' argument
The most coherent defence of credit expiry is that stale credits encourage stale scans. If you bought a pack two years ago and just spent the last credit on a new client, the reasoning goes, your compliance posture is degraded — you're relying on an old data subscription for a fresh screening decision.
The problem with this argument is that credit age and scan age are different things. A credit is a unit of prepaid capacity. A scan is the real-time result of hitting the current data feeds. The credit you buy in 2024 and spend in 2026 generates a scan against 2026 data — not 2024 data. The provider's data is refreshed continuously regardless of when the credit was purchased.
So the "stale data" rationale collapses into the real rationale: forcing renewal conversations. Which is a legitimate commercial objective — just not one that should be disguised as a compliance concern.
What Ironbark does instead
Ironbark credits never expire. This is encoded in two places:
- The
credits_ledgerschema in Postgres has no expiry column. Spending a credit decrements the balance; nothing removes credits from a balance except spending. - The pricing page and the PAYG tier description both state "credits never expire" without qualification. It's not a promotional offer. It's the product.
If Ironbark ever wanted to change this policy, the change would go through a public change log — the same discipline applied to the Trust Score methodology. Customers would be told before the policy changed, not after. Existing credits would be grandfathered on the old policy.
Why make this commitment? Because the thing Ironbark is trying to sell is trust, and trust compounds from small decisions. A product that tells you your credits might disappear after a year is a product you mentally budget against. A product that tells you your credits will still be there whenever you need them is one you stop thinking about — which is the correct relationship to have with a compliance utility.
Objections
"Credits that never expire mean people hoard them." Possibly. Hoarded credits are still paid for — the revenue has already been booked. The provider's only commercial concern is spending-volume skew, which is a forecasting problem, not a pricing problem.
"We need annual renewal conversations." Fine — have them via subscription tiers. Professional and Business subscriptions auto-renew; if a customer wants the monthly allowance, they stay subscribed. PAYG credits sit on the account separately.
"What about fraud — buying credits cheap today and using them at tomorrow's prices?" AML screening is not a commodity with speculative pricing arbitrage. A scan costs what it costs; the volume of scans purchased at one price versus another is noise at our scale.
Frequently asked
Why is 12-month credit expiry a common default?
Two reasons. First, it's a common SaaS-billing default — easy to implement, forces annual renewal conversations. Second, expired credits are a cashflow tailwind: the provider keeps the revenue but doesn't have to deliver the service.
Is credit expiry ever genuinely justified?
The strongest argument is that AML data ages — a 12-month-old scan against a changing sanctions list is no longer reliable. But this argument is about the freshness of the scan, not the freshness of the credit. A never-expiring credit doesn't force you to use stale data — it just lets you buy capacity once and spend it when you need it.
Will Ironbark change this policy later?
No. The pricing commitment is encoded in the credits_ledger schema at the database level and in the public pricing tier. If Ironbark ever reconsiders the policy — which we don't intend to — it would be announced publicly with notice, the same way our Trust Score methodology is versioned via a change log.
Does no-expiry apply to subscription credits too?
Professional and Business tier subscriptions include a monthly allowance (300 and 1,000 scans respectively). Unused scans in a month do not carry forward on subscription — they're included in the monthly fee. Any PAYG top-up credits purchased separately never expire.
What happens to my unused credits if I cancel?
Any PAYG credits on your balance remain usable until spent. Cancelling a subscription does not invalidate PAYG credits — they sit on the account indefinitely.
See the pricing
Free tier at 10 scans per month. PAYG at $0.49 per scan ex-GST. Professional and Business monthly tiers. Credits never expire across every tier that has them.