[ Kontor / Decide / Decision Engine ]

Decisions in milliseconds, with the reason attached.

The Decision Engine makes the credit decisions that can't wait: approving an application, setting a limit and authorising a payment. Every decision records its inputs, the rule version that applied and a reason code.

View demo Read the regulatory map

Origination

Affordability you can evidence

Bureau data, open banking income and expenditure, and your scorecard feed the creditworthiness assessment each market requires — UK CONC, EU CCD2 or US ability-to-pay. Each input is stored with the decision.

Limits

Limit changes with reasons

Increases are offered and decreases applied under policy, with notice periods enforced and customer opt-outs respected. Every change carries the principal reasons, ready for a UK customer letter or a US adverse action notice.

Authorisation

Approve or decline in milliseconds

Card status, open-to-buy from the live ledger, merchant and velocity controls, the fraud model and your rules all run inside the network's response window.

[ ISO 8583 authorisation ]

Inside the network's response window.

Kontor takes the 0100 directly from the network, decides against the live ledger rather than a cached balance, and returns the 0110. Advices, reversals and clearing reconcile against the same record.

Terminal / e-com

Card present or CNP

→ 0100

Acquirer

Builds 0100

→ 0100

Visa / Mastercard

Routes on BIN

→ 0100

Kontor Decision Engine

Decides

Request

MTI 0100 · DE2 PAN · DE4 amount · DE18 MCC · DE22 entry mode

Response

MTI 0110 · DE38 auth code · DE39 response code

Afterwards

0120 advice · 0400 reversal · clearing presentment

Where the milliseconds go

p50 38ms

Parse & card lookup4ms
Status & controls3ms
Open-to-buy (ledger)6ms
Fraud model14ms
Policy rules5ms
Persist & respond6ms

* Illustrative figures, to be replaced with audited numbers

Stand-in, by design

If a dependency degrades, the engine falls back to a reduced rule set you approved in advance: lower floor limits, conservative MCC blocks and no fraud model. It never returns a timeout to the network. Stand-in approvals are flagged for agent review once full service resumes.

Every decision is idempotent on the network's trace data, so retried 0100s never create duplicate holds.

[ Policy as code ]

Your credit policy, versioned and approved.

Rules are written in a small, reviewable language, tested against historical traffic before release, and approved in Console. A change goes live as a new version. The old version stays, so any past decision can be replayed against the rule that made it.

policies/auth/high-risk-mcc.rule

// policies/auth/high-risk-mcc.rule  · v14 · approved by risk 12 Sep
rule "cash-like MCCs on new accounts" {
  when  txn.mcc in ["6051", "7995", "4829"]
    and account.age_days < 60
  then  decline(code: "05", reason: "NEW_ACCOUNT_CASH_LIKE")
}
rule "step up large e-commerce" {
  when  txn.channel == "ecom" and txn.amount > 1_500_00
  then  challenge(method: "3ds", reason: "HIGH_VALUE_CNP")
}

DE39	Meaning	What Kontor records
00	Approved	All checks passed; hold placed on the ledger
05	Do not honour	Policy rule declined; rule ID and version logged
51	Insufficient funds	Open-to-buy below amount after pending holds
54	Expired card	Card past expiry; reissue status checked
59	Suspected fraud	Model score over threshold; step-up sent if eligible
91	Issuer unavailable	Never returned by Kontor; stand-in rules apply instead

Kontor Ledger

Event-sourced, double-entry, bitemporal. The system of record for every balance, accrual and fee.

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