MindForge and the Next Phase of Fraud Decisioning

In January 2026, the Monetary Authority of Singapore (MAS) and a consortium of 24 banks, insurers, capital-market firms, and technology partners published the MindForge AI Risk Management Operationalisation Handbook — a 173-page playbook for putting responsible AI into financial-services operating practice. It is voluntary guidance. It is also a preview of how Southeast Asian bank procurement teams will frame their next round of vendor questions about anything that touches a model, a score, or an automated decision.

For fintech vendors selling decision software into the region, this is the inflection point. The conversation is shifting from “Does your AI work?” to “Show me the inventory, the explanation, the monitoring evidence, the change log, and who signs off when a model updates.” Principles are becoming paperwork — and the paperwork is becoming product architecture.

Run-True Decision builds a Fraud Decision Engine (FDE) for Southeast Asian banks. The MindForge handbook is not a regulatory bar we have to clear. It is the most useful operating language we have seen for describing what good fraud decisioning looks like when a regulated buyer asks. This post is our take on what MindForge changes, where we sit today, and what we are building next.

A note on framing: MindForge is industry guidance from a consortium that includes MAS. It is not an RTD certification, approval, or compliance status, and we do not represent ourselves as MindForge-aligned. We treat the handbook as a useful operating vocabulary for our own roadmap.

What MindForge actually asks of financial institutions

The handbook organises its guidance into four areas: scope and oversight, AI risk management, AI lifecycle management, and enablers. Beneath that taxonomy is a practical operating language any fintech team can use, regardless of whether their bank counterparty references the handbook by name.

For each AI use case inside an institution, MindForge encourages teams to:

• Define the use case. What decision does the system make or influence? Who is the customer-facing or business owner?
• Assess materiality. How much does a bad outcome hurt — customers, the firm, the system? Materiality dictates how much governance the use case earns.
• Assign ownership. A named human is accountable, end to end, for the lifecycle.
• Manage data and third-party dependencies. Where does training and runtime data come from? Which vendors are in the path? What happens if one of them changes?
• Test before deployment. Documented validation against representative scenarios — not just “it passed unit tests.”
• Monitor after deployment. Performance, drift, fairness, and error rates — observed, logged, and reviewed on a cadence.
• Keep human accountability visible. A reviewer, a maker-checker workflow, an audit trail, and a way to roll back.

What makes the handbook useful is that it does not invent a new vocabulary. It packages practices that mature engineering teams already do informally and asks institutions to make them legible: inventoried, documented, reviewable. It also gives equal treatment to traditional machine learning, generative AI, and emerging agentic AI — acknowledging that buyers will encounter all three in vendor stacks.

The shift is from “we have good engineers” to “we have evidence.”

What this means for fintech vendors selling into SEA banks

For banks and vendors in Singapore and nearby markets, MindForge is likely to influence sales and governance conversations even before it becomes a formal procurement checklist. Three shifts in particular are worth preparing for.

First, the vendor questionnaire gets longer. Procurement and second-line-of-defence teams will start asking for an AI inventory: every model, rule pack, scoring component, and automated decision path your product exposes. Even purely deterministic rule engines will get asked, because the bank’s own inventory needs to be complete, and the second-line team would rather log “no AI, rule-based” than skip the entry.

Second, the technical evaluation gets deeper. Expect questions like: “Can you produce a Decision Explanation Object for any decision your system made in the last 90 days?” “What is your maker-checker workflow for a policy change?” “How does a new model version get activated, and how do we roll it back?” “What monitoring do you ship by default?” Hand-wavy answers — “we have logs” — will not pass.

Third, the cadence gets ongoing. Today’s procurement decision is increasingly tomorrow’s quarterly review. Buyers will want change logs of what shipped, monitoring snapshots, and incident postmortems. Vendors who treat governance as a one-time RFP attachment will be at a structural disadvantage to vendors who treat it as a continuously published evidence stream.

Other Southeast Asian regulators and institutions may adapt similar language for their own contexts, but the current public signal is strongest in Singapore.

The challenge and opportunity for fraud-decision platforms

For a fraud-decision platform specifically, the MindForge framing is both a challenge and an opportunity.

The challenge is precision. Fraud decisioning intentionally blurs the line between deterministic rules, statistical scoring, and (in some platforms) machine-learning models. From a customer perspective the distinction can feel academic — the question is whether a payment got blocked or not. From a MindForge perspective the distinction matters enormously: deterministic rules are governed decision policy and need policy-change evidence; ML models need lifecycle evidence; generative AI assistants need default-off, sandboxed, sidecar treatment. Conflating them in marketing copy (“AI-powered fraud detection”) makes governance review harder, not easier.

