AI model change control for Malaysian suppliers to Singapore banks

The decision turns on what changes in the service the bank approved. A model that performs better in testing may introduce a new recipient of customer information, different retention terms or permission to take actions that the pilot could only recommend. Each change needs an identified owner, supporting evidence and a release decision.

Executive Summary

• Record the approved provider, model version, purpose, data flows and tool permissions. Assess the proposed provider substitution and operational expansion against that baseline.
• The bank retains its regulatory responsibilities. Outsourcing classification depends on the actual service, duration and consequences of failure. Customer-information duties can apply even where the service is not a material ongoing outsourcing arrangement.
• Check customer confidentiality separately from personal-data compliance. Existing permissions may cover the new arrangement, but the bank’s internal approval does not establish that they do.
• Malaysian processing can attract Malaysia’s Personal Data Protection Act 2010. Since April 2025, processors within scope have a direct security duty. Onward transfers require the applicable controller to establish a permitted transfer route.
• Agree written approval, evidence, testing, suspension and exit provisions before substitution. Allocate revalidation costs expressly. These negotiated terms should address provider changes that the supplier cannot prevent.

The replacement changes the approved service

The supplier should prepare a comparison of the approved and proposed configurations. Identify the provider’s legal entity, model and version, deployment location, system instructions, retrieval sources, permitted users, connected tools and action limits. Include prompts, outputs, logs, retained memory and provider support access in the data-flow record.

Review should cover changes to the model’s behaviour and the agent’s authority. Moving from drafting an internal recommendation to updating customer records, communicating externally or initiating a payment changes the consequences of error. Increasing transaction limits or removing human approval can matter more than changing the model’s name.

A replacement provider warrants review even where the interface stays the same. The new provider may use different subprocessors or retain prompts for its own purposes. A supplier’s release label, such as “minor update”, cannot resolve those differences.

The proposed contract should reserve these changes for express bank approval. Routine updates can follow an agreed, lighter process where they remain within the approved purpose, permissions and data arrangements. Require evidence of that classification and proportionate regression testing. Several small updates should be assessed together if their cumulative effect changes the approved risk. These are proposed controls, informed by MAS expectations that technology changes be assessed, tested and approved before implementation. (MAS, Technology Risk Management Guidelines, 18 January 2021, paras 7.5.1–7.5.7.)

The bank remains responsible for the outsourced service

First establish whether the arrangement is an outsourced relevant service under MAS Notice 658. Operating an agent within banking processes may fall within that definition; providing software does not establish the classification by itself. Examine the functions, the bank’s reliance on them and the Notice’s exclusions. Then assess whether the service is both ongoing and material. “Ongoing” includes a service received for more than 12 months, taking account of intended extensions. Materiality concerns the potential impact on operations, customers, risk management or legal compliance. A pilot label or low price does not answer those questions. (MAS Notice 658, Management of Outsourced Relevant Services, para 2.1 and Annexes A–D.)

For material ongoing outsourced relevant services, the Notice requires provider assessment, subcontracting controls and continuing review. Other outsourced relevant services involving customer information fall within the separate requirements in section C. The bank should reassess classification when operational reliance grows and update its outsourcing register as necessary. (Notice 658, paras 3.1–3.2, 5.1–5.6, 6.3 and 12.1–12.11.)

Distinguish the relevant approval rules. Notice 658, paragraph 6.3(a), requires written subcontractor notification before engagement or within a reasonable time afterwards, unless prior bank agreement has been obtained. Separately, the MAS Guidelines on Outsourcing (Banks), paragraph 3.5.1, expect prior bank approval of subcontracting any part of a material ongoing outsourced relevant service. The contract should implement a clear prior-written-approval requirement for the proposed provider replacement. It should not describe every substitution as requiring MAS permission; any bank-specific supervisory requirement must be checked separately.

The Notice generally took effect on 11 December 2024. Its mandatory agreement terms have separate transitions: existing agreements can be tied to their next tenure extension, while agreements entered after 11 December 2024 ordinarily engage the requirements on entry. The classification-change rule also needs checking. A model amendment is not automatically a tenure extension. These transitions do not defer the Notice’s other applicable controls. (Notice 658, paras 14.1–14.4.)

Technology and accountability requirements also remain relevant. Current binding technology-risk and cyber-hygiene notices are FSM-N05 and FSM-N06. Their application depends on the systems and controls concerned. The bank should assign responsibility and approval authority under its governance arrangements, with business, technology, security and compliance input proportionate to the change. Outsourcing does not transfer the bank’s accountability to the Malaysian supplier. (MAS Notices FSM-N05 and FSM-N06, effective 10 May 2024; MAS Guidelines on Individual Accountability and Conduct, Outcome 1; Guidelines on Outsourcing (Banks), para 3.1.)

MAS finalised its AI risk-management guidelines on 7 October 2026. Implementation starts on 7 October 2027, with sections 5 and 6 due by 7 October 2028. Their express lifecycle provisions support forward planning for significant-change review, version control and replacement, but are not currently effective requirements. The MAS AI guidelines overview explains that wider timetable. (MAS, Guidelines on Artificial Intelligence Risk Management, paras 1.8, 5.9–5.11 and 5.24–5.26.)

