A guide for chief risk officers, heads of third-party and vendor risk, chief information officers, chief data and AI officers, and procurement leaders in Singapore's financial sector. On 7 October 2026 the Monetary Authority of Singapore issued its Guidelines on Artificial Intelligence Risk Management. This article covers the part most institutions are least ready for: the AI you did not build, did not commission, and in many cases did not knowingly buy.
The short answer
The reason this is hard is not the policy. It is that most institutions cannot answer the first question. They do not know how much AI is already running inside the software they bought, because nobody sold it to them as AI.
What changed on 7 October 2026
That is a twelve-month runway for the first tranche, which covers oversight, identification of AI use, risk materiality assessment and the AI inventory. The second tranche, covering life cycle controls and capability, follows a year later.
Two things about the sequencing are worth noticing. First, identification and inventory come in the first tranche. That is deliberate, and it is the right order, because you cannot apply a control to something you have not found. Second, the Guidelines are principles-based rather than prescriptive. They tell you what to achieve and leave the method to you, which is generous and uncomfortable in equal measure.
MAS also confirmed in its media release that institutions do not need to set up a dedicated AI committee to satisfy the oversight expectations. Existing governance structures can be used where they genuinely provide adequate oversight and cross-functional coordination. And MAS said it intends to consult the sector further in 2027 on what additional guidance on agentic AI would help.
The Guidelines sit alongside, not instead of, what already applies. The Fairness, Ethics, Accountability and Transparency principles continue to apply to AI in the financial sector. MAS expectations on outsourcing and the use of third-party services apply to third-party AI as well. So this is an addition to your third-party risk obligations, not a replacement for them.
What counts as third-party AI?
Think of it like asbestos in a building you bought. You did not install it. It was not on the invoice. It is still yours to find, assess and manage, and nobody will accept that you did not know as an answer.
In practice, third-party AI reaches an institution by three different routes, and most risk functions are only set up to catch the first.
Route one: AI you deliberately bought
A fraud model, a document-processing engine, a customer service assistant. This went through procurement as AI. It is probably in a register somewhere. This is the easy case and it is not where the exposure is.
Route two: AI embedded in software you already own
The Guidelines are explicit about this one. They give the example of software-as-a-service that is not explicitly sold as AI but contains AI features that an institution can access or use as part of consuming the service. Your core system vendor adds a summarisation feature. Your HR platform adds candidate ranking. Your collaboration suite turns on a copilot across the whole tenancy.
Nobody raised a procurement request, because nothing was procured. The contract did not change. Your spend did not change. What changed is that a machine-learned system is now producing outputs that someone in your institution is relying on.
Route three: AI nobody told you about at all
Shadow AI, where staff use public AI tools outside any approved process. The Guidelines name this directly, alongside inadequate disclosure of embedded AI, as a practical constraint on identifying AI use. They do not pretend it can be eliminated. They ask you to recognise the risk it creates and put mitigating measures in place.
One useful boundary. The Guidelines define AI as machine-based systems or models that derive outputs through learned premises, such as the data they receive. Calculators and tools whose outputs come solely from predefined programming logic or rules are not AI for this purpose. So your rules engines do not suddenly become in scope. The test is whether the behaviour was learned or specified.
Why your outsourcing register misses most of it
This is a structural problem rather than a diligence failure. Three things break at once.
- The trigger is missing. Vendor risk reassessment is usually driven by contract renewal, a material change notification, or an annual cycle. A vendor enabling an AI feature inside an existing service may trigger none of these.
- The unit of assessment is wrong. Registers assess suppliers. The Guidelines assess use cases. A single supplier may deliver one AI use case that is trivial and another that touches customer outcomes. One risk rating for the supplier tells you nothing useful about either.
- Nobody owns the question. Procurement assesses the contract. Technology assesses the integration. Risk assesses the supplier. In many institutions, no function is accountable for deciding whether a given piece of software contains AI at all.
The Guidelines close that last gap specifically. They expect a designated control function to be responsible for AI identification, with enough independent oversight to apply the process consistently, and to be the final arbiter on whether a particular use counts as AI use. That is a named decision right, and assigning it is one of the cheapest things you can do this quarter.
The Guidelines also offer a practical bridge rather than a rebuild. The AI inventory can extend existing inventories or stand alone, as long as there are clear links between them. They suggest using consistent vendor or service identifiers that link back to your existing third-party or outsourcing registers. In other words, do not throw the register away. Join it up.
What MAS expects on third-party AI
Read that sequence carefully, because the Guidelines are doing something more specific than asking for vendor diligence. They assume from the outset that you will not get everything you want from the vendor, and they tell you what to do about the shortfall. The shortfall even has a name: an assurance gap.
Within the onboarding decision, the Guidelines set out eight areas to consider, each to be met to a degree that matches the risk materiality of the use case.
| Area | What it is asking |
|---|---|
| Transparency | Does the provider disclose enough for you to judge whether proper controls were applied during development and deployment, across data, model, technology and cybersecurity, fairness and explainability? |
| Supply chain | Have the underlying models, datasets and dependencies, including open-source ones, been assessed for provenance, training data integrity and known vulnerabilities? |
| Concentration | Does this deepen an over-reliance on a small number of providers, directly or indirectly? |
| Change management | Will you be told when the AI is updated or changed after deployment, and can you assess the impact? |
| Contingency | What happens on failure, unexpected behaviour, or the vendor withdrawing support? |
| Legal agreements | Do the contracts set clear expectations on performance, data protection, audit rights, and notification when AI is introduced or updated? |
| Capabilities | Do the people procuring, deploying and using this actually understand it? |
| Complexity | Is this a kind of AI you have little experience with, and therefore needs deeper assessment? |
One of these deserves separating out, because it changes what "evidence" means.
Self-attestation is explicitly not enough
On transparency, the Guidelines say that where a provider's disclosures are limited, an institution may consider reviewing certifications or external assessments of the provider carried out by independent and competent parties, and they add the qualifier in plain terms: not self-attestations.
That single parenthesis is the most consequential line in the third-party section, and it is easy to miss. A completed vendor questionnaire is a self-attestation. A vendor's own white paper describing its responsible AI programme is a self-attestation. A security page on a website is a self-attestation. None of these, on their own, close the gap.
This is the same principle that governs model risk management in banking, where the people who build a model cannot be the only ones who validate it, and it is the principle behind AI assurance generally. What has changed is that it now applies to systems you do not own, built by people who do not work for you. The distinction between testing and assurance matters more here, not less, because you control neither the build nor the tester.
The Third-Party AI Assurance Ladder
Each rung answers one question, and each depends on the one below it.
Rung 1. Find it
Identification has to be consistent across every business and functional area, and where AI sits inside third-party services, the Guidelines say identification should at minimum cover AI in services from material third-party providers. That is the floor, not the ceiling.
Four discovery routes work in practice, and none of them is a questionnaire:
- Release notes. Someone has to read what your material vendors ship. AI features are usually announced, just not to your risk function.
- Admin consoles. Most enterprise platforms expose which AI features are enabled for your tenancy, and by whom. This is the fastest win available to you.
- Contract review triggers. Add an AI question to renewal, variation and material change processes, so new AI gets caught at the next natural checkpoint.
- Technical detection. Network monitoring and data loss prevention controls to pick up unauthorised AI use, which the Guidelines name as an example of a mitigating measure where identification has practical limits.
Then put the result somewhere. The inventory should capture attributes at a level of granularity that actually supports oversight. The Guidelines list candidates including purpose and description, approved scope of use, model type, data used, dependencies, life cycle status, assigned risk materiality, review status, owners and links to documentation.
Rung 2. Tier it
Risk materiality is assessed per use case, using a methodology applied consistently across the institution, and considering both inherent risk before controls and residual risk after them. Three dimensions run through it.
| Dimension | What raises it | The third-party twist |
|---|---|---|
| Impact | Financial, operational, regulatory, legal or reputational consequences, and effects on customers including fairness and consumer protection. Sensitivity of the data processed. | Unchanged. Impact is about your customers, not your vendor. |
| Complexity | The nature of the technology, novelty of the application, the data, and how explainable the outputs are. | Your level of visibility into the technology and the data counts here. Less visibility means more complexity, which means a higher rating. |
| Reliance | How much the decision or output depends on the AI, how much autonomy it has, and how much human involvement remains. | Reliance on third-party AI is named explicitly. Buying rather than building does not reduce it. |
The practical consequence is worth stating plainly, because it inverts normal procurement instinct. Opacity is a risk multiplier. A vendor who tells you less does not thereby become a lower-effort relationship. Under this methodology, they become a higher-rated one.
Rung 3. Prove it
This is where self-attestation fails and independent evidence takes over. Build your evidence expectations by tier rather than asking everyone for everything.
| Risk materiality | Evidence that should satisfy you | What should not |
|---|---|---|
| Low | Vendor documentation on what the AI does, its approved scope, and data handling. Basic governance policies may be proportionate here. | Nothing in the inventory at all. |
| Medium | The above, plus certification or external assessment covering the relevant AI risks, plus your own testing in the context of your use case. | A completed questionnaire treated as the assessment. |
| High | All of the above, plus assessment by an independent and competent party covering the key risks, your own testing on your own data, and documented contingency and exit arrangements. | A vendor's own responsible AI report, however thorough it looks. |
Whatever tier, the documentation obligation is the same in character: keep sufficient records of how you tested the third-party AI and why you judged it suitable. If you cannot show your reasoning a year later, you did not do the step.
Rung 4. Contract for it
The Guidelines expect contractual agreements to give an institution a risk-appropriate degree of visibility over the introduction of AI and over later updates or changes, so that controls can actually be applied. They point to clauses covering performance guarantees, data protection, the right to audit, notification when AI is introduced and updated, and in some cases seeking your agreement before AI is incorporated at all.
| Clause | What it must achieve | Why it matters here |
|---|---|---|
| Notification before introduction | You are told before AI is added to a service you already consume. | This is the clause that fixes route two. Without it, embedded AI keeps arriving unannounced and your inventory is permanently out of date. |
| Consent before incorporation | For high materiality services, the vendor needs your agreement, not just gives you notice. | Stronger than notification. Reserve it for the relationships where a surprise would be unacceptable. |
| Change notification | You are told when the model or its behaviour is updated after deployment. | Supports your own impact assessment. An AI system that passed review in March can behave differently in September. |
| Right to audit | You, or an independent party, can examine the relevant controls. | This is what makes independent evidence obtainable rather than theoretical. |
| Testing rights and data | You may test the service in the context of your own use cases, using your own data. | Compensatory testing is an expectation. If the contract forbids it, you cannot meet the expectation. |
| Performance and data protection | Defined service expectations and clear data handling terms. | Standard, but AI changes what "performance" means. Define it against outputs, not uptime. |
| Continuity and exit | What happens on failure, unexpected behaviour or withdrawal of support. | Supports the contingency expectation, and makes the exit rung real rather than rhetorical. |
A note on sequencing that will save you time. Most institutions cannot reopen every contract at once. Tier first, then renegotiate in tier order, and attach AI clauses to the renewal cycle for everything else. Trying to amend the whole estate in twelve months is how programmes stall.
Rung 5. Compensate for the gap
Covered in full in the next section, because it is the step that decides whether the rest of this is paperwork.
Rung 6. Plan the exit
The last expectation is the one that gives the others teeth. If residual risk for a use case that depends on third-party AI cannot be brought within risk appetite, the institution should consider limiting or suspending the service, or replacing the provider.
That decision is only available if you prepared for it. For high risk materiality use cases, the Guidelines expect contingency plans with fallback options such as alternative systems or manual processes, reviewed and tested so they work under a range of conditions. Where AI has a kill switch, activation protocols should be clear and tested regularly.
Concentration risk belongs here too. Over-reliance on a small number of dominant providers, whether direct or indirect, is named as a risk in its own right. Indirect is the word to dwell on. Four vendors can look like healthy diversification while all four sit on the same underlying model.
What to do when the vendor will not tell you
This is the most important and least discussed part of the whole subject, so it is worth being concrete about what it means.
You will not get model weights. You will often not get training data documentation. You may not get meaningful detail on how fairness was evaluated. None of that stops you from establishing how the system behaves for you, which is the question you actually need answered.
- Test on your own data, in your own use case. A vendor's benchmark tells you how the system performs on the vendor's distribution. Your portfolio, your customers and your document formats are a different distribution. Run your own cases through it and record what happens.
- Probe the edges. Your known hard cases, your historically contentious decisions, the segments where fairness complaints have arisen before.
- Re-test after changes. Which is why the change notification clause is load-bearing. A test result is evidence about a version, not about a vendor.
- Use oversight as a control, not a comfort. Greater human oversight is named as a compensating control. It only compensates if the reviewer can realistically detect an error, has time to do it, and is accountable for the outcome.
- Narrow the use. Limiting what the AI is permitted to do is explicitly available as a mitigant. A system you cannot assess for autonomous decisions may still be perfectly acceptable as a drafting aid.
And the honest point underneath all this: compensatory testing is a capability, not a policy. Most institutions do not currently have a function that can independently test a third party's AI against their own data, document the result and stand behind the conclusion. That is the gap that a twelve-month runway is actually for.
Vendor-supplied agents are the harder case
The failure mode named in the Guidelines is precise and worth repeating to anyone evaluating an agent product: an agent with access to tools can autonomously carry out unauthorised or mistaken actions because of a divergence between the goals it was given and how it translated those goals into actions. The security case is the mirror image. A compromised agent with access to internal systems and external tools can be used to exfiltrate data or execute malicious commands at scale.
For inventory purposes, the Guidelines note that relevant attributes for agents may include agent-specific identifiers, the tools and systems the agent can access, its components, and the guardrails imposed on it. That is a useful checklist to put to a vendor before you buy, and most will struggle with the second item. An agent whose accessible tool set cannot be enumerated cannot be scoped, and a system you cannot scope is one you cannot bound. This is a large part of why enterprises end up decommissioning agents they cannot stand behind.
MAS has signalled that further consultation on agentic AI guidance is intended in 2027. Treat current practice as the floor rather than the finished position, and for the regional reference point, the Infocomm Media Development Authority's Model AI Governance Framework for Agentic AI is cited in the Guidelines themselves.
What to do in the next twelve months
Sections 3 and 4 are the first tranche, so oversight, identification, risk materiality and inventory are the work for this year. A workable sequence:
| Quarter | Focus | What done looks like |
|---|---|---|
| Q1 | Decide who owns the question | A control function is designated for AI identification, with the authority to be final arbiter on what counts as AI use. A definition is written down. |
| Q2 | Find the embedded AI | Material third-party services reviewed for AI features. Admin consoles audited. A first inventory exists, linked to the existing third-party register. |
| Q3 | Tier and triage | A risk materiality methodology applied consistently across use cases. The high materiality set is known and small enough to work on. |
| Q4 | Close the evidence gap | Evidence expectations set by tier. Contract clauses agreed for new and renewing agreements. A compensatory testing capability piloted on one high materiality vendor. |
If you only do one thing this quarter, do the first row. Almost every institution that struggles with this struggles because no one function is accountable for deciding whether a given piece of software contains AI.
Common mistakes
- Treating the vendor questionnaire as the assessment. It is a starting point. The Guidelines say in as many words that self-attestations are not what closes a transparency gap.
- Scoping by contract value. Materiality is about what the AI decides and how much you rely on it, not what you paid.
- Assessing suppliers instead of use cases. One rating per vendor hides the one use case that matters.
- Rewriting every contract at once. Tier first, renegotiate in order, attach clauses to renewals.
- Treating opacity as low effort. Reduced visibility raises the complexity rating. It does not lower the workload.
- Assuming it is someone else's accountability. The decision to onboard third-party AI is the institution's, and so is the accountability for it.
- Testing once. Without change notification and re-testing, your evidence describes a version of the system that may no longer exist.
- Building a register with no exit plan. If you have no contingency, "limit, suspend or replace" is not a decision you can actually take.
Key takeaways
- MAS issued the Guidelines on AI Risk Management on 7 October 2026. They take effect 7 October 2027, with Sections 5 and 6 by 7 October 2028.
- Third-party AI is defined broadly enough to include AI features inside software you already own and never procured as AI.
- Identification and inventory are in the first tranche, because you cannot control what you have not found.
- Risk materiality is assessed per use case on impact, complexity and reliance. Poor visibility into a vendor's AI raises the rating rather than lowering the effort.
- A vendor's self-attestation does not close a transparency gap. Independent assessment and your own testing do.
- Where disclosure falls short, compensatory testing on your own data, tighter human oversight and narrower permitted use are the available answers.
- If residual risk still sits outside appetite, limiting, suspending or replacing the service is the expected response, and that requires contingency planning done in advance.
Work with MASSIVUE
If you are working out how much AI is already inside your vendor stack, two next steps help.
Start with the evidence question. The AI CoE Playbook sets out a five-level maturity model and the evidence architecture that makes an AI deployment decision defensible, mapped to recognised references including the NIST AI Risk Management Framework and ISO/IEC 42001. It is written for the executives who carry this risk, and it is the practical companion to the independence question this article turns on.
If you would rather pressure-test something live, book a 30-minute third-party AI exposure review. We will take one material vendor relationship, walk it end to end against the expectations above, and show you where your current assessment would not hold up. It is a working session on your evidence, not a sales pitch. You can also take the free AI maturity assessment in about five minutes to place your organisation first.
Our AI assurance practice, Protum, exists for exactly this problem: governance and independent assurance for AI you did not build yourself.
Frequently asked questions
What are the MAS Guidelines on AI Risk Management?
They are supervisory expectations issued by the Monetary Authority of Singapore on 7 October 2026, covering how financial institutions should manage risks from their use of AI. They address oversight, AI risk management systems and procedures, life cycle controls, and capability. They apply to all MAS-regulated financial institutions and to all forms of AI, applied in proportion to the institution's size, nature of activities and risk profile.
When do the MAS AI Guidelines take effect?
They take effect on 7 October 2027. Institutions may implement them in phases, meeting the expectations in Sections 3 and 4 from 7 October 2027, and those in Sections 5 and 6 by 7 October 2028. Sections 3 and 4 cover oversight, identification of AI use, risk materiality assessment and the AI inventory, which is why discovery work is the immediate priority.
What is third-party AI under the MAS Guidelines?
AI systems or models, and services or tools that incorporate or use AI, which are developed, owned, operated or provided by an external party and which an institution procures, subscribes to, accesses or otherwise relies on for its business activities. Importantly this includes AI embedded in software-as-a-service that was never marketed to you as AI.
Is a vendor's AI questionnaire enough evidence?
No. The Guidelines say that where a provider's own disclosures are limited, an institution may look to certifications or external assessments carried out by independent and competent parties, and they state explicitly that self-attestations do not serve this purpose. A completed vendor questionnaire is a self-attestation. It is a reasonable starting point and it is not, by itself, assurance.
Who is accountable if a vendor's AI causes harm?
The financial institution. The Guidelines are direct on this: the decision to onboard and use third-party AI is the institution's decision, and the institution retains primary accountability for that use, including the impact on its stakeholders and on its own ability to meet regulatory requirements. Accountability does not transfer with the contract.
What is compensatory testing?
Testing you perform yourself to fill the information gaps a vendor leaves. The Guidelines expect institutions to test third-party AI in the context of their own use cases, including using their own data, and to perform compensatory testing where provider disclosures are inadequate. In practice it means establishing how the system behaves on your cases rather than relying on the vendor's benchmarks.
What contract terms should we ask an AI vendor for?
The Guidelines point to performance guarantees, data protection, a right to audit, and notification when AI is introduced and when it is updated, and in some cases seeking the institution's agreement before AI is incorporated at all. The underlying aim is a degree of visibility appropriate to the risk, both over AI being introduced and over later changes, so you can actually apply your controls.
Do we need a dedicated AI committee?
No. MAS confirmed that existing governance structures may be used where they provide adequate oversight and cross-functional coordination, and that a dedicated AI committee is not required solely to meet the oversight expectation. What is expected is clear accountability, including a designated control function responsible for AI identification.
Does this apply to low-risk uses like drafting emails?
In a lighter form. The Guidelines allow basic AI governance policies and procedures where poor performance or unavailability of the AI is unlikely to have a material adverse impact on the institution, its customers or other stakeholders. Drafting and proofreading assistance, internal summarisation and similar uses are given as examples, on the basis that humans review the outputs before use. Basic does not mean absent: clear accountability, permitted and prohibited uses, an approved tool list and staff education are still expected.
How do the Guidelines treat AI agents?
Agents are in scope, and they are treated as an amplifier of existing risks because of their autonomy and tool access. The Guidelines describe the core failure mode as an agent translating its given goals into actions that were not authorised or intended, and note the security risk of a compromised agent with access to internal systems. Where an institution has little experience with agents, particularly those supplied by third parties, deeper assessment is expected. MAS has indicated it intends to consult further on agentic AI guidance in 2027.
Do rule-based systems count as AI?
No. The Guidelines define AI as machine-based systems or models that derive outputs through learned premises such as the data they receive, and state that calculators or tools whose outputs are based solely on predefined programming logic or rules are not AI for this purpose. The dividing line is whether the behaviour was learned or explicitly specified.
Sources
Statements about the Guidelines in this article are drawn from the primary documents published by MAS.
- Monetary Authority of Singapore, Guidelines on Artificial Intelligence Risk Management for Financial Institutions, 7 October 2026.
- Monetary Authority of Singapore, MAS Sets Out Supervisory Expectations on Responsible AI Adoption by Financial Institutions, media release, 7 October 2026.
- Monetary Authority of Singapore, Principles on Fairness, Ethics, Accountability and Transparency, referenced in the Guidelines as continuing to apply.
- Infocomm Media Development Authority, Model AI Governance Framework for Agentic AI, cited within the Guidelines.
- NIST, AI Risk Management Framework, and ISO/IEC 42001, as general evidence references.
This article is for general information and does not constitute legal or regulatory advice. It summarises selected expectations relevant to third-party AI and is not a complete account of the Guidelines. Verify current requirements against the primary documents and your own legal advice before acting.