The opportunity is trust. A fraud-decision platform that can produce, on demand: the exact rule pack that fired, the exact score that contributed, the named human who approved the last policy change, the signal lineage from raw event to outcome, and the audit log of who reviewed what — that platform answers the MindForge-shaped questions before the bank has to ask. In a market where every vendor claims to use AI, the differentiator is being able to show what kind of AI, governed how, with what evidence.

This is the posture we are building toward at Run-True Decision. We treat fraud decisioning as governed decision architecture first; the model substrate (rules, ML, ensemble) is an implementation detail beneath a stable evidence contract. Our platform overview describes the current decision-evidence surface in more detail.

Where Run-True Decision is today

Public readers should hear the current capability stated plainly, separated from what is in private evidence and what is on the roadmap.

Available now in the FDE platform:

• A governed rule lifecycle — material rule and configuration changes move through maker-checker workflows with audit logs, with remaining admin and tenant lifecycle gaps tracked separately.
• A public, stable risk-score contract — a 0-to-100 score with a four-decision display vocabulary (Accept, Step-up, Review, Block) that integrators can rely on.
• A public risk-evaluate integration contract — documented, versioned, exposed to partner systems.
• Decision evidence — audit logs, replay, and signal lineage for internal review of evaluated events, with a single public Decision Explanation Object still on the roadmap.
• Tenant controls, data isolation, and on-premise deployment options — designed to support data-residency requirements.
• A library of pre-configured banking fraud templates that customers tune, override, and govern through the rule lifecycle.
• Private MindForge baseline planning — internal evidence packs, gap analyses, and design notes that inform what we ship next.

Partial or roadmap (we name this honestly):

• External MindForge evidence sharing — customer-facing exports of inventory and lifecycle artefacts.
• A formal AI inventory export — currently internal, not yet a buyer-facing artefact.
• Public Decision Explanation Object / API exposure — today’s decision evidence is internal and on-request.
• Runtime ML registry consumption and model activation / rollback — under design.
• Full AI monitoring dashboards covering drift, fairness, and incident workflows — partial today.
• Third-party AI questionnaire automation — handled manually today.
• GenAI and agentic buyer-facing claims — we will not make these until the underlying evidence is in place.

Two specifics worth calling out explicitly. Our deterministic fraud rules are not AI; we describe them as governed decision policy with validation and rollback evidence. Our traditional ML scoring is partial — we ship gated lifecycle evidence, not production ML readiness claims. Any analyst-assist GenAI sidecar in our roadmap will be default-off, scoped to assistance (drafting case notes, summarising signals), and never permitted into the decisioning path without separate governance.

What comes next

Over the next several quarters we are working on what MindForge-readiness actually looks like as a product surface, not just a posture:

• A buyer-facing AI inventory export the second-line team can drop into their own register.
• A Decision Explanation Object exposed through the public API, so a bank can request, log, and store the structured rationale for any decision the FDE made.
• An AI/model card evidence pack covering every scoring component we ship — training-data lineage, validation methodology, monitoring plan, and known limitations.
• A monitoring and change-control plan published as part of the product documentation, not just internal runbooks.
• A third-party AI register that lists every model and provider in the FDE data path, with materiality flags.
• GenAI and agentic guardrails — defined, documented, and demoable — before we make any buyer-facing claim about either.

None of these are AI-powered. They are evidence-powered. They are how a fraud-decision platform earns the right to make AI-powered claims when the underlying lifecycle catches up.

The institutions piloting MindForge are not waiting for regulation. They are building the operating system for accountable AI ahead of it. For vendors in the fraud-decisioning space — including us — that is the right kind of pressure. It moves the conversation away from “AI” as a marketing prefix and toward decision architecture, evidence, and ownership.

Run-True Decision is preparing for this future by treating AI risk management as product architecture, not after-the-fact paperwork. The next time a Southeast Asian bank’s second line asks for an inventory, an explanation, a change log, and a monitoring snapshot — we want to assemble a scoped evidence packet from product records quickly, rather than reconstructing it from scratch late in the review cycle.

Run-True Decision is building a fraud decision engine purpose-built for Southeast Asian banks. Talk to us to learn more.