Singapore’s open banking direction in 2026 is broader than the familiar idea of one app reading another bank account. The system now combines consent-based financial data sharing through SGFinDex, bank-specific APIs used by businesses and technology partners, and national payment rails such as FAST and PayNow. The next phase is moving toward richer payment data, tighter system-to-system integration, more cross-border connectivity and new automated payment use cases. Singapore has developed this model through industry guidance and shared infrastructure rather than a single PSD2-style rule that requires every bank to expose the same API set.
Open Finance
Bank APIs
SGFinDex
PayNow Gen2
Singapore’s Open Banking Model in 2026
Singapore does not operate a single mandatory open-banking regime equivalent to the European Union’s PSD2 model. The Association of Banks in Singapore published its Finance-as-a-Service API PlayBook in 2016, developed in consultation with the Monetary Authority of Singapore, as guidance for financial institutions, FinTech firms and other entities adopting open API architecture. Banks have since developed their own API portals and commercial integration models, while public infrastructure has handled parts of identity, consent and financial-data exchange.
The practical result is a layered system. A consumer using SGFinDex, a corporate treasury team connecting an ERP system to a bank, and a merchant receiving PayNow payments may all be using APIs, but they are using different parts of Singapore’s financial infrastructure. The Association of Banks in Singapore also plays an industry coordination role alongside MAS.
The Four Connected Layers
Singpass and consent controls establish who is requesting access and what data may be retrieved.
SGFinDex links participating banks, insurers, SGX CDP and government-held financial information for authorised financial planning use.
Bank APIs expose selected functions such as balances, transactions, payments, collections, notifications and foreign-exchange services, subject to each bank’s access model.
FAST, PayNow, SGQR, GIRO and related schemes move or support payments. They solve a different problem from financial-data aggregation.
Practical distinction: an API portal does not mean every developer can obtain production access to every customer-data or payment function. Sandbox access, partner onboarding, customer consent, commercial eligibility and production approval can differ by bank and API.
SGFinDex Has Moved the Discussion Beyond Bank Accounts
SGFinDex is the clearest example of Singapore moving from narrow open banking toward open finance. It links financial information from participating banks with investment, insurance and government-held information, then makes that information available through participating financial planning applications after user consent.
SGFinDex users reported by GovTech on 29 April 2026.
Connected bank accounts in the same GovTech snapshot.
Data retrievals facilitated by SGFinDex in that snapshot.
Those figures describe a published snapshot rather than a live counter. GovTech’s April 2026 page identifies SGFinDex as a joint initiative involving MAS, the Smart Nation and Digital Government Group, ABS and participating banks.
| Data Group | Current Examples | What It Adds |
|---|---|---|
| Banks | Citi, DBS/POSB, HSBC, Maybank, OCBC, Standard Chartered and UOB | Banking-related financial data from participating institutions |
| Insurance | AIA Singapore, HSBC Life, Great Eastern, Income, Manulife Singapore, Prudential Singapore and Singlife | Insurance information for a wider financial-planning view |
| Investments | SGX Central Depository | CDP-held investment information |
| Government Data | CPF Board, HDB and IRAS information through Myinfo | Selected public-sector financial information relevant to personal financial planning |
How Consent and Retrieval Work
The user enters the SGFinDex flow with Singpass.
The user links participating banks, insurers and/or SGX CDP. Myinfo data is linked for retrieval in the SGFinDex flow.
The selected financial application obtains consent before retrieving the authorised information.
The participating financial institution can present a consolidated financial-planning view to the user.
The current SGFinDex website states that data is retrieved only with consent, that financial institutions must obtain consent for retrieval, and that only the authorised financial institution can see the retrieved data. SGFinDex itself is not presented as a central place where participating institutions can freely browse one another’s customer information. Its published API specification uses OAuth 2.0-based authorisation for consent and data retrieval.
Revoking access has a limit: revocation stops updated data from the selected contributor being retrieved through SGFinDex. The official FAQ also states that data already retrieved by another participating financial institution may remain in that institution’s records because financial institutions have data-retention obligations.
What SGFinDex Does Not Replace
- It is not a bank account or mobile banking application.
- It is not FAST and does not itself serve as the domestic fund-transfer rail.
- It is not PayNow and does not turn every data-sharing action into a payment instruction.
- It is not a universal public API that gives any developer unrestricted access to participating-bank customer data.
- It does not make account-information permission and payment-authorisation permission the same thing.
Bank APIs Are Already Used for More Than Data Sharing
Open banking in Singapore is often discussed as account aggregation, yet current bank developer and corporate API offerings cover a wider set of tasks. Public documentation from DBS, OCBC and UOB shows APIs being used for information retrieval, payments, collections, notifications and other banking functions.
| Bank | Examples in Public Documentation | Access Context |
|---|---|---|
| DBS | Deposit accounts, loans, cards, FX rates, bill payments, fund transfers and GIRO | Developer documentation and sandbox-style developer resources; production use depends on the relevant API and onboarding route |
| OCBC | Corporate PayNow QR, payment collection, credit notification, authorisation and API testing | CONNECT2OCBC supports registration and sandbox testing; transactional production access is subject to the bank’s process |
| UOB | Balance enquiry, transaction history, FAST and PayNow payments, collections, PayNow lookup, eDDA, corporate refunds, notifications and FX | UOB describes the service as available to corporate clients, with bank onboarding for API use |
These examples should be read as evidence of available API capabilities, not as a promise that every API is open to every company on identical terms. Public developer documentation shows what can be explored; production credentials and operational permissions are a separate step.
Corporate Banking Is One of the Most Mature API Use Cases
The corporate use case is especially clear because an API can remove manual steps between a company’s finance software and its bank. UOB, for example, describes two-way real-time communication between client systems such as treasury workstations or ERP systems and the bank.
The company creates a payment instruction, requests a balance or checks transaction history inside its own software.
The approved request is sent through the bank’s API connection using the bank’s authentication and entitlement controls.
The bank processes the permitted action, which may involve account information, FAST, PayNow, collections, eDDA or FX.
Payment status, transaction data or credit/debit notifications can return to the company system and reduce manual matching work.
Bank Feeds, APIs and Payment Rails Solve Different Problems
The terms are often grouped together because they all connect software with banking, but their jobs differ. A bank feed can import transactions into accounting software. SGFinDex can retrieve authorised financial data for a consolidated planning view. FAST moves Singapore-dollar funds between participating institutions, while PayNow provides a proxy-based payment experience on top of Singapore’s instant-payment infrastructure.
| Technology | Primary Function | Shares Financial Data | Moves Money | Typical Use |
|---|---|---|---|---|
| Bank API | Exposes selected bank functions to approved software | Can, depending on API and permission | Can, for payment APIs | ERP banking, account data, payments, collections, notifications |
| Bank Feed | Imports account transactions into another software product | Yes, within the feed scope | Usually no | Accounting and reconciliation |
| SGFinDex | Consent-based financial-data exchange | Yes | No direct payment-rail role | Consolidated financial planning |
| FAST | Domestic real-time SGD fund transfer | Not its main job | Yes | Account-to-account transfers in Singapore |
| PayNow | Proxy and QR-based payment experience | Not its main job | Yes, through supported payment infrastructure | Mobile, NRIC/FIN, UEN, VPA and QR-based payments |
| SGQR | Common QR display standard for supported payment schemes | No | The underlying payment scheme does | Merchant QR acceptance |
No matching rows found.
For the domestic transfer layer, FAST transfers in Singapore explain the real-time account-to-account rail. PayNow sits closer to the user experience because it lets users address payments through registered identifiers and QR flows rather than always entering a full account number.
PayNow Generation 2 Is the Clearest 2026 Signal
On 25 June 2026, MAS and ABS announced a PayNow Generation 2 study covering four priority areas selected after consultations with 37 organisations and benchmarking against 11 jurisdictions. The announcement is useful because it separates near-term pilots from longer-term payment capabilities.
| PayNow Gen2 Area | Planned Change | Published Timing |
|---|---|---|
| QR interoperability | Improve interoperability between PayNow and NETS QR so consumers can scan and pay across the two merchant-acquiring schemes more easily | Pilot targeted by end-2026 |
| Online checkout | Use deep-linking within PayNow QR flows to reduce the need to save a QR, switch apps, upload it and return to the merchant site | Targeted to be ready within a year of the June 2026 announcement |
| Larger public-sector payments | Test larger-value PayNow transactions for government agencies with transaction limits and safeguards | Sandbox with government agencies planned for 2027 |
| Expanded payment capabilities | Study request-to-pay, structured data, micro-payments, cross-border connectivity, offline payment capabilities and functions for agentic commerce | Foundational work in 2026; implementation roadmap planned by end-2026 |
Status matters: these items should not all be described as live PayNow features. The June 2026 announcement labels several as pilots, planned work or longer-term capabilities, with more implementation detail due in the next phase.
Users looking at the current service rather than future development can separate these plans from the existing PayNow setup in Singapore, which covers the live proxy and QR payment model.
Structured Payment Data Could Change Reconciliation
Payment speed is only one part of business efficiency. A payment can arrive instantly and still create manual work if a finance team cannot reliably determine which invoice, order or customer record it belongs to. PayNow Gen2 specifically lists structured data fields for automated reconciliation among the longer-term capabilities under study.
A structured payment message could carry machine-readable references such as an invoice number, order reference or other agreed payment information. The business system could then match the incoming payment to the correct receivable without relying on a free-text remark or manual lookup.
The business system assigns a unique invoice or order reference.
The relevant reference travels with the payment instruction in a defined data field.
The company receives the payment and associated structured information.
Software can close the matching invoice automatically and send only exceptions for review.
Request-to-Pay Adds a New Collection Flow
Request-to-pay is different from a transfer that starts with the payer. A business, biller or public agency can send a structured request first; the payer then reviews and authorises the payment. This can be useful for invoices, recurring collections and payment requests that need clear references. PayNow Gen2 lists request-to-pay as a capability for further development, so it should be treated as a direction under study rather than a universal live function.
Agentic Commerce Raises a Different API Question
The PayNow Gen2 announcement also names new functions to facilitate agentic commerce. The official material does not define a production design or state that software agents will receive unrestricted authority to spend from bank accounts. A workable banking model would need explicit permissions, transaction limits, authentication, approval rules, revocation controls and an audit trail.
A controlled business scenario could allow software to prepare a purchase and payment request inside a permitted policy, then require human approval above a set threshold. APIs matter because the agent, merchant system, bank and reconciliation software need machine-readable ways to exchange instructions and status information. The exact PayNow implementation remains to be scoped.
SPaN Is Reorganising National Payment Governance
Singapore Payments Network Limited, or SPaN, was incorporated on 25 June 2025 as a not-for-profit company limited by guarantee established through a public-private partnership between MAS and ABS. Its role is to consolidate administration and governance of Singapore’s national payment schemes and work with MAS on national payments strategy.
The incorporation announcement set a target for SPaN to reach an operationally ready state by the end of 2026. The current SPaN website still describes operationalisation as in progress. That distinction matters: SPaN already exists as an entity, while the transition of national scheme administration is still being operationalised.
SPaN is not a consumer open-banking application. It does not replace SGFinDex and it is not a banking app. Its relevance to APIs comes from governance of the payment layer that banks, payment institutions, merchants and software integrations depend on.
Singapore’s national payment schemes include FAST, GIRO, PayNow and SGQR. Bringing scheme administration under a more unified governance structure can make future payment upgrades easier to coordinate across institutions, especially where interoperability, common operating rules and cross-border connections are involved.
Cross-Border Connectivity Is Becoming Part of the Same Infrastructure Story
Singapore already has live payment connections beyond its domestic banking system. PayNow has cross-border linkages with Thailand’s PromptPay, India’s UPI and Malaysia’s DuitNow, while merchant QR arrangements also connect Singapore users with overseas QR networks. These are payment-network connections rather than permission to read a customer’s foreign bank data.
PayNow Gen2 places expanded cross-border connectivity among the longer-term capabilities to be developed. That points toward a model where domestic instant payments, bank APIs and international payment links become easier for software and institutions to combine. Users making retail payments abroad can see the current practical distinction in cross-border QR payments.
Permissioned retrieval of financial information from participating sources, as seen in SGFinDex.
Movement of funds or payment messages across domestic and cross-border rails, as seen in FAST, PayNow and linked overseas systems.
Security and Consent Will Set the Pace of Expansion
More API connectivity creates more machine-to-machine traffic and more permissions that must be controlled. The relevant controls depend on the service, but the recurring needs are clear: authenticated clients, limited entitlements, encrypted transport, short-lived credentials where appropriate, consent records, transaction controls, monitoring and auditable actions.
SGFinDex provides one concrete example. Its public API specification uses OAuth 2.0-based authorisation and includes token, consent, data-retrieval and revocation flows. The consumer-facing service is underpinned by Singpass, and the official SGFinDex site says retrieved data is encrypted so that only the authorised financial planning application can decrypt it.
The 2026 AI discussion has also entered financial-sector security. On 28 July 2026, MAS and ABS announced the AI-Driven Cyber and Technology Risk Taskforce, with participation from MAS, ABS, DBS, OCBC, UOB, SGX, NETS and Banking Computer Services. Its work covers industry collaboration, capability development and guidance for responding to AI-enabled cyber risks. That work is broader than open banking, but it is relevant to an API environment where automated systems can initiate or influence more financial actions.
What Is Actually Set to Change After 2026
- PayNow and NETS QR interoperability pilot targeted by end-2026.
- PayNow Gen2 implementation roadmap planned by end-2026.
- Government larger-value PayNow sandbox planned for 2027.
- SPaN operational readiness targeted by end-2026.
- More structured payment data and automated reconciliation.
- Request-to-pay and deeper merchant checkout integration.
- More system-to-system corporate banking.
- More cross-border payment connectivity.
- Stronger permission and security controls for automated services.
- Whether Singapore will ever adopt one mandatory national bank-API standard comparable to PSD2.
- The final scope and timing of agentic-commerce payment functions.
- How far SGFinDex participation and data categories will expand beyond the current contributors.
- Which PayNow Gen2 concepts will become production services after the study and pilots.
The direction is therefore broader than account aggregation. Singapore’s financial infrastructure is moving toward a combination of consented open finance, embedded bank functions, real-time payment rails and richer machine-readable payment messages. The exact shape remains service-specific: SGFinDex governs a consented data-retrieval use case, banks control access to their own APIs, and national payment upgrades follow their own scheme and implementation processes.
What the API Shift Means for Different Users
More financial information can be viewed together through authorised planning applications without giving one bank the login credentials for another bank.
Payments, collections and reconciliation can move closer to accounting or operations software, reducing file exports and manual matching.
ERP and treasury systems can communicate directly with bank services for balances, transaction data, payments, collections and FX where the bank supports the relevant API.
More financial functions are available through APIs, but access remains tied to the relevant bank, service, consent model, technical requirements and production onboarding.
Verification Notes
Current factual checks for SGFinDex, bank APIs, PayNow Gen2 and national payment governance were made against official or first-party material. Product scope, API eligibility, participant lists and implementation timelines can change, so production integrations should be checked against the relevant institution before development or launch.
- SGFinDex for current participating entities, consent rules, data handling and revocation information.
- GovTech SGFinDex service page for the April 2026 usage snapshot and public-service description.
- SGFinDex API specification for the published authorisation, retrieval and token flows.
- ABS FinTech industry material for the Finance-as-a-Service API PlayBook.
- DBS Developers, CONNECT2OCBC and UOB API Services for current examples of bank API functions.
- ABS PayNow and the MAS-ABS PayNow Generation 2 announcement for current PayNow functions and the 2026 enhancement study.
- Singapore Payments Network for SPaN’s role and current operationalisation status.
- ABS 2026 press releases for the July 2026 AI-driven cyber and technology risk taskforce announcement.
