Bank & Open-Finance APIs in South Africa: FNB, Capitec & the Aggregator Route

Yes and no. South Africa has no open-banking mandate, so most major banks do not offer a public API for reading account transactions. Nedbank runs a developer API Marketplace, FNB and Standard Bank expose partner integrations, and Capitec and Absa have no public transaction API. Aggregators fill the gap with consent-based access.

If you have searched "fnb api", "capitec bank api" or "bank account linking api" and come away confused, that is the reason: the landscape does not match what "bank API" means in the UK, the EU or the US. This guide explains what a South African bank API actually is in 2026, what each major bank publishes, and the practical route developers use to get transaction data across banks.

Is there a public bank API in South Africa?

There is no single, standardised bank API in South Africa the way there is in open-banking markets. In the UK, regulation forced the nine largest banks to expose consent-based account APIs by 2018; the EU's PSD2 did the same across the bloc from 2019. South Africa has no equivalent law, so bank API access is uneven, mostly gated, and rarely covers transaction history for arbitrary account holders.

What you can get today falls into three buckets:

• A registered developer API — Nedbank is the only major bank with a self-registration developer portal.
• Partner or enterprise integration — FNB, Standard Bank and Absa integrate with vetted partners and corporate clients under contract, not through a public sign-up.
• Nothing public — Capitec has no developer-facing API for account data at all.

For a fuller picture of where regulation is heading, see open banking in South Africa.

Why South Africa has no open-banking API mandate

Open banking elsewhere exists because a regulator required it. South Africa's regulators have signalled intent but have not mandated anything.

• The South African Reserve Bank (SARB) has run open-finance consultations since 2020 through its Payments Ecosystem Modernisation work, and favours studying the market before prescribing a framework.
• The Financial Sector Conduct Authority (FSCA) has published a consultation on open finance and said a regulated data-sharing regime is likely, without committing to a date.
• The Conduct of Financial Institutions (COFI) Bill is expected to provide the legal basis for customer-data-sharing rules once enacted. Draft regulations circulated in 2025; implementation is phased and not yet in force.

The practical takeaway for 2026: the direction is toward regulated open banking, but there is no mandated bank API, no compliance deadline, and no standard schema. Banks that offer API access do so on their own terms, in their own formats.

What each major South African bank offers today

FNB API

FNB has the most visible developer presence of the retail banks. It has published an API marketplace and offers connectivity for business and enterprise clients — payment initiation, account verification, and statement or balance feeds — but access runs through an application and a corporate banking relationship, not a self-serve key. FNB also feeds transaction data into some accounting platforms (for example a direct Sage bank feed). There is no publicly documented, self-service API that returns transaction history for any FNB account on demand, which is what most "fnb api documentation" and "fnb business api" searches are actually looking for.

Capitec bank API

Capitec has no public developer API for account or transaction data as of 2026. It has the largest retail customer base in the country, which makes this a common blocker: if your product needs to work with Capitec account holders, direct API access is not an option and you will need consent-based access through an aggregator.

Standard Bank API

Standard Bank offers API integrations to selected partners and corporate clients rather than through open registration. It has run open-banking pilots and operates across 20 African markets, so its eventual strategy is likely to be pan-African. Today, treat it as partner integrations only — no self-serve public transaction API.

Nedbank API

Nedbank runs an API Marketplace with OAuth 2.0 and a developer registration flow — the closest thing to a UK-style open-banking experience among South Africa's big banks. It exposes account and payment endpoints for approved developers. Coverage and adoption are narrower than a full open-banking implementation, and it only covers Nedbank accounts, but it is a real, documented API you can register for.

Absa API

Absa provides eStatements and integrates with partners, and has publicly signalled interest in open banking. It does not currently publish a self-serve developer API for account transaction data. Partner integrations only.

The net result: no single API covers all five major banks, and none of them offer self-serve transaction access for small teams. A product that needs to work across South African banks cannot be built on official bank APIs alone.

The aggregator route: one API across banks

The practical path most developers take is a bank data aggregator (also called an intermediary or open-finance provider). Instead of integrating with each bank, you integrate once with the aggregator, and it handles connectivity to the underlying banks.

The model works like this:

1. The account holder gives explicit consent and links their bank account through the aggregator.
2. The aggregator retrieves transactions, balances and account metadata on a schedule or on demand.
3. Your software receives structured data through one API, webhook or feed — regardless of which bank the account is at.

This is the same pattern Plaid and TrueLayer popularised in other markets. In South Africa, because banks mostly do not expose consent APIs, aggregators typically use secure credential-based access rather than bank-hosted OAuth — which brings us to the screen-scraping question.

Screen scraping vs API access

API access means the bank exposes an endpoint, the customer authorises through the bank's own login, and the third party receives a token. Credentials never leave the bank. This is clean but, in South Africa, only broadly available for Nedbank.

Credential-based access (often loosely called "screen scraping") means the customer provides their internet-banking credentials to a trusted intermediary, which signs in on their behalf and extracts structured transaction data. Modern implementations use headless-browser automation and structured parsing rather than scraping raw HTML, but the trust model is different: the customer is sharing credentials with a third party.

A well-built credential-based system should:

• Encrypt credentials at rest (AES-256-GCM or equivalent) in an isolated store, separate from the application database.
• Decrypt only in an ephemeral session at the moment of use.
• Obtain and record explicit account-holder consent, in line with POPIA.
• Never expose credentials to your systems or the end user's.

The trade-off: credential-based access depends on the bank's portal staying stable, and a login-flow change can interrupt data until the connector is updated. In the absence of official APIs, it is the only method that provides automated, recurring transaction access across most South African banks today. The guide to connecting a South African bank account compares every route in more detail.

How Banklink connects South African bank accounts

Banklink is a bank data intermediary built for the South African market. You integrate once; Banklink handles the bank connectivity layer.

1. Link an account — the account holder authorises the connection through Banklink's secure interface. Credentials are encrypted with AES-256-GCM and never stored in plaintext.
2. Create a Pulse — a scheduled job that pulls transactions on your chosen interval (hourly, daily, weekly) or on demand.
3. Receive the data — each Pulse delivers to one or more destinations: an HTTP POST to your webhook in structured JSON, an emailed digest, or the Banklink dashboard.

The data arrives in a consistent shape no matter which bank it came from, so you write business logic instead of browser automation. Banklink currently supports FNB, with more banks being added. See the API reference for the endpoint and payload shape, and the documentation for how Pulses and destinations are configured. For a worked example of reading balances from the transaction feed, see checking bank account balances programmatically.

Choosing an approach

When SARB and the FSCA do mandate open banking, aggregators will move from credential-based access to bank-hosted APIs where they exist, without their customers needing to change anything. The account linking you build today becomes the same pipe formal open-banking data flows through later.