MAS Licensing for Fintech Platforms in Singapore: Major Payment Institution vs Standard

Which MAS licence fits your platform?#

Under Singapore's Payment Services Act 2019, one early licensing decision is practical. Can your platform apply for a Standard Payment Institution (SPI) licence, or should it apply for a Major Payment Institution (MPI) licence? MAS indicates you can apply for SPI if your payment services meet the stated SPI thresholds, and you should apply for MPI if your payment services exceed those threshold limits.

For compliance, legal, finance, and risk owners, this is a control-design decision, not just a licence label. You need clear decision rules, operating checkpoints, and escalation triggers so growth does not force a rushed filing or an unnecessary early overbuild.

MAS confirms that payment service providers can apply for three licence types under the PS Act, and points firms to Section 6(5) for threshold-limit detail. The published SPI threshold signals are:

If your forecasts are moving toward these levels, or your service mix is expanding across payment functions, treat that as an escalation trigger. For external status checks, MAS identifies the Financial Institutions Directory as the reference point for listed standard payment institutions in Singapore.

Process execution risk matters too. MAS has published licensing-process revisions effective 26 August 2024, including a legal-opinion submission requirement for mapping proposed business models to regulated payment services, an Independent External Auditor assessment requirement for new and variation applications to carry out DPT services, and a case-on-hold process for reviewed cases that need more applicant resolution time. Because the materials here do not fully set out how every reported change applies across filing types, treat these as filing-specific items to verify before you submit.

Scope boundary matters as well. This article stays grounded in published MAS materials. From the excerpts here, you can rely on the SPI thresholds and the basic within-limits versus above-limits direction. You cannot rely on them for a complete SPI-versus-MPI obligations map, exact MPI quantitative thresholds, full eligibility criteria, or definitive licensing fees and approval timelines.

SPI and MPI at a glance for platform operators#

For platform operators, the core rule is simple. Stay on the Standard Payment Institution (SPI) licence path only while you are within the Section 6(5) of the Payment Services Act limits. If you exceed those limits, MAS says you should apply for a Major Payment Institution (MPI) licence.

The operational checkpoint is evidence quality. MAS regulates 7 types of payment services under the PS Act, so do not rely only on total volume. Confirm which regulated service types you are providing, and whether you have crossed from one service into two or more. For external verification, MAS identifies the Financial Institutions Directory to check listed standard payment institutions in Singapore.

Operator planning step (not a MAS-stated trigger): if forecasted volume or e-money exposure is close enough that SPI limits are becoming a planning risk, run an MPI readiness assessment before product expansion. That gives you the high-level split. For a broader regional view, see A Deep Dive into the FinTech Network of Southeast Asia.

What MAS confirms today and what is still unknown#

For licensing decisions, use primary MAS text and statute text as decision-grade material. Treat secondary commentary as a prompt to verify, not a substitute for that step.

Confirmed in MAS text#

• MAS states that from 30 June 2025, DTSPs serving only customers outside Singapore for specified token services require a licence.
• MAS says it has "set the bar high for licensing and will generally not issue a licence" for that offshore-only DTSP scope.
• MAS says unlicensed in-scope DTSPs "will have to cease their regulated activities."
• MAS says for providers already licensed and serving customers in Singapore, "there is no change to what the licensed providers can do."
• MAS links digital token services to existing statutes, including the Payment Services Act 2019, Securities and Futures Act 2001, and Financial Advisers Act 2001.

Needs direct confirmation from MAS or counsel#

If your scope is near a licensing boundary or touches digital tokens, confirm against live MAS materials and counsel before launch or expansion.

Threshold monitoring rules for contractor, seller, and creator platforms#

For SPI operators, threshold monitoring should run as an early-warning control, not only a month-end reporting task. If your legal mapping uses Section 6(5) of the Payment Services Act 2019 for SPI limits, treat that boundary as live and escalate early when growth could outpace licensing preparation.

The point is not false precision. The point is a documented method, repeatable calculations, and a clear escalation path when growth or product changes start to compress your headroom.

