[ Kontor / Ledger / Kontor Ledger ]

Every penny, every version, provable.

Kontor Ledger is the system of record under every loan, card and line. Its design choices mean you never have to explain a balance with a spreadsheet.

View demo Read the regulatory map

[ Design ]

Three properties, enforced at write time.

Event-sourced

History is the source of truth

Balances are derived from an append-only stream of events. Replay the stream and you get the same answer, so a balance can always be explained line by line.

Double-entry

Every event balances to zero

Each event posts debits and credits across named accounts: receivables, interest, fees, suspense and scheme settlement. The ledger rejects writes that don't balance.

Bitemporal

Two clocks on every posting

Effective time records when something happened. Recorded time records when we learned about it. You can back-date corrections without rewriting history, and query any balance as of any moment.

Event	Debit	Credit	Amount
card.authorised	pending_auth	open_to_buy	$120.00
card.cleared	purchases_balance	scheme_settlement	$120.00
card.cleared	open_to_buy	pending_auth	$120.00
interest.accrued	interest_receivable	interest_income	$0.08

Every event posts balanced entries. The sum across all accounts is zero at every point in both timelines, and the ledger rejects any write that isn't.

[ Bitemporal ]

Late payments without rewriting history.

Payments arrive late, rates change retroactively and complaints get upheld. Kontor records the correction with its true effective date, recalculates interest from that date forward, and keeps what you believed at the time.

28 Feb

Effective

Customer pays €300 by bank transfer. Their bank is slow to send it.

02 Mar

Recorded

The ledger has already accrued two days of interest on the higher balance and issued a statement.

05 Mar

Corrected

The payment is recorded with an effective date of 28 Feb. Interest is restated. Nothing is overwritten.

GET /accounts/LN-20481/balance?effective_at=2026-03-01&known_at=2026-03-02

// what we believed on 2 Mar about 1 Mar: €8,615.35

// what we know now about 1 Mar: €8,315.35

[ Interest & accrual ]

Day-count is a setting, not a rewrite.

Each product declares its own day-count convention, accrual frequency, capitalisation point, rounding and grace rules, whatever its market expects. Rate changes carry an effective date and notice period, so accrual stays correct either side of the change.

ACT/365F
ACT/ACT ISDA
ACT/360
30/360

products/credit_card_standard_v7.json

{
  "product": "credit_card_standard_v7",
  "day_count": "ACT_365F",            // ACT_ACT_ISDA | ACT_360 | 30_360
  "accrual": { "frequency": "daily", "capitalise": "statement" },
  "rounding": { "mode": "half_even", "scale": 2 },
  "grace_period": { "purchases": "full_statement_paid" },
  "balances": [
    { "type": "purchase",  "apr": 24.9 },
    { "type": "cash",      "apr": 29.9, "grace": false },
    { "type": "transfer",  "apr": 0.0,
      "promo_ends": "P18M", "reverts_to": "purchase" }
  ],
  "allocation": "minimum_then_highest_apr",
  "rate_changes": { "effective": "bitemporal", "notice_days": 30 }
}

[ Payment allocation ]

Highest APR first, as standard.

Payments are allocated by a declared rule set per market, and the allocation is itself a ledger event. When a customer asks where their money went, the answer is one query.

£1,000 payment, minimum £150

surplus £850 → highest APR first

Cash advance 29.9%£400 of £400
Purchases 24.9%£450 of £1,800
Balance transfer 0% promo£0 of £2,400

The minimum covers interest and fees under the programme's own rule. Anything above it goes to the highest-rate balance first, the order both UK rules and US Reg Z require. The allocation order is itself market configuration, and each allocation is a ledger event with its own audit record.

[ Early repayment · UK pack shown ]

Payoff quotes that survive a complaint.

Settlement statement	Generated on request and sent within 7 working days (CCA s.97). Agents send it without approval.
Rebate calculation	Statutory rebate under the Consumer Credit (Early Settlement) Regulations 2004, with the settlement date deferral built in.
Compensation	s.95A compensation where the agreement allows it, capped at 1% (more than a year left) or 0.5%.
Partial settlement	The customer chooses to shorten the term or reduce the instalment. The schedule is regenerated and the old one kept.

[ Authorisation vs clearing ]

A hold is not a posting.

Authorisation	Places a hold that reduces open-to-buy. Nothing posts to the balance and no interest accrues.
Incremental & partial	Hotel and fuel incrementals extend the hold. A partial approval holds only what was approved.
Clearing	The presentment posts the purchase, matches it to the hold and releases it. Over- and under-clearing are posted within configured tolerances.
Expiry & reversal	Holds with no presentment expire on an MCC-specific clock. A 0400 reversal releases the hold immediately.
Force posts	Presentments with no matching authorisation still post and are flagged for review in Console.

Decision Engine

Origination, limits and real-time authorisation, decided in milliseconds with reason codes attached.

Agent Runtime

Supervised agents for disputes, collections, hardship and servicing. They act inside your policy.

Console

Policy as code, approval queues and a replayable audit trail. Where your people run the programme.

Run your credit book on Kontor.

Bring a product spec or a portfolio extract. We'll show you how the ledger, decisions and agents would run it, and what your regulator would see.

View demo Read the regulatory map