Payments out of South Africa

Exchange Controls in South Africa

South Africa is not a "standard" market to integrate against. Unlike most corridors, money moving into and out of South Africa is subject to capital controls (also called exchange controls), and this shapes what your integration needs to handle differently for South African (ZAR) flows compared to any other currency on the platform.

This guide covers what you need to know before building against ZAR — why certain transfers are blocked, what documentation you'll need to collect from your customers, and how that differs for resident vs. non-resident use cases.

❗️
These rules aren't ours
These rules are set by South African regulation, not by Verto. They can't be configured, disabled, or bypassed on a per-client basis.

Why does South Africa work differently?

Most currencies on the Verto platform move freely — funds can go from one wallet to another, or out to any destination, without restriction. South Africa is an exception: local capital controls restrict why and how money can leave the country, and a South African bank has to enforce those restrictions on every relevant transaction.

To support this, ZAR flows are processed through, our local South African license, rather than through Verto's standard rest-of-world payment rails.

Onshore vs. offshore ZAR — two different wallets

Because of exchange controls, ZAR held on the platform is not a single, uniform balance — it exists as two distinct wallet types with different regulatory treatment:

Wallet type	Where it sits	Regulatory status
Onshore ZAR	Under Verto's South African license	Inside South Africa — subject to exchange controls
Offshore ZAR	Issued by Verto's UK entity, safeguarded in the UK	Treated as already outside South Africa

Both are ZAR, but which wallet your integration is using determines which rules apply.

📘
Why offshore ZAR exists
Offshore ZAR exists because ZAR — unlike most other African currencies — also trades at volume outside South Africa, so there's genuine demand for holding it offshore. Most other currencies on the platform don't need this split, since there's no regulatory reason to separate an onshore and offshore version.

Wallet-to-wallet transfers out of an onshore (Investec) wallet are blocked

If your integration tries to move funds from an onshore ZAR (Investec) wallet to any other wallet — including an offshore ZAR wallet or a wallet in another currency — expect this to be blocked.

🚧
This is not a bug
This is enforced by design, not a temporary limitation. From a South African regulatory standpoint, moving money from an onshore Investec wallet to any other wallet is equivalent to moving funds offshore into 1st party named account for that client — one of the most heavily regulated actions under exchange control rules.

What you can do instead, from an onshore Investec wallet:

A bank payout — an FX conversion and the external payment happen together, as a single linked action. These two steps can't currently be decoupled (Investec performs both the compliance check and the settlement as one package). You use our exchange endpoint + specify an external beneficy.
Pay back out to another South African bank account — funds can be returned to any account within South Africa. You use our Wallet payout endpoint, but only to send funds to a South African bank.

There is no path from an onshore Investec wallet to any other wallet on the platform. Build your flows around this constraint rather than around a wallet-to-wallet transfer.

All outbound South African payments are screened

Every payment leaving South Africa is checked before it's released. This applies to every transaction, regardless of size or client type, and isn't something that can be skipped or sampled.

📘
Design for this upfront
Your integration should expect this screening step to be part of the payout flow for any onshore ZAR transaction, and should be built to collect the right supporting information upfront (see below) rather than after a payment has already been submitted.

Inbound is a different story: because South African controls are focused on money leaving the country, not arriving, inbound payments into South Africa are currently handled entirely offshore by Verto's UK entity — originating inbound payments (in both ZAR and USD) via SWIFT, the recipient bank will do light touch capital controls - but they're often not required with recipiepts just specifying the purpose with the payment released.

Screening differs for residents vs. non-residents

The screening requirement itself doesn't change, but where in the flow it happens, and what you need to collect, depends on whether your client is a South African resident or a non-resident. This is the single most important distinction to design for.

Resident clients

For a South African resident, the regulatory trigger point is the moment they convert FX to send money abroad. Screening happens at FX conversion + payout, and your client will need to:

Select a Balance of Payments (BOP) category — this identifies the purpose of the payment.
Provide a supporting document for that category (an invoice, contract, or agreement, for example).

📘
SARB approval may apply
Depending on the BOP category (for example, inter-company payments, loans, or foreign direct investment), a formal South African Reserve Bank (SARB) approval may also be required. This is submitted by Investec on the client's behalf, and typically takes 4–6 weeks to turn around.

Non-resident clients

For a non-resident, the logic is different: because the client isn't a South African resident, funds collected into a South African account are already treated as "leaving South Africa" the moment they're collected (having been sent by a resident) —

Screening happens at the point of collection, earlier in the flow than for residents.
A manual Source of Funds check is required for 100% of payments — there's no threshold or sampling.
The Source of Funds request is sent to the client directly via email.

🚧
Don't assume parity with other markets
Your integration should not assume non-resident collections behave like collections in any other market — every single inbound payment will trigger this check, and it happens before conversion rather than at payout.

Quick reference

	Resident	Non-resident
Screening point	FX conversion + payout	Collection
What's required	BOP category + supporting document	Manual Source of Funds check
Coverage	Per transaction, per BOP rules	100% of payments
How it's requested	As part of the FX/payout step	Sent to the client by email
Possible additional step	SARB approval (4–6 weeks), depending on BOP category	SARB approval (4–6 weeks), depending on BOP category

Summary

South Africa is governed by capital/exchange controls that don't apply anywhere else on the platform — these can't be relaxed or configured per client.
ZAR exists as two separate wallet types (onshore/Investec vs. offshore/UK), with different regulatory treatment.
Funds in an onshore Investec wallet can only leave via a bank payout or be returned to another South African account — they cannot move to any other wallet.
Every outbound South African payment is screened; there's no exception path.
What's collected, and when, depends on residency: BOP category and documents at FX/payout for residents; a mandatory Source of Funds check at collection for non-residents.