Turn legal thresholds into operating triggers#

At minimum, monitor three views together: service volume by payment service type, combined activity across services where aggregation may matter, and e-money exposure, including value stored, held, or redeemed in your platform setup.

Use current statute text and live MAS licensing guidance when finalizing calculation logic. The materials here point to SPI/MPI licensing categories, but they do not provide the full threshold-calculation method or every trigger detail. Keep a dated copy of the source text, or a legal interpretation note, in your threshold file rather than relying on memory.

A practical escalation rule#

Use a forecast trigger, not only backward-looking actuals. As an internal operating rule, if forecast growth shows a realistic chance of exceeding SPI limits within the next two quarters, start an MPI readiness gap assessment and escalate to Legal, Compliance, and the accountable product executive.

Treat that two-quarter trigger as an internal operating rule, not a MAS-quoted requirement. It gives teams lead time for licensing prep, governance evidence, and product-scope decisions.

Where platforms usually get this wrong#

A common failure mode is narrow data scope. Teams may track settled payouts but miss pending flows, held balances, wallet-like value, or DPT-linked activity. That can understate exposure and delay escalation.

For DPT-linked activity, the MAS PSN02 guidance in these materials applies to payment services licence holders carrying on DPT services and should be read with the notice. MAS also states that observance can affect its overall risk assessment, including governance and internal controls. Even where threshold treatment needs legal interpretation, incomplete data coverage is still a control weakness.

Example internal operating cadence (not MAS-mandated):

Keep ownership split: Compliance for interpretation, Finance Ops for completeness and reconciliation, and Payments Ops for money-movement reality. A single-team model can work, but it raises the chance that classification errors persist.

For a US comparison point, read A Deep Dive into California's Money Transmitter License Requirements.

Eligibility and governance baseline before filing#

Before drafting, confirm that your applicant setup is actually licensable. After preliminary threshold monitoring points you toward SPI or MPI, the next gate is practical readiness: clear payment service categorization, a registered Singapore records location, and a resident director MAS can assess as fit and proper.

This work is front-loaded. If you leave it to the form-drafting stage, legal, compliance, and finance can end up in avoidable rework over applicant structure, records ownership, and governance evidence.

What to verify before first draft#

The clearest documentary checkpoint is records governance. Be able to identify the registered Singapore office address where regulatory records are kept, and align finance, ops, and compliance on one consistent records set before filing.

Director readiness needs the same discipline. The materials here support a resident director meeting MAS fit and proper criteria. If your structure depends on EP or PR assumptions, treat that as a verification item and confirm it directly with current MAS guidance and counsel before presenting it as compliant.

Governance should be tested, not narrated#

Complete governance evidence before drafting begins. At minimum, lock down the payment service category, resident director setup, records location, and accountable owners for AML and TRM controls.

A practical failure mode is writing the narrative first and validating governance later. That shows up as conflicting role descriptions, unclear AML and TRM accountability, or inconsistent records-location statements. The materials here say AML and TRM frameworks should be fully operational before launch, so internal sign-off should reject "we will build it later."

Internal sign-off before filing#

Use a three-way sign-off before submission. Legal confirms service category and applicant structure. Compliance confirms fit-and-proper readiness and AML and TRM operating readiness. Finance confirms records location, data completeness, and consistency with threshold monitoring assumptions.

Verdict: treat governance readiness as a filing prerequisite. If resident-director setup, records presence, or fit-and-proper support is still uncertain, pause and close that gap before submitting.

For a step-by-step walkthrough, see 8 Resilient Compliance Controls for Payment Platforms in 2026.

Licensing process changes that now affect execution risk#

After governance readiness, a key execution risk is scope drift, not just form completion. If your application touches Digital Payment Token (DPT) services, plan for additional verification, more document iteration, and a longer path than a stable filing with already-mapped activities.

Under the Payment Services Act 2019, Singapore regulates by activity. The materials here note that 2024 amendments expanded the DPT perimeter. That is why "front-end only" or "non-custodial" product descriptions should not be treated as safe shortcuts without a fresh scope check.

