The SARB non-bank Authorisation Framework: what changes for fintechs

It is a directive from the SARB that lists payment activities and sets the conditions a provider must meet to perform each one. The SARB authorises the activity rather than the type of institution, so a wallet, a pay-by-bank app and a collection platform each apply for what they actually do. In October the Governor said that at the moment, anyone who wants to access the payment system has to go through a bank^{[BIS: Kganyago, checked 2026-11-05]}.

Two drafts are public. The SARB published the draft directive for payment activities in November 2025^{[SARB Annual Report 2025/26, checked 2026-11-05]}, and a May 2026 draft^{[SARB, checked 2026-11-05]} carries the activity groups and capital figures this page works from. Neither is final. The timing section below has the publication target, and this page will be updated when the final text is out.

If you are new to the institutions involved, read how payments work in South Africa first. It shows where the SARB, PayInc and the banks sit, which makes the rest of this page easier to follow.

Because the system was built around banks. In the Governor's words, "at the moment, anyone who wants to access the payment system has to go through a bank"^{[BIS: Kganyago, checked 2026-11-05]}. In practice a bank sits behind every fintech product, holding the money and connecting it to clearing and settlement.

There is a banking law problem too. Holding money for customers can look like taking deposits, and taking deposits is the business of a bank. On 20 May 2026 the Prudential Authority said, in Prudential Communication 10 of 2026^{[SARB Prudential Authority, checked 2026-11-05]}, that it intends to issue an Exemption Notice taking specified payment activities out of the definition of the business of a bank^{[Prudential Authority, checked 2026-11-05]}.

The two instruments work as a pair. The exemption stops listed payment activities counting as banking. The SARB's directive then decides who may perform them, with how much capital and under what conditions. Put simply, the exemption answers "is this banking?" and the directive answers "who may do it, and on what terms?"

The May 2026 draft sorts payment activities into seven groups^{[SARB, checked 2026-11-05]}. Find the group that matches what your product does with other people's money; that decides which authorisation you apply for and what capital you hold.

Activity groups in the SARB's draft Authorisation Framework

Activity group in the draft	The businesses it is likely to catch (our reading)
Issuing e-money and payment instruments	Wallets and apps that hold a balance for the customer; prepaid and card-issuing programmes
Acquiring	Signing up merchants and accepting payments on their behalf, the core of a payment facilitator or gateway
Payment execution: clearing, settlement and payment initiation	Pay-by-bank providers that start a payment from the customer's own account, and processors that clear and settle between providers
Payments to third persons (TPPPs)	Platforms that collect from payers for merchants or sellers: marketplaces, billing platforms and collection services
Schemes	Operators that write the rules for a payment network that other providers join
Money remittance	Sending money for customers to recipients, at home or across borders
Payment account	Providers of the accounts that payments are made from, such as deposit and credit accounts

Last verified: 2026-11-05. Sources, checked 2026-11-05: SARB. The group names come from the draft. The second column is our reading of which businesses each group catches, not the SARB's wording.

Most fintechs touch more than one group. A marketplace that holds seller balances and pays them out may be collecting for third persons and issuing e-money at the same time. A checkout that both starts bank payments and signs up merchants may touch payment initiation and acquiring. Map every money movement in your product, including refunds, payouts and balances left sitting overnight, not just the headline feature.

If you would rather hand the build that follows to someone else, Mctaba Labs payment integration builds the payment integrations that sit on top of whichever group you land in.

Two of the draft's capital figures matter most to early-stage fintechs. Treat both as draft numbers until the final text confirms them.

• Payment initiation: R2 million minimum capital in the May 2026 draft^{[SARB, checked 2026-11-05]}.
• E-money issuing: Tier 1 e-money issuance needs R8 million initial capital and Tier 2 needs R5 million^{[SARB, checked 2026-11-05]}.

The e-money test is worth reading twice. The tier is not set by revenue or customer numbers. It is set by the money customers hold with you, averaged month by month over a run of six consecutive months. A wallet that grows quickly can cross into the higher tier while its revenue is still small.

