MAS MindForge practitioner guide: operationalising AI governance for Singapore FSI

If you are a Head of Model Risk, CISO, or compliance director at a Singapore-regulated bank, insurer, or capital markets firm, you have probably seen three different “MindForge” decks in the last quarter. One from your consulting partner. One from a vendor claiming full coverage. One from your own risk team, still in spreadsheet form.

This guide is for practitioners who need to operationalise MAS expectations, not recycle slide titles. It is based on the public MindForge AI Risk Management Toolkit (Executive and Operationalisation Handbooks, launched at Singapore FinTech Festival 2025) and on what we see when FSI teams try to move from policy to evidence.

AgenticAssure is a General Member of the AI Verify Foundation and maps test results into MindForge-aligned reports. This guide stands on its own whether or not you use our platform.

What MindForge actually is (and is not)

Project MindForge is an MAS-led industry consortium initiative, not a statute. It builds on the 14 FEAT Principles (Fairness, Ethics, Accountability, Transparency) that MAS issued in 2018 for responsible use of AI and data analytics in financial services.

Phase 1 (2023) focused on generative AI risks for banks. Phase 2 expanded scope to banking, insurance, and capital markets, and to traditional AI, generative AI, and agentic AI.

The operative output for practitioners is the AI Risk Management Toolkit:

Executive Handbook — strategic framing for boards and senior management
Operationalisation Handbook — how to implement the 17 Considerations
Implementation Examples — anonymised FI case studies

MindForge is best read as supervisory-aligned operational guidance that will inform MAS’s evolving expectations on AI risk management. It is not a substitute for your existing technology risk, outsourcing, or BCM frameworks. It tells you what good looks like when those frameworks meet LLMs, agents, and third-party model APIs.

Common mistake: treating MindForge as a rebranded EU AI Act checklist. It is sector-specific, principle-led, and use-case granular. The EU regulation asks for conformity assessment and Annex IV technical documentation. MindForge asks whether your AI inventory, third-party AI procurement, and pre/post-deployment testing actually work for GenAI.

FEAT vs the 17 Considerations

FEAT is philosophy. The 17 Considerations are the operative checklist.

Layer	What it is	Practitioner use
FEAT (14 principles)	Fairness, Ethics, Accountability, Transparency	Board-level language, policy alignment
17 Considerations	Thematic recommendations grouped across oversight, lifecycle, enablers	Control design, evidence requests, thematic review prep
7 risk dimensions	Taxonomy for classifying AI-specific risks (Appendix B)	Risk materiality, KRI design, use-case assessment
MindForge Checklist (Appendix H)	Consolidated action list	Internal audit scoping

Not every Consideration maps 1:1 to a single FEAT principle. Several Considerations (inventory, guardrails, change management, skills, infrastructure) extend FEAT because GenAI and agentic systems introduced risks that 2018 FEAT did not contemplate.

The seven risk dimensions

MAS and the MindForge consortium organise AI-specific risks across seven dimensions (updated from the 2023 GenAI whitepaper taxonomy):

Accountability and Governance — who owns outcomes, escalation paths, policy adherence
Monitoring and Stability — drift, performance degradation, robustness over time
Transparency and Explainability — disclosures, interpretability, customer-facing explanations
Fairness and Bias — demographic parity, socio-cultural bias, disparate impact
Legal and Regulatory — IP, licensing, cross-border obligations, record-keeping
Ethics and Impact — customer harm, reputational risk, societal impact
Cyber and Data Security — prompt injection, data leakage, third-party API exposure

Practitioner note: use-case risk materiality (Consideration 5) should reference this taxonomy explicitly. If your risk register still only lists “model risk” and “cyber risk” without AI-specific sub-risks, thematic reviewers will ask how you classify hallucination-driven mis-selling, agentic tool abuse, or cross-tenant RAG leakage.

The 17 Considerations: what each one demands

Below is a practitioner reading of each Consideration from the Operationalisation Handbook, with the evidence type MAS-aligned reviewers typically expect.

Section 1: AI oversight (Considerations 1–3)

C1 — AI governance operating model. Board and senior management roles, three lines of defence, operating effectiveness measures. Evidence: governance charter, RACI, committee minutes showing AI on the agenda, not a one-page policy.

C2 — Governance documents. Policies and procedures that define AI concepts, lifecycle stages, and responsibilities. Evidence: version-controlled policy set, annual attestation, mapping to existing enterprise risk policy.

C3 — Enterprise risk framework uplift. AI-specific enterprise risks, appetite statements, KRIs. Evidence: risk register entries tagged to MindForge taxonomy, KRI dashboards with thresholds and breach history.

Section 2: AI risk management (Considerations 4–6)

