Card and banking rewards with ledger discipline.
Card-linked earning, tiered relationship rewards and redemption marketplaces — engineered for reconciliation and audit.
- Model the programme
- Connect the estate
- Parallel run and reconciliation
- Earn first, then redeem
- Operate and optimise
A bank’s rewards programme is a liability account with a marketing department attached.
Finance wants a points number it can sign at quarter end. Audit wants to trace any movement back to the transaction that caused it. Cards wants a campaign live on Thursday. The card processor sends authorisations in real time and clearing in overnight files, and the two disagree often enough that someone keeps a reconciliation spreadsheet nobody is proud of.
Loyalty & Retention for banking is the engine configured for that reality. Card-linked accrual by MCC, merchant and campaign runs on the transaction stream. Relationship tiers read deposits, cards and investments from core banking. Redemption — miles, cashback, catalogue and pay-with-points — sits on one ledger with one liability view. Every movement carries its rule version and source reference, so reconciliation is a report over the ledger rather than a monthly argument.
Reconciliation, audit trails and access control are part of the engine. Compliance reviews start from evidence, not promises. The same team that built it operates it, on the cloud and region you choose, GDPR / KVKK compliant.
Six modules, configured for banking economics.
Each module reads and writes the same member ledger, so a point earned on a card swipe, spent in the marketplace and reported to finance is one fact with one audit record.
Card-linked earning
Transaction-stream accrual with MCC, merchant and campaign rules — settled to the cent. Authorisation feeds create provisional earn; clearing confirms or reverses it, so a declined or refunded purchase does not leave points behind.
Relationship tiers
Rewards across products — deposits, cards, investments — designed to drive multi-product depth. Tier qualification reads balances and product holdings from core banking, and the ladder is a versioned document you simulate before you publish.
Redemption marketplace
Miles, cashback, gift catalogue and pay-with-points — one liability view underneath. Each redemption is reserved, then committed or released, so a failed fulfilment does not strand a balance.
Fraud-aware flows
Velocity checks and anomaly signals on earning and burning — abuse contained by design. Thresholds and holds are configuration; flagged movements queue for review with the evidence attached.
Auditable ledger
Every point movement traceable and reconcilable, for finance and audit. Movements are append-only, carry rule version, actor and source reference, and export to your GRC tooling.
Core-banking integration
Patterns for core-banking and card-switch estates, batch and real-time. Authorisation streams, clearing files and statement events arrive through governed contracts with replay and dead-letter handling.
What it does, in detail.
Earning that agrees with the card processor.
Card programmes fail quietly on the gap between authorisation and clearing. The engine treats them as two events on the same movement: authorisation creates a provisional earn the member can see, clearing confirms the amount and settles the points, and a reversal or chargeback unwinds them with a linked record. Each transaction is keyed by its processor reference, so a replayed file does not double-credit. When the month closes, every point on the ledger points back to a cleared transaction, which is what reconciled-to-source means in practice.
- Rules by MCC, merchant, card product and campaign window — configuration with a version history
- Provisional, confirmed and reversed states on one movement, visible to the member and to finance
- Replay tooling for late or corrected clearing files, with the difference reported rather than hidden
Tiers that read the whole relationship.
A card-only tier rewards spend. A relationship tier rewards depth — the customer who holds a current account, a card and an investment product is worth more than the sum of the three, and the programme should say so. Qualification rules read product holdings and balances from core banking on a schedule you set. The ladder itself is a versioned document: thresholds, qualification windows, soft-landing rules and the multiplier each tier earns. Simulate a proposed ladder against last year’s transactions, see who moves and what it costs, then schedule it.
- Qualification on spend, balances, product count or any combination — configured, not coded
- Soft landings and status extensions as settings, with the reason recorded on the member
- Simulation on historical data before any ladder change reaches a customer
One marketplace, one liability number.
Miles transfers, cashback to account, a gift catalogue and pay-with-points at checkout are four redemption channels with four cost bases. Underneath them the engine keeps one ledger. A redemption reserves points first, commits when the partner or fulfilment confirms, and releases if it fails — so a member does not see a balance vanish for a transfer that did not happen. Redemption runs to a latency budget agreed with you and measured at p95, and liability is reportable by currency, channel, partner and expiry bucket at any moment.
- Airline and hotel partner transfers with per-partner rates, caps and settlement calendars
- Cashback credited to the member’s account through the core-banking contract, not a manual file
- Breakage and expiry policy as configuration, with the finance impact simulated first
Built to contain abuse before it reaches the ledger.
Rewards abuse is a cost line until it becomes a headline. The engine checks velocity and anomaly signals on both sides of the ledger: earn spikes from a merchant that suddenly looks like a points farm, redemption bursts from a newly registered device, transfer patterns that match known laundering shapes. Flagged movements are held, not lost, and queued for review with the evidence attached. You tune the thresholds, and every hold and release is on the audit record. The rules shown here are examples.
- Velocity limits per member, card, merchant and device — as configuration
- Anomaly scores from the same model layer that drives retention, trained on your history
- Held movements resolve through a review queue with four-eyes approval where you require it
Example rules. Yours are configured with you.
One programme, four seats.
Campaigns go live without a release.
Bonus-earn campaigns by MCC, merchant or card product are configured, simulated and scheduled in the console. Budgets and caps are enforced at earn time, and each campaign carries a holdout so uplift is measured against a control group rather than against last quarter.
- Campaign calendar with budgets and per-member caps
- Holdout on every campaign, uplift on one screen
- Consent state checked at send time
A liability number you can trace.
Every movement carries its rule version, channel, partner and cost basis. Liability, breakage and partner settlement are reports over the ledger, reconciled to the cleared transaction — so the quarter closes from the system, not from a spreadsheet beside it. The CFO sees the measured effect of retention spend, not just the cost.
- Liability by currency, channel and expiry bucket
- Settlement statements per partner and period
- Audit export to your GRC tooling
Evidence first, then the conversation.
Role-based access, four-eyes approval on rule changes, an append-only ledger and a complete audit trail over every movement. Compliance reviews start from the export, and the platform is operated to the same controls on every programme. See security & compliance for the full set.
- Who changed which rule, when, and what it replaced
- Held and released movements with the reviewer recorded
- Data residency in the region you choose, GDPR / KVKK compliant
Governed contracts, replay and end-to-end traces.
Your estate publishes card and core-banking events; the engine consumes them idempotently and publishes ledger events back. Kafka topics with versioned schemas, an outbox on every write, dead-letter queues, replay tooling and OpenTelemetry traces end to end. A sandbox tenant runs your real traffic shape before anything touches a customer.
- REST and event APIs with versioned schemas
- Batch clearing files and real-time authorisations on one path
- Runbooks, SLOs and dashboards shared with your ops centre
Where it sits in a banking estate.
What ships in the box, and what is configured per bank.
Patterns for core-banking and card estates.
Card switch & processor
Authorisation streams and clearing files matched on processor reference; reversals and chargebacks linked
Core banking
Product holdings, balances and statement events for tier qualification and cashback credit
Mobile & internet banking
Balance, history and redemption embedded through REST and GraphQL with your design system
CRM & marketing
Segment sync and campaign delivery via email, push and SMS providers with consent enforced
Airline & hotel partners
Points transfer with per-partner rates, caps and settlement statements
Fraud & risk systems
Anomaly signals exchanged both ways; holds surfaced to your case tooling
Identity
Customer identity across channels
Data warehouse & BI
Ledger events exported to Snowflake, BigQuery or your lakehouse; Power BI models
Configured to your portfolio, step by step.
Model the programme
Card products, MCC rules, tier ladder, marketplace channels and expiry policy configured against your current programme design. Golden-master tests pin the behaviour of the existing engine, quirks included.
Connect the estate
Card-switch authorisations, clearing files and core-banking events flow into a sandbox tenant through governed contracts. Your real traffic shape runs before any customer is touched.
Parallel run and reconciliation
The engine shadows the legacy calculation on live traffic until outputs match the record, exception by exception. Balances and history migrate with a signed reconciliation.
Earn first, then redeem
Segment by segment, every step reversible and every rollback rehearsed. The cutover is designed to avoid a programme freeze or a customer-facing gap.
Operate and optimise
Attrition models and campaign measurement turn the running programme into a retention engine, operated to SLOs and incident cover agreed with you according to your needs, with dashboards shared with your ops centre.
Frequently asked questions
One engine, five verticals.
See it on your own data.
A guided demo with an engineer who operates the platform — configured toward your programme, not a canned deck.