07Decision engines

Decision engines — explainable, configurable, audit-trailed.

Most decisioning engines started as a Python script, became a 200-line nested if-statement, and now nobody dares change them. The business team wants new rules; engineering wants control; compliance wants explainability. The vendor product (Provenir, FICO, Experian PowerCurve) gets you 70% — at vendor pricing and vendor cycle times. The 30% it doesn’t give you is exactly the 30% your product needs.

FCA · UK CFPB · US FCAC · Canada EU AI Act
Discuss a build →See pricing
01 — Problem

Where decision engines builds usually go wrong.

Decisioning is the highest-leverage system in a regulated platform — and the one most often built as a side-effect of something else. The pattern is consistent: a working Python rule sheet evolves to a hundred lines of branching logic, then becomes the place where compliance, product and engineering have an annual fight about whether to buy Provenir, FICO or PowerCurve.

What we build is the third path: a configurable, explainable, audit-trailed decision engine that the business team can edit (within governance rails), engineering can ship safely (champion-challenger A/B), and compliance can defend (reasoned-decision records under GDPR Art. 22). Plus a clean migration pattern from the legacy script — or from a vendor product the firm has outgrown.

And, increasingly, the EU AI Act-aware pattern: credit scoring is a high-risk AI system from August 2026, with explainability, governance and monitoring obligations the legacy decisioning stack doesn’t meet.

02 — What we build

End-to-end, audit-ready, in production.

01

Configurable rule engines

Business-team-editable, versioned, A/B-testable rule engines — with governance rails around what each role can change.

02

Model-serving infrastructure

Score models alongside rules in one decision pipeline — with per-decision feature snapshotting and explainability.

03

Tiered decision flows

Auto-approve, auto-decline, manual review and decline-and-explain paths — with clean operator hand-off.

04

Reasoned-decision records

Every decision retains its rule path, model contributions, feature inputs and explanation — immutable and queryable.

05

Explainability layer

SHAP-style explanations for model decisions, rule-path explanations for rule decisions — both human- and audit-readable.

06

A/B testing for decisions

Shadow mode, champion-challenger, gradual rollout controls — so rule changes ship without rollbacks.

07

Pluggable data sources

Bureaus, Open Banking, alt-data, internal signals — exposed to the decision pipeline as a feature store.

08

Vendor migration

Provenir, FICO, PowerCurve to self-hosted (or to a better vendor) — with parallel-run validation and zero decision-continuity loss.

03 — Patterns

Build patterns we ship from.

Pattern A

Rules-and-models hybrid decision engine

One pipeline. Rules and models both contribute to the decision, both produce explanations, both are versioned.

Drools / OPASageMaker / Vertex AIInternal rule DSL
Pattern B

Reasoned-decision-record ledger

Event-sourced decision log — every decision is reconstructable from the inputs and rule version at the time.

Postgres event-sourcingS3 / GlacierInternal explainability layer
Pattern C

Champion-challenger A/B framework

Shadow-mode evaluation, traffic-split execution and per-decision attribution — so rule changes are validated before they affect customers.

Internal A/B serviceSnowflake / dbtOpenTelemetry
Pattern D

Decisioning-vendor migration pipeline

Parallel-run mode against the legacy engine, decision-diff reconciliation and progressive rollout with safety rails.

Diff serviceSnowflakeStep Functions
04 — Regulations

What this work has to comply with.

GlobalGDPR Art. 22UKFCA CONC (affordability)USECOA Reg B (fair lending)USFCRA Adverse Action NoticesCAOSFI Guideline B-13EUEU AI Act (Aug 2026)
05 — Stack

What we build with.

Rule engines

DroolsOPAInternal DSLGitHub / GitLab versioning

Model serving & ML

TensorFlow ServingSageMakerVertex AISHAP / LIME

Infrastructure

AWS Step FunctionsPostgres event-sourcingKafkaSnowflake / dbt
06 — Recent build

From a 200-line Python rule sheet to a configurable, audit-trailed decision engine in 8 weeks.

A UK consumer credit lender’s decisioning was a Python rule sheet that had grown to 200 lines over three years. Nobody on the team would touch it without a full regression run. Each rule change took ~3 weeks, and the compliance team had no defensible record of why any individual decision had been made.

We replaced it in eight weeks with a configurable rule engine on Drools, with the legacy rules ported as version 1.0, a model-serving sidecar for the affordability score, reasoned-decision records keyed to the rule version active at the time of the decision, and a champion-challenger framework that let the business team test rule changes in shadow before promoting them.

The first month after launch, the team shipped 9 rule changes through the champion-challenger framework — work that would previously have taken a full quarter. The compliance team’s first audit walkthrough of the new engine took 90 minutes and produced zero remediation items.

8 weeks
Build to production
9
Rule changes, first month
0
Audit remediation items
07 — FAQs

Questions we get every time.

What’s the right architecture for a rules-and-models decision engine?

Both contribute to the same decision through one pipeline. Rules handle deterministic logic (hard declines, regulatory cut-offs, fraud signals); models handle probabilistic signals (default prediction, fraud scoring, affordability). The decision-record format is the same regardless of which path drove the outcome — every decision retains its rule path, its model contributions, the feature inputs at the time of the decision and an explanation a human reviewer can read. Rules and models are versioned separately but together — a decision is reconstructable from rule version + model version + inputs.

How do you make decisioning explainable under GDPR Art. 22?

Three properties: (1) a reasoned-decision record per decision that’s human-readable; (2) per-decision model contributions (SHAP or equivalent), not just population-level model explanations; (3) an adverse-action notification flow that maps decision drivers to plain-language reasons. The reasoned-decision record is the centrepiece — it’s what you produce when the customer requests an explanation, what the regulator queries in a review, and what your compliance team uses when defending an outcome.

Can you migrate off Provenir / FICO without breaking decision continuity?

Yes, with parallel-run mode. The replacement engine runs alongside the legacy one for 30–90 days, both producing decisions on the same applications. Decisions are diffed continuously, root-cause analysis runs on every disagreement, and the rules / models are tuned until the disagreement rate is below the agreed threshold. Then the replacement engine takes traffic gradually — usually 5%, 25%, 50%, 100% — with rollback ready at any stage. Decision continuity is preserved because the legacy engine is still running for comparison the whole time.

What does champion-challenger A/B testing look like for credit decisions?

Shadow-mode evaluation first — the challenger runs on the same applications as the champion but the customer never sees the challenger’s decision. Disagreements are logged and analysed. Once the challenger meets the agreed criteria (decision agreement, portfolio-level outcomes, compliance review), it takes a traffic slice — typically starting at 5–10%. Outcomes are tracked per slice and the challenger is promoted to champion when the comparison is conclusive. The discipline is in deciding the promotion criteria up-front, not after the data lands.

How do you handle EU AI Act requirements for credit scoring models?

Credit scoring is a high-risk AI system under the EU AI Act from August 2026. The obligations include: a documented risk-management process, training-data governance, technical documentation, transparency to users, human oversight, accuracy / robustness / cybersecurity, and post-market monitoring. Most of this is buildable as platform capabilities once rather than per-model — risk-management dashboard, training-data lineage, model documentation generator, human-oversight workflow. The technical bar is genuinely meetable; the planning bar (deciding who in your firm is accountable for each obligation) is the harder part.

Scoping a decision engines build?

Send us a few sentences. We’ll come back inside three business days with a credible delivery plan and a date.