Two engineering consequences follow. First, your ledger has to report total customer balances at every month end so you can compute the average the test uses; build that report before launch, not when someone asks for it. Second, put an alert on the trend. If the running six-month average is heading for the tier line, you want to know a quarter before you cross it.

If the capital is out of reach, the realistic route is to keep operating under an authorised partner, a bank or a licensed provider, and to design your stack so you can move across later.

They keep operating for now. Third-party payment provider registrations granted before PASA's recognition was withdrawn stay valid until the SARB publishes the Authorisation Framework directive^{[SARB, checked 2026-11-04]}.

Read that sentence carefully: the protection runs until publication, not for a set period after it. The final directive is where the transition rules for existing registrations should appear, so they are the first thing to read when it is out.

In the draft's own terms, a TPPP is one of the groups: payments to third persons, which the draft labels TPPPs^{[SARB, checked 2026-11-05]}. Most registered TPPPs will be mapping themselves onto that group, and some will find that a wallet balance or a payout feature pulls them into a second one. If you are not sure the TPPP label fits you at all, what a TPPP is covers the test, and what happened to PASA explains why registrations now sit with the SARB.

The SARB intends to publish the Authorisation Framework by the end of November 2026^{[BIS: Kganyago, checked 2026-11-05]}. That target comes from the Governor's October speech. It is an intention, not a gazetted deadline.

When the final text appears, four things decide whether your plans still hold:

1. The activity groups. Whether any group was split, merged or renamed, and whether your product still maps to the same one.
2. The capital figures. Whether the payment initiation and e-money numbers above survived.
3. The transition. How long registered TPPPs have to apply, and whether any activity is phased in later.
4. The application route. What the SARB wants to see in an application and how long a decision takes.

The rest of this page, the reasons for the framework and the way to map your product onto it, should hold either way. When the directive is published, this section, the capital figures and the FAQs are the parts that change, and the Last verified date on this page tells you whether that update has happened.

Do the work that pays off whatever the final text says.

• You hold a TPPP registration. Keep your details current with the SARB, and write down which draft group each of your money flows falls into. When the final text lands you will be comparing, not starting from zero.
• You are building a wallet. Start recording month-end customer balances now and model both capital tiers. Decide early whether you launch under a bank's licence or wait to apply in your own name.
• You are building pay-by-bank or payment initiation. Budget for the draft capital figure, and keep consent and authentication logs in a form an inspector could read.
• You run a marketplace or platform. Check whether you collect money for sellers. If you do, you are in TPPP territory. The alternative is to let an authorised PSP collect and split payments for you, which keeps the activity on its licence.
• You sell your own goods and services. On our reading, the draft groups describe payment services provided to others, and selling your own products through a PSP is not one of them. The framework reaches you through your PSP's contract, so ask your PSP how it is preparing.

The full route from registration to authorisation is in how to become a non-bank payment provider. For wallets, mobile money under the e-money tier asks whether the new rules change the economics. For customer due diligence and data protection, see FICA, KYC and POPIA for payment products.

Less than you might fear on day one, more over time. An authorised provider still moves money over the same rails: an EFT, a debit order or a card payment works the same way whoever holds the licence. What changes is who carries the obligations, and that shows up in three places in a codebase.

• The ledger. Customer money and your own money need separate accounts in your books, reconciled daily against the bank accounts that hold them. For a wallet, the e-money tier test makes this impossible to skip.
• The provider layer. Today you probably call a PSP or a bank's API. After authorisation you may connect differently, or to more than one partner. Put each rail behind your own interface now, so a change of partner is a configuration change and not a rewrite.
• The evidence trail. An authorised provider can be asked how a payment was initiated, who consented and when. Record consent, authentication results and status changes as append-only events, keyed to your own payment IDs.

The framework is one part of the SARB's wider Payments Ecosystem Modernisation programme. Whether a new payments law is also on the way is covered in where the NPS Act review stands. For licensing in neighbouring countries, see payments in Southern Africa.

When you are ready to build on the rails your authorisation covers, Mctaba Labs payment integration works on exactly these South African systems.