IMDA’s Model AI Governance Framework for Agentic AI, version 1.5, is voluntary guidance. Its controls for permissions, human checkpoints, testing and monitoring can inform the schedule. They become contractual commitments if the parties incorporate them. The framework itself grants no permission to disclose customer information or conduct a regulated activity. (IMDA, Model AI Governance Framework for Agentic AI, v1.5, sections 2.1–2.3.)

The new provider changes the confidentiality and data assessment

Start with banking confidentiality. Singapore’s Banking Act protects defined customer information, including information about corporate customers. It is therefore wider than personal-data compliance alone. Section 47 permits disclosure only within the Act’s exceptions. The outsourcing exception concerns disclosure solely connected with outsourced bank operational functions, to the specified recipient and subject to MAS conditions. The bank must establish the applicable route for each recipient and any onward disclosure. (Banking Act 1970, ss 40A and 47; Third Schedule, Part 2, item 3.)

There is an additional written-consent requirement when a material ongoing outsourced relevant service is subcontracted and customer information must be disclosed. Notice 658, paragraph 6.2, contains a limited exception for information relating to banking-company or designated-financial-institution customers. Existing consent may suffice: MAS guidance does not require it to name every provider, but the disclosure’s scope and purpose must be communicated. If existing permission does not cover the new disclosure, obtain the necessary permission or redesign the flow before sending the information. (Notice 658, paras 6.1–6.2; Guidelines on Outsourcing (Banks), para 3.5.2.)

Read the replacement provider’s operative terms and configuration together. Establish whether prompts, outputs or logs are used for general model training, how long each category is retained, who can inspect it and where subprocessors operate. A contractual permission to use information beyond the bank’s service cannot be treated as authorised merely because the provider calls it service improvement. The bank must reconcile that use with banking secrecy, its outsourcing obligations and the applicable personal-data basis. (Notice 658, paras 8.1 and 12.9; Personal Data Protection Act 2012, ss 13, 18 and 20.)

Singapore’s PDPA also distinguishes processing on another organisation’s behalf from processing for an independent purpose. The bank remains responsible for personal data processed on its behalf. A provider’s own training use needs separate analysis of its role, lawful basis and purpose. The PDPC’s July 2026 generative-AI guidance expressly addresses these distinctions. A generic privacy notice does not automatically establish sufficiently specific consent for large-scale model training. Nor is consent the only possible statutory route. (Personal Data Protection Act 2012, s 4(2)–(3); PDPC, Advisory Guidelines on Use of Personal Data in Generative AI, 20 July 2026, paras 4.2–4.6, 6.3 and 7.1–7.4.)

The proposed schedule should prohibit independent training by default and specify permitted inference, support, logging and retention. Any exception should require a separate bank decision and the necessary legal basis. Bank approval cannot permit customer information to be used beyond what is necessary to provide the outsourced service where Notice 658 imposes that restriction. (Notice 658, paras 8.1(b) and 12.9(b).) Require documented deletion arrangements, including backups and any retention required by law. Overseas transfers need a permitted basis under Singapore’s transfer rules. Where the parties use the contractual route, the enforceable obligations must provide comparable protection and specify the countries and territories of transfer. A hosting-region choice does not resolve remote support access or onward transfers. (Personal Data Protection Act 2012, ss 24–26; Personal Data Protection Regulations 2021, regs 9–12.)

Malaysia requires a separate assessment. Act 709 applies to covered commercial processing with the statutory Malaysian connection, including establishment or qualifying use of equipment. Malaysian incorporation alone does not settle every overseas processing activity. Conversely, Singapore customers are not excluded merely because they are abroad. Identify where the supplier processes information and whether it acts solely on instructions or determines its own purposes. (Personal Data Protection Act 2010 [Malaysia], ss 2–4.)

For processing within scope, the amended Act imposes the Security Principle directly on data processors from 1 April 2025. Controller duties also matter where the supplier determines its own purposes. Data-protection-officer and breach-notification requirements took effect on 1 June 2025; assess the applicable role, thresholds and reporting arrangements rather than assuming every vendor has identical duties. (Act 709, ss 5(1A), 9 and 12A–12B; Personal Data Protection (Amendment) Act 2024 [Act A1727], ss 4–6; P.U. (B) 522/2024; Commissioner’s DPO Circular No. 1/2025 and DBN Circular No. 2/2025.)

Processors meeting the applicable DPO criteria must appoint a DPO; section 12B’s mandatory breach-notification duty rests on the controller. Prompt processor-to-controller reporting should be secured contractually. (Act 709, ss 12A(2) and 12B; Commissioner’s DPO Circular No. 1/2025, para 4(1); Personal Data Protection Guidelines on Data Breach Notification, paras 12.1–12.2.)