C4 — Third-party AI risk. Procurement templates, vendor assessment, contractual change notification, access to AI expertise. Evidence: completed AI Card disclosures (Appendix E template) for each vendor model, due diligence records, subcontractor chain for hosted LLMs.

C5 — Use-case risk framework. Materiality assessment, inherent/residual risk scoring, controls commensurate with risk, pre/post-deployment reviews. Evidence: signed use-case risk assessment per AI system, linkage to control library, exception tracking.

C6 — AI inventory. Accurate record of new, updated, and decommissioned use cases. Evidence: inventory system of record (not a SharePoint folder), fields for model version, data sources, human oversight level, deployment environment.

Section 3: AI lifecycle management (Considerations 7–15)

C7 — Use-case context and design. Ethical/regulatory/organisational fit; governance tier by materiality. Evidence: design review sign-off, prohibited use case list, human-in-the-loop design decisions documented.

C8 — Data use evaluation. Intended data compatible with standards and law. Evidence: data lineage, lawful basis, consent where required, training vs inference data separation.

C9 — Data management practices. Processing risks and limitations addressed. Evidence: data quality metrics, bias testing on training data, retention and deletion procedures.

C10 — Third-party onboarding within use cases. Incremental risks when embedding vendor AI. Evidence: integration architecture diagram, subprocessors list, failover if vendor API changes behaviour.

C11 — Guardrails and metrics. Performance and risk metrics defined at build time. Evidence: metric catalogue aligned to Appendix F (Library of AI Metrics), refusal rates, hallucination checks, fairness metrics where applicable.

C12 — Pre-deployment testing and review. AI-specific risks tested before go-live. Evidence: adversarial testing results (MindForge explicitly includes red teaming), sign-off checklist, residual risk acceptance by risk owner.

C13 — Monitoring and contingency plans pre-deployment. Risk-informed rollout (canary, phased, kill switch). Evidence: runbook, rollback procedure, incident classification for AI failures.

C14 — Ongoing monitoring. Fit-for-purpose over time. Evidence: continuous monitoring logs, periodic re-validation schedule, drift alerts acted upon.

C15 — Change management. Traceability when models, prompts, tools, or data change. Evidence: change tickets linked to inventory IDs, material change re-approval, regression test results after each change.

Section 4: Enablers (Considerations 16–17)

C16 — Skills, knowledge, culture. Training for builders and reviewers; diverse governance teams. Evidence: training completion records, role-based curricula, hiring plan for AI risk skills.

C17 — AI infrastructure. Supporting infrastructure fit for purpose. Evidence: capacity planning, security architecture for GPU/API endpoints, environment separation (dev/staging/prod).

GenAI and agentic AI: what changed from traditional model risk

The 2023 MindForge GenAI whitepaper mapped risks across the lifecycle (design, development, deployment, monitoring). Phase 2 adds explicit language for:

Prompt injection and jailbreaks (Cyber dimension; Appendix G guardrails)
Hallucination and factual consistency (Monitoring and Stability; consistency checks in metrics library)
Tool and agent abuse (Accountability; excessive agency)
Multilingual attack surfaces (relevant for Singapore: English, Mandarin, Malay, Tamil prompts in red-team suites)

Traditional model validation (backtesting, champion/challenger, PSI on features) does not cover:

System prompt extraction
Cross-session context leakage
RAG poisoning via uploaded documents
Agent chains calling unauthorised tools

Practitioner rule: if your validation report predates ChatGPT-era architecture, it does not satisfy Considerations 11–12 for GenAI use cases. MAS does not require you to abandon classical model risk. It requires you to extend it.

Evidence architecture: what passes a thematic review

Thematic reviews punish three failure modes:

Policy without probes — FEAT principles in a PDF, no test artefacts
Point-in-time decks — evidence assembled the week before the meeting
Unverifiable claims — “we tested for bias” with no methodology, timestamps, or reproducibility

What reviewers increasingly expect (and what the Operationalisation Handbook points toward):

Evidence type	MindForge anchor	What “good” looks like
Inventory	C6	Machine-readable, versioned, linked to controls
Use-case risk assessment	C5, C7	Signed, materiality-tiered, FEAT-mapped
Pre-deployment testing	C12	Adversarial test report with methodology
Metrics and guardrails	C11, Appendix F/G	Defined thresholds, production monitoring
Third-party AI	C4, C10, AI Card	Vendor disclosures on file, updated on model change
Change traceability	C15	Every prompt/model update triggers regression
Examiner access	C1 (accountability)	Read-only verification without production write access

Slide decks are briefing material. Probes, logs, and signed assessments are evidence.

90-day playbook for compliance and model risk teams

