What we ship, month by month.

Banking Investigation Workflow Readiness

Run-True Decision now gives bank fraud teams a clearer path from alert triage to case review, decision replay, quality review, and follow-through without asking frontline analysts to work through every governance screen during daily case handling.

What's New

• •Analyst-first case workflow. Case views emphasize the immediate investigation question first: what happened, which evidence matters, and what action should happen next.
• •Role-shaped follow-through. The workflow separates frontline case review from control-owner follow-through, so rules, experiments, and pipeline governance do not crowd the analyst's primary review path.
• •Investigation evidence exports. Pilot evidence packs and case quality review artifacts make it easier to review decision history, replay evidence, labels, and operational follow-up outside the live dashboard.
• •Demo-tenant readiness controls. Controlled synthetic replay and evaluation-demo access help teams walk through realistic examples without mixing demo controls into daily analysis.

Improvements

• •Added investigation work queue and SLA-operation foundations for repeatable fraud-operations workflows.
• •Added replay and lineage surfaces that help explain which signals, entities, rules, and decisions contributed to a case outcome.
• •Improved mobile case layout behavior so investigation screens remain usable on narrower displays.
• •Clarified preparation and enablement actions for controlled evaluation demos.

Fixes

• •Hardened demo-tenant readiness so tenant configuration and simulator access stay scoped to the intended tenant.
• •Added release version visibility to make evaluation-environment checks easier to trace.

Decision Change Packages

Run-True Decision now lets risk teams review related decision-logic changes as one governed package instead of chasing separate approvals across features and rules. Makers can assemble eligible changes into a package, submit it for review, and give reviewers one place to inspect the full change set before it moves into shadow approval.

What's New

• •Governed change packages. Related feature-definition and custom-rule changes can be bundled into a single maker-checker review unit.
• •Packages workspace in Decision Governance. Operators can create packages, attach eligible pending changes, submit for review, and inspect package status from a dedicated Packages tab.
• •Package-aware review queue. Submitted packages appear in the shared governance queue as one approval item, with direct links into package detail.
• •Shadow approval visibility. Reviewed packages preserve their package lifecycle state, including shadow-approved outcomes, so teams can distinguish review approval from live promotion.

Improvements

• •Attached package items no longer appear as loose approval rows while the package is open, keeping reviewer counts and queue totals clean.
• •Package review timing now rolls into the shared governance review metrics as one logical review, not one review per package item.
• •Package audit rows are visible in the shared governance audit view while item-level audit evidence remains tied to the underlying feature or rule.
• •The package workspace includes role-aware controls, deep links, status filters, and English, Indonesian, and Thai interface copy.

Fixes

• •Hardened package queue counts and review metrics so bundled changes are not double-counted.
• •Removed a stale frontend permission gate from the package review path.

Decision Governance Center & Feature Control

Run-True Decision now gives fraud and risk teams a governed way to change decision logic without losing reviewer context. Makers can keep working from the relevant object pages, reviewers get one shared queue for approvals, and auditors get a stronger history of what changed, who reviewed it, and what evidence was created along the way.

What's New

• •Decision Governance Center actions. Reviewers can approve or reject pending changes across Lists, Features, Rules, and Scoring Strategy from one shared queue, while each object page keeps its local maker workflow.
• •Governed list batch imports. CSV list imports can now be staged for review, approved transactionally, applied to the list, and synced to the runtime cache after approval.
• •Audit evidence and export. The governance ledger now supports stable event identities, filters, CSV export, and evidence views for governed list-import changes.
• •Feature shadow lifecycle. Custom derived features can move through approval into shadow observation before promotion, so teams can inspect runtime health before a feature affects live decisions.
• •Tenant feature controls. Global derived features can be disabled or kept shadow-only for a tenant through governed proposals, review, and audit history.

Improvements

• •Reviewer deep links now open the right object-local approval context across Lists, Features, Rules, and Scoring Strategy.
• •List and Feature approval history now supports reviewed statuses, pagination, focus recovery, and clearer empty states.
• •Review timing and queue health are visible on reviewed governance rows, with compact summary metrics for reviewer operations.
• •List-import evidence now durably links approvals to the immutable list entry versions created by that approval.
• •Approval pagination and count displays were hardened so reviewer pages stay consistent during concurrent review activity.
• •Locale coverage now guards the approval empty-state copy across English, Indonesian, and Thai.

Fixes

• •Closed tenant-scope gaps on list approval review paths and related Decision controls.
• •Prevented unsupported list approval actions from being approved before full batch-import semantics were available.
• •Fixed inconsistent list approval row and count reads by returning approvals and counts from one database statement.
• •Removed rollback-only Feature approval copy after the replacement status-aware strings were validated.
• •Added tests to prevent approval empty-state locale keys from regressing.

Sprint 1 — Audit-Ready Decision Logs