Where the pressure is highest#

Pressure is typically highest in filings where DPT functionality or exchange-like features are present. Keep a live service inventory mapped to PSA categories, including the seven payment-service categories framing, and rerun it whenever roadmap changes land, not only at drafting time.

One failure mode is treating custody as the only trigger. The materials here support a broader checkpoint: if your platform enables people to exchange virtual currency in Singapore, treat it as a licensing-scope question and escalate early.

Legal opinions and Independent External Auditor Assessment#

For legal opinions and the Independent External Auditor Assessment, the materials here do not support stating that they are universal MAS requirements for these scenarios. Treat them as verification items for your specific filing, not assumptions.

Operationally, confirm early whether additional external analysis or independent review is expected for your model, and align your evidence pack with how the service actually works.

Plan for pause risk in timelines#

The materials here do not give a complete basis for treating any reported MAS hold process as a universal, defined mechanism with fixed triggers. You should still model practical pause risk: applications can stall while scope, documents, or control evidence are clarified.

External commentary cited here reports waits of at least a year in context. That is material for launch sequencing. If DPT scope is near your roadmap, plan around verification gates and scope alignment rather than optimistic submission dates.

For the controls side of ongoing compliance, read What Is an Audit Trail? How Payment Platforms Build Tamper-Proof Transaction Logs for Compliance.

DPT variation applications and scope creep risk#

Treat DPT-adjacent feature requests as an early escalation point, not a routine release decision. In this evidence set, the exact legal trigger for a licence variation is not confirmed. The safer checkpoint is whether the proposed live service still matches your current licence narrative, activity mapping, and customer-facing description.

Recent Singapore fintech activity in tokenised assets and embedded finance, alongside higher fraud/scam pressure in cross-border and AI-driven platforms, is a practical reason to tighten scope checks before launch. A practical decision screen is simple: does this change alter how users access, move, or exchange digital value in your product? If yes, involve legal and compliance before roadmap commitment, not after engineering and commercial plans are locked.

Use existing licensing and customer-protection guidance as review anchors, but do not assume this evidence proves specific variation steps, timelines, or mandatory artifacts. If product, legal, and compliance reviews point in different directions, pause and reconcile before build.

Who owns which control across legal, finance, risk, and engineering#

Use a hybrid ownership model as an internal governance approach. Legal and compliance can make the final licensing call, while finance, risk, and engineering run early-warning signals so scope or threshold issues are caught before filing.

Finance can own threshold calculations because the limit test is a licensing control, not just a reporting exercise. Retain source data, calculation logic, and manual adjustments in each monthly pack.

Legal can own the licensing narrative, with cross-functional input. The evidence set should align service scope and governance facts. That includes business location or registered-office recordkeeping arrangements, appointed on-site complaint-handling coverage, and fit-and-proper support for controllers and directors under FSG-G01. If the service is only money-changing, escalate scope classification early because MAS indicates that path should use a money-changing licence.

Engineering can own auditability standards that make compliance evidence recoverable. The excerpts here do not prescribe a specific MAS log format. Set traceable payment-event history and reconciliation-ready records as internal standards that finance and compliance can map back to books-and-records obligations under the Payment Services Act 2019.

Centralized ownership improves filing consistency. Distributed ownership catches product changes earlier. Use an internal release gate so material payment-flow changes are reviewed for licensing impact before go-live.

Evidence and reporting checklist for monthly governance reviews#

Your monthly governance pack should answer two questions up front: are you still within your current licence perimeter, and do you have a clear escalation path if that answer changes.

The threshold sheet is the anchor. MAS says firms can apply for an SPI licence when payment services meet the thresholds, and should apply for an MPI licence when payment services exceed specified limits. Keep those threshold numbers explicit each month rather than implied in broader reporting.

Service-mix mapping is the second control that prevents false comfort. MAS also states not all payments-related activities are regulated under the PS Act. Providers that process only payment data and not money may be treated as outsourcing services. That is why scope checks should sit alongside threshold math.

