Singapore’s open banking framework under the Monetary Authority of Singapore (MAS) and the UK’s Payment Services Directive 2 (PSD2) operate on fundamentally different architectures, yet both achieve similar outcomes: incumbent bank disruption and fintech acceleration. Understanding how they differ—in governance, API standards, consent mechanisms, and liability allocation—matters urgently for any financial services firm building products across both jurisdictions.
The Core Architecture Difference: Prescriptive vs. Principles-Based
The MAS framework is prescriptive. It mandates exactly which APIs banks must expose, in what format, on what timeline. The UK’s PSD2 is principles-based: it requires “secure, open connectivity” but leaves substantial discretion to industry on implementation standards.
This distinction shapes everything downstream. Under MAS’s Open API Governance Framework (launched 2018, expanded repeatedly since), all participating banks must expose identical datasets: accounts, transactions, payees, and beneficiaries. The payload structure, authentication protocol, and rate limits are standardized centrally. A UK open banking developer, by contrast, encounters fragmented implementations across 8,000+ regulated entities—each interpreting PSD2’s vague requirement for “strong customer authentication” and “secure open connectivity” differently.
MAS publishes detailed technical specifications. PSD2 does not. The Open Banking Implementation Entity (OBIE) in the UK produces industry-led standards, but these are advisory, not mandated. That creates compliance headaches for third-party providers (TPPs) in the UK, who must test against multiple bank implementations. In Singapore, you test once against the standard.
Governance and Authority: Central Mandate vs. Market-Driven Consensus
The MAS can unilaterally impose timelines and technical requirements. Banks must comply or face enforcement. When MAS expanded the framework in 2021 to include broadband APIs and infrastructure APIs, it didn’t ask permission—it issued a directive.
The FCA and PSD2, by contrast, operate through a combination of regulatory requirement and industry coordination. The FCA sets the rule (third parties have the right to access payment account data), but the OBIE—a standards body owned by major UK banks—negotiates the “how.” This creates a softer landing for incumbent banks but slower, messier adoption for fintech.
Result: Singapore’s framework reached nearly 100% bank participation within 18 months. The UK took four years to achieve comparable coverage, and even now, smaller banks frequently don’t meet OBIE’s published API standards.
For compliance teams, this means a Singapore open banking build is predictable; a UK build is not. You’re not just coding to a spec; you’re managing deviation risk across dozens of implementations.
Consent Architecture: Pre-Authorised Access vs. Per-Transaction Approval
MAS permits pre-authorised, persistent access to account data. Once a customer consents to a third-party app (e.g., an aggregation app, a budgeting tool), that app can pull transaction history and balances repeatedly without re-authentication. Consent is revoked at the customer’s discretion, but no per-pull approval is required.
PSD2 mandates re-authentication for “out-of-scope” payments and higher-risk transactions, and the 2019 RTS (Regulatory Technical Standards) introduced the concept of dynamic linking for remote payments. This means a UK user authorising a £500 payment must explicitly approve that transaction in real time, not just once at app onboarding.
The practical implication is user experience divergence. A Singapore aggregator app (e.g., a wealth dashboard) can refresh balances invisibly in the background. A UK equivalent must prompt the user frequently or accept rate-limited access.
For open banking fintechs, this changes your product roadmap. Singapore lets you build “set and forget”; the UK forces you toward “user-in-the-loop” design. Neither is wrong, but they’re incompatible architectures.
Scope: What Gets Opened and to Whom
MAS’s open banking framework has broadened over time but remains tightly controlled. Phase 1 opened accounts and transactions. Phase 2 (2021) added fund transfer capabilities. Phase 3 was conceptual—exploring infrastructure APIs for interbank connectivity. The scope is decided by MAS, not by market demand.
PSD2 is radically broader in principle. Any “payment service provider” or “account information service provider” (AISP) can request access. PSD2 doesn’t distinguish between a major fintech and a weekend hobbyist—the right to access is statutory. This creates security and fraud risk that UK regulators have never fully solved.
Additionally, PSD3 (the successor to PSD2) is expanding scope further, opening credit data, payment data, and soon possibly insurance and investment data. Singapore’s framework, by comparison, expands methodically and only when MAS is satisfied the infrastructure is ready.
For third-party developers, Singapore’s controlled scope means less disruption but fewer opportunities. The UK’s open scope means explosive innovation but fragmented security posture.
Liability and Fraud Risk: Who Bears the Cost
Under MAS’s framework, participating banks are liable for API security. If an AISP’s credentials are compromised, the bank bears the fraud loss (within limits). This creates strong incentive for banks to police third-party security rigorously.
PSD2’s liability model is muddled. Banks are liable for unauthorised transactions initiated by AISPs only if the customer didn’t consent. If the customer consented (even if the AISP later goes rogue), the customer often bears the loss. This incentivizes customers to be cautious with third-party access—a benefit to incumbents, a brake on innovation.
The UK’s FCA has increasingly pushed back against this, requiring banks to refund fraud on AISPs in certain cases, but it’s not codified as clearly as Singapore’s model.
A compliance officer evaluating open banking risk in Singapore needs to focus on API security and third-party monitoring. In the UK, you must also model the statutory liability gap and the likelihood of regulatory pushback.
Standards and Technical Implementation
| Dimension | Singapore (MAS) | UK (PSD2 / OBIE) |
|---|---|---|
| Authentication Standard | OAuth 2.0 (centrally specified) | OAuth 2.0 (recommended, not mandated) |
| API Format | RESTful (MAS standard) | RESTful (OBIE standard) |
| Data Format Standardization | Highly prescribed (JSON schema published by MAS) | OBIE standards published; compliance varies |
| Consent Revocation | Customer-initiated, no time limit | Per-transaction or periodic re-auth required |
| Rate Limiting | Centrally mandated (e.g., 100 calls/min) | Bank-specific policies |
| Onboarding Third Parties | MAS registry and approval process | Self-registration; FCA supervision post-hoc |
What Does “Secure API” Mean in Practice?
In Singapore, “secure” has a specific definition: TLS 1.2 minimum, mutual TLS, certificate pinning in mobile apps, rate limiting, and audit logging. MAS has published these in its technical guidance. Banks implement identically.
In the UK, “secure” is left to interpretation. Some banks implement certificate pinning; others don’t. Some use mutual TLS; others use token-based auth only. The FCA hasn’t mandated a single approach. This creates a lowest-common-denominator risk: if one bank’s API is compromised, the entire ecosystem loses trust, but the regulatory framework doesn’t prevent it.
For a fintech building in both markets, this means dual security architecture. Your Singapore API integration can assume certain hygiene standards. Your UK integration must test each bank individually.
Regulatory Enforcement and Remediation
MAS enforces open banking compliance tightly. Banks that miss timelines or don’t expose required APIs face enforcement action. The 2020-2022 period saw MAS issue public statements calling out non-compliant banks by name.
The FCA enforces PSD2, but enforcement is largely reactive (post-breach) rather than proactive (pre-deployment). There’s no equivalent to MAS’s regular compliance audits. The FCA fines individual firms for failures, but the framework itself is rarely adjusted after enforcement.
This matters for your compliance calendar. In Singapore, expect regular audits and policy updates. In the UK, expect fewer audits but higher-stakes enforcement when failures occur.
Open Banking Beyond Payments: The Roadmap Divergence
MAS is exploring infrastructure APIs that would enable interbank settlement, cross-currency transfers, and algorithmic liquidity matching. This is years away, but the vision is a fully connected financial ecosystem where data and value can move without intermediaries.
The UK’s roadmap (via PSD3 and Open Finance initiatives) is broader in scope but less structured. Regulators are pushing for insurance data, investment data, and credit data to open. But there’s no central technical architecture. Each asset class will have its own standard, negotiated industry-by-industry.
What Gets Opened on Day One vs. What’s Queued
Singapore’s phased approach meant Day One (2018) was narrow: accounts, transactions, payees. Scope expanded only after proving the infrastructure worked. This reduced risk of large-scale fraud or systemic failure.
The UK opened broadly from inception: any AISP can request account and transaction data. This drove faster innovation but also created the FCA’s ongoing headache of managing fraud and consumer harm from rogue AISPs.
For a bank planning open banking product strategy, Singapore’s phased model suggests starting with core use cases (aggregation, budgeting) and only expanding as fraud and operational risk are demonstrably controlled. The UK’s broad-scope lesson is that you can’t assume third parties will be trustworthy, so your liability model must account for that.
Direct Answer: Which Framework Should You Build For First?
If you’re a UK-based fintech, start with UK open banking—the market is larger and the regulatory requirement is real. If you’re Singapore-based or expanding to Asia-Pacific, build for Singapore first; the framework is simpler, the technical surface is smaller, and compliance is faster. If you’re a global bank, implement Singapore first (to prove you can execute the standard), then apply those learnings to the UK’s fragmented landscape.
The Algoy Perspective
Most practitioners compare Singapore and UK open banking on headline metrics (API coverage, third-party count, transaction volume). That’s wrong. The real difference is in liability allocation and governance resilience.
Singapore’s MAS has centralized liability: the bank pays for API security failures, and MAS audits that. The UK’s system distributes liability across customers, banks, and regulators—and nobody is fully liable. When something goes wrong in Singapore, it’s clear who pays and how. In the UK, expect litigation.
This has an immediate implication: if you’re building a high-value use case (trading, institutional settlement, cross-border payments), Singapore’s framework is more defensible. If you’re building high-volume consumer apps (aggregation, budgeting), the UK’s fragmentation is actually an advantage—you can choose which banks to integrate with based on their API maturity, rather than being forced to support all of them.
Frequently Asked Questions
Is Singapore open banking compatible with UK open banking standards?
No. Both use REST and OAuth, but the data schemas differ. A Singapore API payload (MAS standard) will not validate against UK OBIE schemas without transformation. You’ll need an adapter layer if you’re building cross-jurisdiction products.
Which framework moved faster from regulation to full bank compliance?
Singapore. MAS issued the framework in 2018; by end of 2019, all major banks had live APIs. The UK’s PSD2 was effective January 2018, but OBIE standards didn’t solidify until 2019, and full compliance across all FCA-regulated entities took until 2022. Prescriptive regulation moves faster.
Can a UK bank use Singapore’s MAS open API standards for their international arm?
Partially. Some UK banks operating in Singapore do build to MAS standards. But the UK bank’s UK operations must comply with OBIE standards. You’re running dual systems, not a unified one.
Does MAS mandate which third parties can access the APIs?
Yes, via a registration and approval process. The UK’s FCA allows self-registration; you just notify the FCA. Singapore’s model is more stringent—MAS retains veto power over new AISP applicants.
