MAS Payment Regulations: What Singapore Fintech Platforms Actually Need to Implement

The Payment Services Act (PSA) is the primary regulatory framework governing payment service providers in Singapore. It came into force in January 2020 and was significantly amended in 2021 to extend its scope, particularly around digital payment token services and cross-border money transfers. If you are building a platform that moves money in Singapore, some part of the PSA almost certainly applies to you. The question is which part, and how you implement the obligations without embedding them in application code that gets harder to maintain with every regulatory update.

This is not legal advice. For licensing determinations you need a qualified Singapore law firm or compliance consultant. What this article covers is the operational and technical side: what PSA obligations look like when you translate them into system requirements, and which of those requirements can be handled at the payment infrastructure layer rather than in your product code.

Which license class actually applies to your platform

The PSA establishes three main license classes for payment service providers: Money-Changing Licence, Standard Payment Institution Licence, and Major Payment Institution Licence. The distinction between Standard and Major turns primarily on transaction volume thresholds: SGD 3 million per month in a single payment activity, or SGD 6 million per month across all payment activities combined, is the line where Standard becomes Major. These thresholds matter because Major Payment Institution licensees face more extensive requirements around safeguarding, reporting, and capital adequacy.

Many early-stage platforms building on top of licensed payment providers (such as DBS, OCBC, Stripe Singapore, or other licensed institutions) operate under the exemption that applies when you are not the payment service provider but rather a technology layer on top of one. However, the line between "technology platform facilitating payments" and "payment service provider" is not always clear. MAS has taken a substance-over-form view: if your platform controls when, to whom, and how much money moves, you may be providing a payment service regardless of how you have structured the arrangement contractually.

The practical trigger for most platforms is when you begin holding float, netting settlements, or operating e-money accounts on behalf of users. At that point, you have almost certainly crossed into the perimeter of the PSA.

Safeguarding obligations

For licensed payment service providers, the PSA and its subsidiary legislation (including MAS Notice PSN01 for e-money issuers and MAS Notice PSN02 for domestic money transfer services) impose safeguarding requirements for customer money. The core requirement is that funds owed to customers must be held separately from the company's own operating funds, in a designated account with an approved bank or in qualifying assets.

From a technical standpoint, safeguarding compliance requires your system to maintain a clear and auditable separation between customer funds and company funds at the ledger level. This means your payment ledger must accurately reflect the float you hold on behalf of customers at any given moment. Aggregate reporting on safeguarded funds is typically required on a daily basis under MAS rules.

Where this gets technically complex is in platforms with multiple payment rails and multiple settlement timelines. DBS PayNow settles near-instantly. SWIFT cross-border transfers may take 1 to 3 business days. Your safeguarding calculation on any given day reflects money in transit across multiple rails with different settlement states. The ledger design needs to correctly classify each of these states: in-transit, provisionally credited, or fully settled.

AML and transaction monitoring

The Monetary Authority of Singapore's Notice PSN-N02 on anti-money laundering and the Financial Action Task Force (FATF) standards apply to payment service providers. At the operational level, this translates to requirements for customer due diligence (CDD), transaction monitoring, and suspicious transaction reporting to the Suspicious Transaction Reporting Office (STRO).

Transaction monitoring requirements are where the intersection with payment infrastructure becomes concrete. The rules require that you screen transactions against sanctions lists (the MAS consolidated list, UN Security Council lists, and others relevant to your transaction corridors), monitor for patterns that may indicate structuring or layering, and retain transaction records for a minimum of five years.

At the payment routing layer, sanctions screening happens before a transaction is routed to a provider. Every counterparty reference, every account identifier, needs to be checked before the payment is submitted. If a match is found, the payment is held pending review rather than routed. The routing layer is the right place for this check because it runs on every transaction regardless of which provider will ultimately process it.

The five-year record retention requirement is a data architecture constraint. Transaction records, including the payment details, counterparty information, routing decisions, and any screening results, need to be retained in a queryable format. "Queryable" here is not optional: MAS examination requests and STRO investigations often require rapid retrieval of specific records. A data architecture where retrieving all transactions involving a specific counterparty takes two weeks to reconstruct from backup is not compliant in practice, even if the data technically exists.

Cross-border transfer requirements

Cross-border money transfers are regulated separately under the PSA because they carry distinct risks around currency controls, sanctions, and correspondent banking. Platforms sending money outside Singapore need to comply with the Travel Rule (FATF Recommendation 16 as implemented by MAS), which requires that certain information about the originator and beneficiary travel with the transaction through the payment chain.

The Travel Rule applies to wire transfers above SGD 1,500 (or the equivalent in foreign currency). The required information includes originator name, account number, and address, as well as beneficiary name and account number. Correspondent banks that process the wire need this information. If your payment routing sends cross-border transfers through a chain of banks, you are responsible for ensuring this information is passed correctly at each leg.

Technically, Travel Rule compliance means your payment records must capture and transmit this structured information as part of the payment message. If you are routing through SWIFT, this maps to specific message fields in MT 103 and MT 202 COV messages (or their MX/ISO 20022 equivalents). If you are using an intermediary provider for cross-border transfers, you need to confirm that your data model is compatible with theirs and that the required information is not being dropped or truncated in the routing.

MAS Technology Risk Management guidelines

Beyond the PSA, MAS's Technology Risk Management (TRM) guidelines apply to financial institutions in Singapore including payment service providers. The TRM guidelines are not prescriptive about specific technical implementations, but they establish principles around system resilience, access controls, change management, and incident response that have direct implications for payment infrastructure design.

On system resilience: the TRM guidelines expect financial institutions to achieve recovery time objectives that are proportionate to the criticality of the system. For a payment processing platform, the expectation is that core payment processing should be recoverable quickly after an outage, with documented and tested recovery procedures. This is one reason why failover design is not just an engineering quality-of-life concern. It is part of what MAS expects from a compliant payment infrastructure.

On access controls: the TRM guidelines require that access to payment processing systems be based on least-privilege principles, with multi-factor authentication for privileged access. API keys used to access payment infrastructure should be scoped to the minimum permissions required. Key rotation procedures should be defined and practiced.

What can be handled at the infrastructure layer

We are not saying that infrastructure handles all of compliance. That is not true, and it would be misleading to suggest it. License applications, customer due diligence programs, suspicious transaction reporting, and board-level governance of AML programs are things your compliance team handles. Infrastructure does not replace compliance judgment.

What can be handled at the infrastructure layer is the enforcement of rules that apply consistently to every transaction. Sanctions screening runs before every payment is routed. The Travel Rule data fields are captured and passed with every cross-border wire. Transaction records are written in a schema that supports the five-year retention and rapid retrieval requirement. The routing layer refuses to process transactions that would violate a configured compliance rule and surfaces a compliance hold status rather than a generic error.

The practical value of this is that when MAS updates guidance or issues a new circular, the change happens in one place rather than across every service that touches payments in your platform. We have seen platforms where a new transaction screening requirement meant updating six different services, coordinating four engineering teams, and running a two-month project to validate the change was applied consistently everywhere. That is a compliance risk as much as an engineering cost.

Singapore's payment regulatory environment is active. MAS consults frequently and updates guidelines regularly. Building on an infrastructure layer that is designed to absorb those updates is not just about today's compliance posture. It is about the cost of staying compliant as the rules evolve.