Keep two regulator-facing checks as standing monthly items: a dated Financial Institutions Directory verification and a short internal alignment note to the MAS licensing guidance you rely on. The materials here do not provide a MAS-mandated monthly template, so your internal note should focus on whether current services, entity status, and scope assumptions still match the guidance.

For sign-off and escalation, define an internal matrix and apply it consistently. Escalate to external counsel when you cannot confidently classify a live or planned activity using MAS primary materials. Do the same when operations may be shifting between data handling and money handling, when thresholds are breached or likely to be breached, or when a roadmap change may require licence variation.

Before your next monthly review, map each control owner to implementation evidence and escalation paths in one place. The Gruv docs can help legal, finance, and engineering align on an audit-ready operating model.

High-cost mistakes that create regulatory surprises#

Regulatory surprises often come from a few avoidable mistakes. Teams use secondary summaries as if they were authoritative, wait too long to escalate when they are nearing licensing decision points, or approve DPT-related scope changes before compliance evidence is ready.

Use third-party explainers as prompts, not conclusions. MAS primary materials should be your decision anchor, especially for licensing interpretation and AML and CFT expectations.

Threshold misses are often governance misses, not just math misses. If you are moving closer to your current limits, increase control depth early so escalation is deliberate rather than reactive.

DPT changes deserve earlier escalation#

MAS states DTSPs may be more susceptible to ML and TF risk because the services are internet-based and cross-border. MAS also states it will license DTSPs in a prudent and cautious manner, in extremely limited circumstances, and without a transitional arrangement. Those points do not automatically determine your platform's status, but they do signal that token-scope expansion should never be treated casually.

For token-adjacent changes, keep the evidence pack ready before build approval: product scope, flow mapping, service-classification note, and AML and CFT control mapping. At minimum, that mapping should cover customer and beneficial-owner identification, account review, and suspicious transaction monitoring and reporting where relevant.

Build enough control for your stage, not for a hypothetical future#

Overbuilding too early can slow execution. Underbuilding near key triggers can create expensive rework. The practical approach is to keep controls lean but documented when scope is stable, then increase formality as proximity and scope complexity rise.

MAS notices can change the answer#

Do not assume an earlier analysis remains current. MAS AML/CFT Notices and related Guidelines set requirements and supervisory expectations, so check the latest MAS materials during launch and change approval even when your base licence view appears unchanged.

Scenario recommendations for common platform profiles#

Use a forward-looking lens: decide for the next planning cycle of scope and volume, not only today's footprint. If services and volume are stable and clearly below applicable limits, an SPI-oriented posture may be workable. If growth or scope is moving, start MPI readiness early. Treat SPI/MPI limit assumptions as provisional until you confirm them against MAS primary materials and legal advice.

A fast-scaling platform should also treat timeline risk as real. Third-party legal commentary in these materials reports licence processing periods of at least a year, so parallel preparation is usually the safer operating posture.

For DPT-related scope, apply a harder gate. Singapore's regime is activity-based, and 2024 PSA amendments expanded regulated DPT services. Front-end trade-arranging models can fall inside scope even without taking possession of DPTs.

Related reading: Accounting Cycle for Payment Platforms: How to Structure Month-End and Quarter-End Close.

Conclusion#

SPI versus MPI is not just a filing label. In practice, it is an operating commitment you should revalidate as volumes, services, and product scope change.

If you are operating near your assessed SPI thresholds or planning a new payment feature, treat that as an escalation point, not routine monitoring.

Process changes effective 26 August 2024 and DPT-related submission requirements can increase execution risk, so treat timeline assumptions cautiously and verify current filing requirements before you submit.

A practical control choice is a monthly threshold review, even though these excerpts do not state a mandatory MAS monthly cadence. The real test is whether you can quickly produce dated records showing why your current licence position is still appropriate.

If your team is designing cross-border payout infrastructure, map these controls into product and finance operations early and confirm Singapore scope and jurisdiction-specific coverage before launch.

If your roadmap could push you from SPI toward MPI obligations, contact Gruv to validate coverage, compliance gating, and rollout assumptions before you lock launch timelines.