MAS sets AI-risk expectations for payment institutions and other financial firms

The verified development

The Monetary Authority of Singapore issued Guidelines on Artificial Intelligence Risk Management on 7 October 2026. MAS says the guidelines apply to all financial institutions and all forms of AI, using a principles-based and risk-proportionate approach. The covered list includes designated payment-system operators, settlement institutions, major payment institutions and standard payment institutions. MAS expects governance, AI inventories, risk assessment, lifecycle controls, human oversight, cybersecurity, monitoring and change management. The guidelines take effect in phases from 7 October 2027 and 7 October 2028.

MAS also says financial institutions remain accountable for AI used in services they deliver when that AI is developed, operated or provided by third parties. Firms should obtain assurance, assess suitability and use compensating controls where gaps exist. The guidance is directed to regulated financial institutions, not automatically to every merchant using their services. These are reported facts from MAS. The following merchant analysis is independent, does not provide Singapore legal advice and does not claim that FixPays uses or supplies a covered AI system.

Independent analysis: operational scope

Payment providers can use AI in onboarding, fraud scoring, transaction monitoring, support, routing, forecasting and software development. Merchants experience the result even when they never see the model. A declined transaction, delayed review or support response can affect customers and cash flow. Merchants should ask providers which consequential decisions involve automated systems, what information is required from the merchant, where human review is available and how an error can be corrected. The answer should describe the actual service, not a generic AI policy.

A merchant’s own inventory should include customer-facing agents, fraud tools, catalogue generation, support summarisation and internal decision aids. Record the owner, purpose, vendor, data used, output, affected customers and fallback. Not every use requires the same controls. A writing assistant has a different impact from a system that blocks withdrawals or changes payment routing. Classification should reflect possible customer, financial, regulatory and operational harm so oversight effort follows materiality rather than fashionable terminology.

Independent analysis: customer and risk controls

Third-party accountability matters because payment chains already depend on multiple vendors. A model can be embedded inside a gateway, identity tool or case-management platform. Contract review should address documentation, testing, change notices, incident reporting, data use, subcontractors, access to evidence and termination. If the vendor cannot explain a critical control, the merchant should limit the use case or add independent checks. A familiar provider name is not evidence that every embedded model suits the merchant’s customer group or transaction profile.

Human oversight must be operationally real. Staff need authority, training and usable evidence to review a decision; a nominal escalation mailbox is not enough. Define which outcomes can be reversed, how quickly, and what happens to payment status while a case is reviewed. Monitor false positives, customer complaints, demographic or geographic disparities where lawfully measurable, and outcomes after model changes. Do not collect extra sensitive data merely to make a dashboard appear complete; data minimisation and access control remain important.

Independent analysis: rollout and measurement

The phased effective dates give regulated firms time to build governance, but merchants should not infer that present AI use is unregulated or risk-free. Existing contracts, privacy duties, consumer obligations, security controls and sector rules may already apply. A sensible readiness exercise maps dependencies now, identifies the most consequential uses and asks providers for dated answers. Merchants operating outside Singapore can still use the publication as a comparison point while checking their own jurisdictions and contractual responsibilities.

Independent analysis: wider merchant implications

Payment-specific AI inventories should include tools that recommend declines, prioritise alerts, classify disputes, generate merchant communications or change transaction routes. A model used only by a provider can still produce merchant consequences. Ask which outputs are deterministic rules, statistical models or autonomous agents, because testing and explanation differ. Record dependencies such as external data, cloud services and human queues. An inventory should be current enough to support incident response, not a once-a-year spreadsheet assembled for audit.

Merchants should examine whether an AI system can initiate an action or only recommend one. The risk changes when software can refund a payment, suspend an account, alter a limit or contact a customer without review. Define permission boundaries and transaction-value thresholds. Require strong authentication for administrative actions and log tool use. If an agent can access several systems, test whether a malicious or erroneous instruction can cross those boundaries and whether staff can stop the sequence quickly.

Competitors may use regulatory readiness as a trust signal, but merchants should distinguish verified governance from marketing language. Useful evidence includes a scoped control description, incident process, meaningful testing and a named accountable function. A badge, policy page or broad statement that AI is responsible does not establish performance. Procurement comparisons should use equivalent use cases and materiality. A simple low-impact system can appropriately have lighter controls than a complex autonomous decision engine.

Customers need understandable outcomes even when the underlying model is complex. A merchant may not be able to reveal fraud logic, but it can state whether a payment failed, an order is under review, more information is required or a person will reconsider the case. Avoid blaming “the algorithm” as if no organisation owns the decision. Support staff should see enough context to prevent repeated document requests and should know when a provider, rather than the merchant, controls the next step.

A change-management plan should define which model or prompt updates require retesting, who can approve emergency adjustments and how rollback works. Performance can shift when products, geographies, fraud patterns or customer language change even if the software version does not. Monitor inputs as well as outcomes. If a vendor silently changes a service, compare results against the prior baseline. Material drift should lead to investigation and possible limitation, not an assumption that newer always means better.