If data is exported from Malaysia, the applicable controller must establish the route under amended section 129. It may rely on the statutory comparable-law or equivalent-protection condition, or an applicable exception with its own requirements. The former ministerial whitelist mechanism was removed from 1 April 2025. Do not assume that Singapore’s destination status or a signed processing agreement completes the assessment. The supplier should provide the controller with evidence of recipient safeguards, countries, onward transfers and contractual enforceability. (Act 709, s 129, as amended by Act A1727, s 12; Commissioner, Guidelines on Cross-Border Personal Data Transfer, No. 3/2025, paras 4–6 and 12–16.)

Bank Negara Malaysia’s RMiT policy applies to its specified financial institutions. It does not directly regulate every Malaysian technology supplier merely because a Singapore bank buys its service. If expanded powers make the supplier perform a regulated financial service in its own right, obtain an activity-specific perimeter assessment before enabling those functions. The bank’s approval and the supplier’s incorporation do not answer that separate question. (Bank Negara Malaysia, Risk Management in Technology, BNM/RH/PD 028-98, 25 September 2026, paras 2.1 and 5.2.)

Reapproval needs a controlled release and a usable fallback

The parties should adopt the following approval sequence in the schedule:

1. The supplier records the current configuration and submits a complete change notice. It identifies the proposed provider, operational purpose, permissions, data changes, dependencies and requested release date. The bank names the decision owner.
2. The bank reassesses outsourcing classification, customer-information permissions and the proposed use. The supplier supplies provider terms and the Malaysia processing and transfer assessment relevant to its role. No real customer information goes to the replacement provider for testing until the applicable disclosure and processing conditions are satisfied.
3. The bank and supplier agree acceptance criteria. Test the bank’s actual workflows, including inaccurate outputs, prompt injection, unauthorised tool use, data leakage, excessive permissions, provider failure and human escalation. Use approved test data and preserve the results.
4. The bank’s authorised approvers record acceptance or refusal, residual risks and any limits on deployment. A procurement signature or an unanswered notice should not substitute for this recorded release decision.
5. The supplier deploys only the approved configuration, initially within agreed exposure limits. Monitoring should compare behaviour, permissions and provider terms with the approved baseline. Unexpected changes trigger the agreed stop or reassessment process.
6. The supplier demonstrates rollback or a workable alternative before release. If the previous model is unavailable or unsafe, the fallback must be another approved configuration, a controlled manual process or suspension of the affected function.

This sequence implements the proposed contract and supports current MAS technology-change expectations, including testing, approval, records and rollback planning. The required level of testing depends on the change and its consequences. (Technology Risk Management Guidelines, paras 7.5.1–7.5.7.)

An emergency route should identify who may authorise a narrowly scoped protective change, how quickly the bank receives the evidence and when review follows. It should not permit broader agent powers or unauthorised disclosure. A forced upstream retirement may require suspension while the bank approves a replacement. A contractual rollback promise cannot restore a model the provider has withdrawn.

The schedule must govern later provider changes

The contract should make the approval sequence enforceable and assign each obligation to a party. It should cover:

• The approved configuration and reserved changes. Include provider substitution, material model behaviour, purpose, tool authority, data location, training rights, retention, subprocessors and retirement. Define the evidence required to treat an update as routine.
• A complete notice package and agreed lead time. The review period starts when the bank has the necessary information. Silence is not approval. Neither party should invent a universal statutory advance-notice period for model changes.
• Upstream commitments. Require the supplier to secure the necessary purpose restrictions, security, access, assurance and exit support from providers. If it cannot secure them, it must disclose the gap before approval. The bank then decides whether lawful, workable alternatives exist.
• Version and configuration control. Require pinned versions where available, change detection where they are not, and disclosure of any provider right to substitute models behind an unchanged API. A model name alone is insufficient evidence of stability.
• Testing and release evidence. Allocate test preparation, acceptance criteria, sign-off, production monitoring and record retention. State who can stop the agent and how credentials and tools are disabled.
• Suspension, rollback and exit. Set triggers for failed validation, unlawful data use, loss of safeguards, provider withdrawal and repeated unauthorised change. Require assistance with migration, usable exports, revocation of access and verified deletion, subject to identified legal retention duties.

Incident provisions should require prompt supplier escalation without waiting for a completed root-cause report. The bank may have a one-hour notification deadline after discovering a relevant incident under FSM-N05; the contractual escalation route must enable compliance where that test is met. The schedule should also support applicable privacy-breach reporting and regulatory access. (MAS Notice FSM-N05, paras 7–9; Notice 658, paras 7.1 and 12.8, subject to paras 14.2–14.4.)

Allocate revalidation costs expressly. A proposed commercial position is that the supplier funds its requested provider substitution, including agreed validation and migration work. Bank-requested expansion can proceed through a priced change order. Address emergency security changes, unavoidable retirements and rejected proposals separately. MAS does not prescribe that commercial allocation. Payment disputes must not authorise an unapproved release or prevent an agreed protective suspension.

Prepare a model-change control schedule. Ask Licentium to review the approved workflow, replacement-provider terms and change notice, then define the approval, testing, fallback and exit obligations for the next release and later substitutions.