Assumes one regulated AI use case in production (e.g. customer service GenAI, credit decision support, internal copilot). Scale horizontally after day 90.

Days 1–30: Inventory and honesty

Stand up or reconcile AI inventory (C6): every LLM, agent, RAG pipeline, embedded vendor API
Classify each use case by materiality (C5, C7) using MindForge risk dimensions
Gap-assess policies against C1–C3; do not rewrite everything, identify uplift areas
Request AI Cards from top three third-party model vendors (C4)

Exit criterion: inventory row for every production AI system, each with an owner and materiality tier.

Days 31–60: Test and instrument

Run baseline adversarial testing on highest-materiality use cases (C12): prompt injection, data extraction, jailbreaks, tool abuse if agentic
Define metrics catalogue (C11) from Appendix F: at minimum ISR/PSR for GenAI, hallucination checks for customer-facing, fairness metrics if decisions affect customers
Implement change detection (C15): any prompt, model, or tool change triggers re-test
Document monitoring and contingency plans (C13–C14)

Exit criterion: pre-deployment test report on file for each high-materiality system; monitoring dashboard live.

Days 61–90: Package for governance

Map test results and control status to FEAT and 17 Considerations (not narrative mapping, control IDs with evidence hashes or report references)
Conduct pre-thematic self-assessment: can an independent reviewer reproduce your C12 results?
Brief board risk committee with KRIs (C3), not vanity metrics
If EU exposure exists: crosswalk high-materiality systems to EU AI Act controls in parallel (separate track, same inventory)

Exit criterion: MindForge Checklist (Appendix H) self-score with evidence links; gaps have named owners and dates.

Common failure modes we see in Singapore FSI

Outsourcing evidence to the vendor. “OpenAI is SOC 2” is not C4/C10 compliance for your use case risk.
Treating RAG as ‘just retrieval’. Consideration 9 and cyber dimension both apply; poisoning is a lifecycle risk.
One enterprise chatbot policy for 40 use cases. C5 requires use-case-level assessment; materiality differs.
Annual model validation cadence on weekly prompt changes. C14–C15 require continuous monitoring for GenAI.
Fairness testing only on training data. Socio-cultural bias in production prompts (multilingual Singapore context) is a known MindForge metric category.
No examiner-ready access path. Building evidence the week MAS calls is worse than having gaps with a remediation plan.

APAC institution with EU exposure: run both tracks

Singapore and regional FSI increasingly serve EU customers or process EU personal data. MindForge and EU AI Act are complementary, not interchangeable.

Question	MindForge (Singapore FSI)	EU AI Act (cross-border)
Primary audience	MAS thematic review, board risk	Notified Body, EU deployers
Unit of analysis	Use case + FEAT alignment	System + Annex III classification
Evidence style	Considerations checklist, metrics, AI Cards	Annex IV dossier, conformity assessment
GenAI focus	Guardrails library, red teaming	GPAI obligations, systemic risk (if applicable)

Practical approach: one inventory (C6), two framework lenses. High-materiality customer-facing systems get MindForge evidence pack and EU AI Act conformity pipeline if EU persons are affected. Do not maintain two inventories.

Checklist: ready for a MindForge conversation?

Use this before your next board AI update or MAS engagement prep.

AI inventory complete with owners, materiality, and deployment status (C6)
17 Considerations self-assessed with evidence links, not RAG colours (all)
Third-party AI Cards on file for hosted models (C4, C10)
Pre-deployment adversarial test report per high-materiality use case (C12)
Metrics defined with thresholds; production monitoring active (C11, C14)
Change management ties prompt/model updates to regression tests (C15)
KRIs reported to risk committee with breach history (C3)
Examiner or auditor can verify evidence read-only without your team rebuilding it (C1)

Where AgenticAssure fits (optional)

We built AgenticAssure for practitioners who need continuous evidence, not annual attestations:

Discover inventories AI systems, agents, tools, and MCP servers (C6)
Test & Prove runs 34 attack techniques including multi-turn jailbreaks, mapped to OWASP and MindForge cyber risks (C11–C12)
Analysis produces MindForge-aligned framework reports and AI Verify AIVTF crosswalks
Assurance maintains live compliance posture and immutable audit log
External Auditor Seats give examiners time-boxed, read-only verification (C1 accountability)

Start with Discovery (free) to map your estate in an afternoon. When you are ready for a walkthrough of MindForge evidence mapping, book a demo.

Sources and further reading

Manish Chawda is Founder & CEO of AgenticAssure, CISSP/CISM/CRISC, and a General Member of the AI Verify Foundation. He previously built Pragma Pte Ltd across 12 countries in APAC cybersecurity.