Singapore’s open banking framework operates under the Monetary Authority of Singapore (MAS), creating a significantly different operational and compliance landscape than the UK’s PSD2-driven model. While both jurisdictions mandate third-party access to banking data, the MAS framework prioritizes bilateral negotiation between banks and fintechs, whereas the UK enforces standardized APIs and transparent pricing—a critical distinction for any firm operating across both markets.
The MAS Open Banking Architecture: Bilateral Trust Over Standardized APIs
Singapore’s open banking framework, introduced in 2019 through the Payments Systems Act amendments and reinforced by MAS guidelines, does not mandate a single standardized API specification. Instead, the MAS requires banks and third-party service providers (TPPs) to establish bilateral agreements governing data access, security protocols, and liability allocation. This bilateral-first approach means that a fintech seeking to aggregate transaction data from three Singapore banks must negotiate three separate technical integrations, each with different API specifications, authentication standards, and data formats.
The UK’s Payment Services Directive 2 (PSD2), in contrast, mandates that all banks expose standardized Open Banking APIs with consistent endpoints, response formats, and authentication via OAuth 2.0. A PSD2-licensed payment initiation service (PISP) can build a single integration and connect to any of the UK’s major retail banks without renegotiating technical terms. This architectural difference has profound operational consequences: a compliance officer managing a cross-border fintech must maintain separate audit trails, security assessments, and data-handling procedures for Singapore versus UK operations, even if the underlying business logic is identical.
MAS does not publish detailed API specifications itself; instead, it expects banks to publish their own technical documentation and security standards. This creates fragmentation but also gives individual banks latitude to implement proprietary enhancements—such as transaction categorization or real-time fraud scoring—that competitors cannot easily replicate. UK banks, constrained by the standardized Open Banking specification, compete instead on speed of data delivery, breadth of historical data exposure, and downstream application features rather than API design.
Regulatory Scope: Narrow in Singapore, Broad in the UK
MAS’s open banking remit is narrower than the FCA’s PSD2 enforcement. In Singapore, open banking primarily applies to retail banking data (transaction accounts and payment initiation) and covers only institutions licensed as banks or finance company. Investment portfolios, insurance products, and securities holdings are explicitly excluded from MAS open banking requirements, though they may be covered under separate regulatory frameworks for specific services.
The UK’s PSD2 applies to all payment service providers—including e-money institutions, mobile payment operators, and API-driven fintechs—and the subsequent evolution toward PSD3 expands scope to investment services and open finance more broadly. A UK firm must apply PSD2 Strong Customer Authentication (SCA) rules to all payment transactions above €50, with limited exemptions. The MAS does not prescribe a single authentication standard; instead, it requires banks to implement “appropriate security measures” determined through bilateral risk assessment, which typically results in multi-factor authentication but allows banks flexibility in implementation.
This regulatory narrowness in Singapore has allowed certain categories of fintech—such as investment robo-advisors and insurance aggregators—to operate without triggering MAS open banking obligations, whereas a UK equivalent would likely fall under FCA scope if it processes payments or holds funds.
Consumer Data Rights and Consent Management
Both frameworks require explicit consumer consent before third parties access banking data, but the mechanisms differ materially. The UK’s PSD2 mandates that consent be collected through a standardized user journey: the consumer is redirected to their bank’s authentication portal, logs in, grants permission to the TPP for a specified scope of access (read transaction history, initiate payments), and is redirected back to the TPP’s application. The bank must record this consent and make it auditable to the FCA and other regulators.
Singapore’s bilateral model allows banks greater discretion in designing the consent mechanism. Some banks use a similar redirect model; others use in-app consent tokens, email-based approval, or SMS-triggered authorization. While MAS requires consent to be documented and managed securely, there is no mandatory standardized consent UI or revocation mechanism across all banks. A consumer revoking access to their transaction data may use different procedures with different Singapore banks, whereas UK consent withdrawal follows a consistent pattern across all PSD2-regulated institutions.
For cross-border compliance teams, this creates a tactical headache: firms operating in both markets must build consent management systems that can handle two distinct consent architectures, audit trails, and revocation workflows. A single consent management platform may need to support both standardized PSD2 workflows and custom Singapore bank-specific procedures.
Data Retention, Security Audits, and Liability
The UK’s PSD2 framework establishes shared liability: if a bank’s API leaks consumer data due to inadequate security, both the bank and the TPP can face FCA enforcement, though liability allocation depends on the terms of their API agreement and the nature of the breach. The Open Banking Standard specifies minimum encryption, timeout, and rate-limiting requirements; banks cannot opt out of these without losing PSD2 compliance.
MAS’s bilateral approach means that liability for a data breach is negotiated in each bank-TPP contract rather than prescribed by regulation. Some agreements place primary liability on the bank for infrastructure security; others require the TPP to bear responsibility for application-layer vulnerabilities. This flexibility allows banks and fintechs to allocate risk according to their specific risk appetite, but it also means that a fintech’s exposure to liability can vary by bank. A security incident at one Singapore bank partner might trigger remediation costs, regulatory censure, and consumer compensation, while a similar incident at another bank might fall entirely under the bank’s liability due to contractual allocation.
Data retention periods are likewise negotiated bilaterally in Singapore. MAS does not specify a maximum retention window for transaction data accessed via open banking APIs (though it does impose a 6-year retention floor for consumer protection documentation). UK PSD2 rules require that TPPSs delete transaction data within a specified period (typically 90 days from consent withdrawal or transaction completion) unless the TPP is processing payments on behalf of the consumer, in which case longer retention is permitted for legal compliance purposes.
Testing, Certification, and Onboarding Timelines
In the UK, a new PISP or account information service provider (AISP) can expect a standardized testing process: connect to the Open Banking Directory, register API credentials, complete sandbox testing against the standardized Open Banking API, and go live within 4–8 weeks, depending on regulatory approval speed. The FCA publishes a Regulatory Technical Standards document that governs the testing criteria; the TPP knows upfront what will be tested and what constitutes pass/fail.
Singapore offers no equivalent pre-published testing standard. Each bank manages its own sandbox environment, testing requirements, and approval process. A fintech seeking access to three Singapore banks may face three different testing methodologies, approval timelines ranging from 4 weeks to 16 weeks, and different criteria for production cutover. This fragmentation favors large fintechs with dedicated integration teams and disadvantages smaller players that lack the resources to manage multiple bilateral onboarding flows in parallel.
MAS does require banks to publish Service Level Agreements (SLAs) covering API availability and response times, but these are bilateral contracts rather than standardized minimums. Some Singapore banks publish 99.9% uptime guarantees; others commit only to “best efforts.” UK banks are required to meet minimum SLA thresholds set by the Open Banking Standard and monitored by the regulator.
Cross-Border Payment Initiation and Open Finance Expansion
The MAS framework does not currently mandate open banking for cross-border payments or currency conversion. A UK consumer using a PSD2-licensed cross-border payment initiator can send funds to a Singapore beneficiary with the transaction initiated through the UK bank’s standardized API. However, if a Singapore TPP wishes to initiate payments for Singapore consumers to overseas accounts, it must negotiate bilateral access with each participating Singapore bank—the MAS does not require banks to expose cross-border payment APIs on the same terms as domestic transaction initiation.
In practice, this means that remittance operators and cross-border fintech platforms often find it easier to launch in the UK (where PSD2 PISP status grants automatic API access to all banks) than in Singapore (where they must establish bilateral relationships with each bank, which may take 6–12 months). This regulatory asymmetry is a primary reason why UK-headquartered cross-border payment platforms have scaled faster than Singapore-based competitors.
The MAS has signaled interest in “open finance” (extending open banking principles to insurance, investment, and savings products), but no mandatory framework exists yet. The UK’s trajectory is clearer: the FCA and HM Treasury have published consultations on Open Finance, which would extend PSD2-like API mandates to investment services and general insurance beginning in the coming years. A firm planning a 3–5 year product roadmap in investment aggregation faces regulatory certainty in the UK (PSD2 PII data, Open Finance framework pending), but significant uncertainty in Singapore (voluntary bank cooperation, no published timeline for mandatory open finance).
What Regulators Require: Governance and Consumer Harm Prevention
Both the MAS and the FCA require that TPPs maintain robust data governance, security, and consumer redress procedures, but the regulatory tone differs. The FCA publishes detailed Handbook rules and expects firms to demonstrate compliance through point-in-time certifications (often every 12 months). MAS takes a principles-based approach: banks and TPPs are expected to maintain “appropriate” security and governance, but MAS does not publish a checklist of required controls. Instead, it expects firms to self-assess risk and justify their control choices in writing to MAS during examinations.
For a compliance team managing both jurisdictions, this means: in the UK, you build a documented controls framework that maps explicitly to FCA Handbook sections; in Singapore, you build a risk-based framework that you can defend to MAS auditors on principles of proportionality and effectiveness. The UK framework is more prescriptive but also more predictable; the Singapore framework is more flexible but carries higher interpretation risk.
Direct Answer: How Do the Two Frameworks Differ in Practice?
The MAS open banking framework requires bilateral bank-TPP agreements with negotiated API specifications, while the UK’s PSD2 mandates standardized APIs, transparent pricing, and regulatory oversight. In Singapore, onboarding takes 4–16 weeks per bank; in the UK, standardized testing enables go-live within 8 weeks across all banks. UK frameworks apply to investment and insurance services; Singapore’s remains limited to retail banking. For fintech operators, UK open banking offers speed and scale; Singapore offers flexibility but fragmentation.
The Algoy Perspective
Most articles comparing open banking frameworks focus on theoretical differences in API design or consent mechanisms. The genuine competitive friction for fintech practitioners lies in the liability and liability-management gap: in the UK, PSD2 liability is standardized and regulated; in Singapore, it is negotiated, which means a fintech’s legal exposure can differ substantially across bank partnerships. A sophisticated fintech will conduct a bilateral liability audit across its Singapore bank partners and identify which partners bear infrastructure security risk, which require the fintech to fund cyber insurance, and which create asymmetric exposure if a breach occurs. Banks, conversely, have discovered that TPPs willing to bear liability become preferred partners—even if the deal is less attractive—because it reduces bank audit burden and regulatory scrutiny. This liability arbitrage is invisible in public frameworks but governs deal flow in practice.
