Open banking is reshaping how businesses and consumers interact with financial data across the world. In the United Kingdom, it is law. In the European Union, it is a regulated right. In Australia, it is expanding beyond banking into energy and telecoms. In South Africa, the picture is different — formal regulation is still taking shape, but real implementations already exist and businesses are using them today.
This guide explains what open banking is, where South Africa stands in the global picture, how the technology works, and what it means in practice for developers, finance teams, and business owners operating in the South African market.
What is open banking?
At its core, open banking is a simple concept: a bank account holder gives permission for a third party to access their financial data. Instead of downloading a CSV from internet banking and emailing it to an accountant, the data flows directly — structured, machine-readable, and on a schedule the account holder controls.
The idea originated in the United Kingdom. The Competition and Markets Authority (CMA) mandated in 2016 that the nine largest UK banks must build standardised APIs allowing licensed third parties to access account data with customer consent. The European Union followed with PSD2 (the Second Payment Services Directive), which came into force in 2019 and extended similar requirements across all EU member states.
These regulations established three foundational principles:
- Customer consent — No data moves without the account holder's explicit permission. The customer decides which third party can see what, and can revoke access at any time.
- Standardised APIs — Banks must expose account data through well-documented, machine-readable interfaces. No more screen scraping, no more manual downloads.
- Licensed intermediaries — Third parties accessing bank data must be regulated. In the UK, this means FCA authorisation as an Account Information Service Provider (AISP) or Payment Initiation Service Provider (PISP).
The result in markets where open banking is mature: a business can connect its bank account to accounting software, a lending platform, or a cash flow dashboard in minutes. The data arrives structured and current. No manual steps, no emailed PDFs, no stale information.
The South African context
South Africa does not yet have a formal open banking mandate equivalent to PSD2. But the regulatory machinery is in motion, and the gap between "no regulation" and "things are happening" is important to understand.
The South African Reserve Bank (SARB) has been actively exploring open finance since at least 2020. SARB's Fintech Unit, housed within the Financial Surveillance and National Payment System departments, has published multiple discussion papers on the topic. Their position has been consultative rather than prescriptive — studying what has worked in other markets before committing to a framework.
The Payments Association of South Africa (PASA) plays a regulatory role in the payments ecosystem and has been involved in drafting standards for how third-party access to payment data might work. PASA's work feeds into the broader regulatory process but does not itself create binding obligations on banks.
The Conduct of Financial Institutions (CoFI) Bill is the most significant piece of legislation in the pipeline. CoFI is designed to consolidate and modernise the regulation of how financial institutions treat customers — including how customer data is shared with third parties. Draft regulations were published for consultation in 2025, with formal implementation expected in phases. While CoFI is broader than open banking, it provides the legal scaffolding on which data-sharing rules will be built.
The regulatory sandbox operated by the Intergovernmental Fintech Working Group (IFWG) has allowed several fintech companies to test open banking-adjacent services under controlled conditions. This has given SARB real-world evidence of how data-sharing models perform in the South African context.
The practical reality in 2026: South Africa is somewhere between "interested" and "committed." The intent to enable open banking is clear. The timeline for mandated bank APIs is not. Businesses that need bank data today cannot wait for regulation to catch up.
How open banking works technically
Open banking implementations fall into two broad categories, and understanding the difference matters for anyone evaluating solutions in South Africa.
API-based access
In mature open banking markets, banks expose RESTful APIs that follow a published standard (such as the UK's Open Banking Standard or the Berlin Group's NextGenPSD2). A third-party application authenticates using OAuth 2.0, the customer authorises access through their bank's own interface, and the third party receives a token that allows it to retrieve account data.
The flow looks like this:
- The customer initiates a connection in the third-party application.
- The application redirects the customer to their bank's authorisation page.
- The customer logs in and explicitly consents to data sharing.
- The bank issues an access token to the third party.
- The third party uses the token to call the bank's API and retrieve data.
This is clean, standardised, and secure. The third party never sees the customer's banking credentials. The bank controls the authorisation flow. The customer can revoke access at any time through their bank's settings.
In South Africa, this model is largely aspirational. Nedbank has an API Marketplace with OAuth 2.0 support, and FNB offers an Integration Channel for corporate clients. But neither provides the kind of self-serve, broadly accessible API access that exists in the UK. Access requires enterprise relationships, formal applications, and in many cases, months of onboarding.
Credential-based access and screen scraping
In markets where banks have not built open APIs — which includes most of South Africa — third parties use an alternative approach: the customer provides their internet banking credentials to a trusted intermediary, which then logs into the banking portal on their behalf and retrieves data.
This is sometimes called "screen scraping," though modern implementations are more sophisticated than that term implies. Rather than parsing raw HTML, services like BankLink use headless browser automation to navigate the bank's authenticated portal, extract structured transaction data, and deliver it in a clean format.
The credential handling in a well-built system works like this:
- Credentials are encrypted at rest using AES-256-GCM or equivalent.
- They are stored in an isolated vault, separate from the application database.
- They are decrypted only at the moment of use, in an ephemeral session.
- The third party never exposes credentials to the end user's own systems.
This approach has real trade-offs. It depends on the bank's web portal remaining stable — a UI change can break the data pipeline until the scraping logic is updated. It also requires the customer to share credentials with a third party, which demands a high level of trust. But in the absence of official APIs, it is the only method that provides automated, recurring access to bank transaction data in South Africa today.
If you are evaluating how to connect a South African bank account to your software, understanding this distinction between API-based and credential-based access is essential.
What data is available
Open banking — whether via API or alternative methods — typically exposes the following categories of data:
Transaction history — Individual debits and credits with dates, descriptions, amounts, and running balances. This is the most commonly used data type. Transaction descriptions in South African banking typically include the merchant name, reference number, and sometimes the branch or channel.
Account balances — Current balance, available balance, and in some cases the overdraft limit. For businesses managing cash flow, automated balance checks across multiple accounts eliminate the need to log into each banking portal individually.
Account metadata — Account number, account type (cheque, savings, credit), branch code, and account holder name. This is useful for verification purposes — confirming that an account exists and belongs to the person claiming it.
What is not typically available: Internal bank scoring data, credit bureau information, pending transactions before clearing, and inter-account transfers that have not yet settled. Banks also do not expose data about other customers' accounts — the consent model is strictly per-account.
In practice, the most valuable data for South African businesses is transaction history. It feeds reconciliation, cash flow analysis, lending decisions, and compliance workflows. A single structured transaction feed replaces hours of manual statement collection.
Use cases in South Africa
Open banking is not abstract. It solves specific, expensive problems that South African businesses deal with every day.
Accounting and reconciliation
The dominant pain point. Accounting firms managing dozens or hundreds of clients spend enormous amounts of time collecting bank statements, converting them from PDF or CSV into their accounting system's format, and then reconciling against invoices. Automated bank data feeds cut this from a multi-step, multi-day process to something that happens in the background. Transactions arrive structured, categorised, and ready for matching.
Lending and credit decisions
Lenders — from traditional banks to micro-lenders to buy-now-pay-later platforms — need to assess affordability. The traditional approach involves requesting three months of bank statements, waiting for the applicant to provide them, and then manually reviewing the documents. With open banking, a lender can access a consented view of an applicant's transaction history in real time. Income verification, expense patterns, gambling activity, existing debt repayments — all visible directly from the source data.
Personal finance management
Consumer-facing apps that aggregate a user's accounts across multiple banks into a single dashboard. In South Africa, where it is common to hold accounts at two or three banks (a primary cheque account at FNB, a savings account at Capitec, a credit card at Nedbank), a unified view is genuinely useful. Understanding where money goes each month requires seeing all accounts together.
Payroll verification
Employers and HR platforms can verify salary deposits directly from bank data, rather than relying on payslips that can be forged. A consented view of three months of credits to an account, filtered for salary-like transactions, provides hard evidence of employment and income level.
Payment reconciliation for e-commerce
South African e-commerce businesses that accept EFT payments (which remains common, particularly for B2B transactions) need to match incoming bank credits against outstanding orders. Manual reconciliation — downloading a statement, scanning for references — does not scale. Automated transaction feeds matched against order references solve this.
Regulatory compliance
Know Your Customer (KYC) and anti-money laundering (AML) processes benefit from direct access to bank data. Confirming that bank details are valid, that the account holder matches the expected identity, and that transaction patterns are consistent with the stated business purpose — all of this is faster and more reliable with structured data than with manually submitted documents.
The current landscape: South Africa's big five banks
Each of South Africa's major banks has a different posture toward third-party data access.
FNB is the most advanced in terms of third-party integrations. Their Integration Channel provides APIs for payments and account data, and they offer a direct bank feed into Sage Business Cloud. However, access is gated behind a corporate banking relationship and a formal application process. There is no self-serve developer portal.
Nedbank operates an API Marketplace that uses OAuth 2.0 and provides access to account information and payment initiation for registered developers. Of the big five, Nedbank's developer experience is closest to what open banking looks like in the UK — but adoption is limited and the range of available endpoints is narrower than a full open banking implementation.
Standard Bank has run limited open banking pilots and has publicly stated its interest in the space. Their API offerings are available to selected partners rather than the general developer community. Standard Bank's scale across Africa (they operate in 20 countries) means their eventual open banking strategy will likely extend beyond South Africa.
ABSA provides eStatements and has signalled interest in open banking, but does not currently offer a public developer API for account data access. Their existing digital banking tools are strong on the consumer side but limited for third-party integration.
Capitec has the largest customer base by account numbers in South Africa but does not offer any developer-facing API. Capitec's focus has historically been on simplifying consumer banking rather than enabling third-party data access. For businesses that need to access Capitec account data — which is common given the bank's market share — alternative methods are the only option.
The net result: if you are building a product that needs to work across all South African banks, you cannot rely on official APIs alone. No single API covers all five major banks, and none of the existing APIs are truly self-serve for small and mid-sized businesses.
Challenges and limitations
Open banking in South Africa faces real obstacles, and understanding them is important for anyone building or buying in this space.
No mandated API standard. Unlike the UK, where the Open Banking Implementation Entity (OBIE) defined a single technical standard that all banks must follow, South Africa has no equivalent. Each bank that does offer an API uses its own format, authentication flow, and data schema. This fragmentation means that a developer integrating with multiple banks must build and maintain separate integrations for each.
Bank resistance. Banks have limited commercial incentive to make customer data freely available to third parties. Data is a competitive asset. While regulation will eventually force the issue — as it did in the UK — the voluntary adoption pace is slow.
Screen scraping fragility. Credential-based access depends on banks' web portals remaining stable. When a bank redesigns its internet banking interface, screen scraping breaks until the scraping service updates its logic. This creates maintenance overhead and occasional service interruptions that pure API access would avoid.
Credential handling concerns. Sharing banking credentials with a third party requires trust. Even with strong encryption and isolated storage, some customers and compliance teams are uncomfortable with the model. API-based open banking, where the bank mediates the authorisation flow and the third party never sees credentials, is inherently cleaner from a trust perspective.
Data freshness. In API-based open banking, data can be near-real-time. With credential-based access, data is typically fetched on a schedule (hourly, daily, or on-demand) rather than streamed continuously. For most use cases this is sufficient, but it means there is always some latency between a transaction occurring and appearing in the third party's system.
Limited scope. Current implementations — both API and credential-based — focus on read access to account data. Payment initiation (instructing a bank to make a payment on behalf of a customer) is a separate, more complex capability that is even less developed in South Africa than data access.
Where it is heading
The trajectory is clear, even if the timeline is not.
SARB's Fintech Unit continues to develop the regulatory framework. The signals from published discussion papers and industry engagements indicate that South Africa will move toward a regulated open banking model — the question is when, not if.
The CoFI Bill will provide the legal basis for data-sharing obligations. Once enacted and regulations are gazetted, banks will have a defined timeline to comply. Industry participants expect the first binding requirements to take effect in 2027 or 2028, though this depends on the legislative process.
The IFWG regulatory sandbox continues to accept fintech applicants testing open banking services. The insights from these tests feed directly into SARB's policy development.
Industry convergence is happening independently of regulation. As more businesses demand automated bank data access, and as intermediaries demonstrate that it can be done safely and reliably, the commercial pressure on banks to cooperate increases. Some banks may choose to open up voluntarily before regulation forces them to, recognising that partnering with fintechs is more productive than resisting them.
The South African model is unlikely to be a direct copy of PSD2. The regulatory approach will reflect local market conditions — the dominance of a small number of large banks, the high mobile banking adoption rate, the importance of financial inclusion, and the existing payments infrastructure managed by PASA and BankServAfrica. Expect a framework that is informed by international precedent but tailored to South African realities.
For businesses that need bank data today, the practical advice is straightforward: do not wait for regulation. Solutions exist now. Services like BankLink provide automated, encrypted, consented access to transaction data across South African banks — delivering the core benefit of open banking without requiring that the regulatory framework be complete. As regulation matures, these services will transition from credential-based access to API-based access where available, without requiring their customers to change anything.
Open banking in South Africa is not a future concept. It is a present reality operating ahead of its regulatory framework — and the businesses adopting it today are the ones building their data infrastructure on solid ground.