Configurable rule engines
Business-team-editable, versioned, A/B-testable rule engines — with governance rails around what each role can change.
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.
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.
Business-team-editable, versioned, A/B-testable rule engines — with governance rails around what each role can change.
Score models alongside rules in one decision pipeline — with per-decision feature snapshotting and explainability.
Auto-approve, auto-decline, manual review and decline-and-explain paths — with clean operator hand-off.
Every decision retains its rule path, model contributions, feature inputs and explanation — immutable and queryable.
SHAP-style explanations for model decisions, rule-path explanations for rule decisions — both human- and audit-readable.
Shadow mode, champion-challenger, gradual rollout controls — so rule changes ship without rollbacks.
Bureaus, Open Banking, alt-data, internal signals — exposed to the decision pipeline as a feature store.
Provenir, FICO, PowerCurve to self-hosted (or to a better vendor) — with parallel-run validation and zero decision-continuity loss.
One pipeline. Rules and models both contribute to the decision, both produce explanations, both are versioned.
Event-sourced decision log — every decision is reconstructable from the inputs and rule version at the time.
Shadow-mode evaluation, traffic-split execution and per-decision attribution — so rule changes are validated before they affect customers.
Parallel-run mode against the legacy engine, decision-diff reconciliation and progressive rollout with safety rails.
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.
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.
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.
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.
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.
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.
Send us a few sentences. We’ll come back inside three business days with a credible delivery plan and a date.