The SARB's Payments Ecosystem Modernisation programme explained for builders

PEM is the SARB's programme for changing who may connect to South Africa's payment system and how people pay through it. It is not one project but a set of workstreams, each at a different stage. The Governor frames the wider goal as four building blocks of a better payment system: opening it to non-banks, deepening the use of PayShap, QR+ interoperability, and a single digital ID for payments^{[BIS: Kganyago, checked 2026-11-05]}.

The SARB's 2025/26 Annual Report lists what PEM has released so far: a draft regulatory framework for non-bank participation, the first QR+ standard and a draft Fraud Risk Framework^{[SARB Annual Report 2025/26, checked 2026-11-05]}. Two further SARB plans, a shared payments platform and a reusable digital credential, are earlier still; the section on what is further out covers them.

For where the SARB, PayInc and the banks sit, see how payments work in South Africa. The governance change running alongside PEM, the end of PASA's role, is covered in what happened to PASA.

Two problems, and the Governor named both. The first is access: "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 fintech with a better wallet or checkout still reaches customers' money through a bank.

The second is adoption. South Africa built a rapid payment rail, and card payments still outnumber it many times over. Last year PayShap processed only about 6% as many transactions as cards, and under 40% of EFT credit volumes^{[BIS: Kganyago, checked 2026-11-04]}. The Governor named four things holding it back: parity, pricing, promotion and the acceptance perimeter^{[BIS: Kganyago, checked 2026-11-05]}.

The acceptance perimeter is the one builders can move. Every checkout, invoice and till that accepts PayShap widens it, and QR+, which now supports PayShap, is the obvious way to widen it at the point of sale.

Read the building blocks with those two problems in mind and the programme hangs together. Non-bank access changes who can build. PayShap and QR+ change where people can pay. A digital ID changes how they prove who they are.

Drafts, a standard and a pilot date. Here is each workstream, where it stands and what to do about it.

Where each of the SARB's payment reforms stands

Workstream	Where it stands	What a builder should do now
Opening the system to non-banks	Draft directive for payment activities published in November 2025	Map your product to the draft's activity groups; the final text decides how you are licensed
QR+ standard	Version 1.2 introduces enhancements to support PayShap integration	Read the standard and check that your QR flows can start a payment on more than one rail
QR+ pilot	Pilot planned for the first quarter of 2027	Watch which banks and PSPs take part before you print new codes
Deepening PayShap	Held back by parity, pricing, promotion and the acceptance perimeter	Offer PayShap where your PSP supports it; every checkout that accepts it widens acceptance
Fraud	Draft Fraud Risk Framework released	Read the draft for duties that touch your product, and keep the fraud data you would need to report
Digital ID for payments	PEMKey programme building the Payment Credential Ecosystem	Nothing to integrate yet; keep identity checks behind your own interface
Shared payments platform	H-UPP business case being developed	No action; do not design around it

Last verified: 2026-11-04. Sources, checked 2026-11-04 to 2026-11-05: SARB Annual Report 2025/26, SARB, BIS: Kganyago, SARB. Status as the SARB and the Governor describe it; the third column is our advice, not the SARB's.

Notice what is missing: no new rail and no new API you can call today. Everything on the list is either a draft rule, a standard that providers will implement, or a plan. That shapes how you should respond: change your roadmap now, and your code when providers ship.

If you want the product side handled while you track the rules, Mctaba Labs payment integration builds integrations on the rails that exist today.

Three of them, depending on what you build.

If you want your own licence, the non-bank workstream is the one that matters. The SARB published the draft directive for payment activities in November 2025^{[SARB Annual Report 2025/26, checked 2026-11-05]}, and the final version decides which payment activities a non-bank may perform in its own right. The SARB non-bank Authorisation Framework covers the activity groups, the draft capital figures and the timing.

If you take payments in person or on invoices, QR+ is the one to watch. Version 1.2 of the standard adds enhancements to support PayShap integration^{[SARB, checked 2026-11-05]}, and the pilot is planned for the first quarter of 2027^{[BIS: Kganyago, checked 2026-11-04]}. QR+ in South Africa explains what the standard does and how to prepare.

If you run a PSP or sell in a high-fraud category, read the fraud workstream. The SARB has released a draft Fraud Risk Framework^{[SARB Annual Report 2025/26, checked 2026-11-05]}. What the draft means for merchants and PSPs goes through it, and 3D Secure 2, chargebacks and fraud covers the card rules you already live with.

The PayShap workstream touches almost everyone who collects money, but it changes your roadmap more than your code. PayShap already exists; the question is whether your checkout offers it. Start with what PayShap is and how it works.

Two of the SARB's plans are further out, and neither deserves engineering time yet.

The first is a shared platform for moving money. H-UPP is the SARB's proposed Hybrid Unified Payments Platform, which aims to integrate multiple payment systems through shared core services; a business case is being developed to assess its feasibility^{[SARB Annual Report 2025/26, checked 2026-11-05]}. If it goes ahead, the system that settles between banks and the one that carries everyday fast payments would become one platform. For a builder, a business case is a long way from an API, and it can end in a no. Today's settlement system is explained in SAMOS, RTGS and settlement.

The second is identity. The SARB's PEMKey programme is establishing the Payment Credential Ecosystem, which will enable secure, reusable digital credentials for use across the payments ecosystem^{[SARB, checked 2026-11-05]}. Read it alongside the Governor's fourth building block, a single digital ID for payments. A reusable credential would let a customer prove who they are once and use that proof again. For anyone who runs onboarding, that is the part to watch.

The engineering response to both is the same. Keep your settlement and identity dependencies behind your own interfaces, so a future platform or credential becomes an adapter, not a rewrite.

Build as if the rails underneath you will change. Three habits make that cheap.

Separate how a payment starts from how it moves. QR+ is built on this split: it is a standard for starting a payment from a QR code, barcode or digital link^{[SARB, checked 2026-11-05]}, and it passes the initiation data to the selected payment rail, which processes the transaction^{[SARB, checked 2026-11-05]}. Your code should make the same split. Model the payment intent (who pays whom, how much, for what) separately from the rail that carries it (card, EFT, PayShap), and adding a rail stops touching checkout logic.

Give every rail the same status machine. Pending, authorised, settled, failed and reversed mean slightly different things on each rail, but your order system should not care. Translate each provider's webhooks into your own states, store the raw payloads, and reconcile against settlement reports every day.

Keep identity and fraud checks behind interfaces. Today you might call a bank account verification service and your PSP's fraud tools. Later there may be a reusable credential and new fraud duties. If KYC and risk scoring sit behind your own service boundary, swapping what is behind it is a contained job.

For the rail choices you make today, EFT, RTC, RTGS or PayShap compares the options, and ISO 20022 in South Africa covers what developers need to change in their messaging.

Cards and EFT still dwarf PayShap, as the Governor's own comparison above shows, and nothing PEM has released changes that this year. The practical verdict for a builder in South Africa:

• Online checkout: keep cards as the default and add pay-by-bank or PayShap where your PSP supports it. That is the direction the SARB is pushing.
• In person and on invoices: plan for QR+, but keep the QR and card methods your customers use today until the pilot shows which banks and apps support it.
• Products that hold or move other people's money: plan your licence around the Authorisation Framework, not the registration model it replaces.
• Everything else: PEM is background. Track the dates, keep your architecture flexible, and revisit when a draft becomes final.

For how South Africa's rails connect to the rest of the region, see payments in Southern Africa. When you want the build done on today's rails without boxing in tomorrow's, Mctaba Labs payment integration works on exactly these South African systems.