Banks running Run-True Decision can now answer the question every internal audit team eventually asks: “Show me exactly why you made this decision.” Decision audit records are now captured for evaluation requests — with encrypted sensitive fields and privacy-preserving lookup — and analysts can replay past decisions to see how today’s rules and models would have scored them differently. This is the foundation for backtesting, audit trails designed for internal review, and rule-change confidence.

What's New

• •Decision Audit Records. Decision audit records are now written for evaluation requests, capturing inputs, rule outputs, and the model versions in effect at decision time. Designed to support data residency requirements — your audit data stays where your decision data is.
• •Audit Replay. Replay past decisions against the current rule set and model. Returns a verdict showing whether the result matches, drifted, or changed because of a rule update or a model update.
• •Drift detection across rule and model versions. When today’s engine produces a different result than the original decision, the system tells you precisely whether the change came from a rule edit, a model update, or both — so you can defend a rule change in a control-committee review.
• •Role-based access for analyst replay workflows. A new permission gates who can run replays, separating day-to-day operators from senior analysts performing rule-change reviews.

Improvements

• •Encoder path tuned for banking-mode traffic — designed for millisecond-level overhead on the live decision path.
• •New command-line tool for one-off audit replay against any historical decision ID.
• •Tightened end-to-end test coverage on the audit persistence path so audit logs survive partial outage scenarios.

Fixes

• •Resolved an edge case where a transient persistence error could mask the underlying audit-record failure mode.

Billing & Metering Hardening

For banks running Run-True Decision on-premise, billing transparency matters as much as decision accuracy. This release ships audit-ready metering reports with HMAC-validated metadata so finance, procurement, and compliance teams can independently verify usage records without trusting vendor-supplied summaries.

What's New

• •Audit-ready billing reports with HMAC-validated metadata. Every billing report carries an HMAC signature so on-premise customers can verify the report wasn’t modified after generation.
• •In-dashboard audit UI for reviewing past metering reports, exporting them for procurement, and downloading the signed evidence file.
• •Role-based access — billing access is scoped separately from fraud-operations access, so finance can see what they need without seeing PII.

Improvements

• •Command-line verification tool included for offline procurement reviews.
• •Period-boundary handling tightened so usage rollups match exactly across all timezones.
• •Reports designed to support data residency requirements — the audit chain stays in your infrastructure.

Native Agent Integration (MCP)

Run-True Decision is one of the first fraud decision engines to expose a native MCP (Model Context Protocol) interface, letting AI assistants and analyst copilots query the engine directly through standardized tool calls. Fraud teams can wire the engine into Claude, ChatGPT, and other agent runtimes without building a custom integration.

What's New

• •Native MCP server with a curated set of tools — evaluate_risk, submit_outcome, submit_fraud_label, and check_health — available through configured RTD credentials and approved tool access.
• •Bearer-token authentication so each agent runtime gets a scoped, revocable identity rather than sharing the engine’s primary API key.
• •Governed tool surface — agent workflows remain subject to tenant policy, authentication, and audit controls; write actions are tracked alongside the dashboard’s existing maker-checker approvals.

Improvements

• •Tooling hardened to handle multi-tenant access cleanly so a single deployment can serve multiple business units without crossing data boundaries.
• •Test coverage extended to verify agent-issued queries against the tenant isolation design.

Adversarial QA Framework

Fraud detection is the only product category where the user is actively trying to break it. We built an adversarial QA framework that runs a structured red-team pass against the engine — designed to catch the structural blind spots traditional regression tests miss.

What's New

• •Red-team and green-team test harness that exercises the engine against known fraud patterns and adversarial mutations.
• •Dashboard surfacing of adversarial run results so analysts can see exactly which mutations were caught and which slipped through, alongside their normal investigation views.
• •Structural-gap detection that flags scenarios the rule library doesn’t yet cover — surfaces gaps before a real attacker finds them.

Improvements

• •Test data generation pipeline rebuilt to mix synthetic and real-shape transaction patterns so coverage maps to actual SEA market behavior.
• •Run reports formatted for control-committee review — a standing artifact for every release cycle.

Banking Fraud Templates Library

A pre-configured library of banking fraud templates is now live, covering the scenarios SEA banks asked for most often during pilot conversations: account takeover, wire-transfer scams, structuring patterns, and authorized-push-payment fraud. Banks can deploy the library out of the box and tune individual templates without writing code.

What's New

• •Pre-configured banking fraud templates for wire, account takeover, structuring, and APP-scam scenarios. Built from real bank requirements.
• •No-code rule editor — fraud teams can adjust thresholds, add carve-outs, and shadow-test new templates from the dashboard.
• •Cross-cut signals that fire alongside domain rules to catch scenarios that single-rule logic misses (for example, beneficiary-familiarity scoring on wire transfers).
• •Shadow mode for every template — see what would have triggered before promoting a rule to production.

Improvements

• •Rule editing flows tightened around a maker-checker approval pattern so a single analyst can’t unilaterally change production rules.
• •Backtesting hooks added to the no-code editor for “what would have happened” analysis.
• •Audit trail on every rule change so a control committee can reconstruct the rule history.