TCIB for fintechs: the 1 April 2027 CMA deadline and how to migrate payouts

SARB Directive No. 1 of 2025, gazetted in April 2025, requires settlement system participants to stop routing smaller CMA cross-border EFTs through SADC-RTGS by 31 March 2027, and to route them through TCIB from 1 April 2027^{[Government Gazette, checked 2026-11-05]}.

Three terms in that sentence decide whether it touches your product:

• CMA cross-border EFTs. The Common Monetary Area joins South Africa, Namibia, Lesotho and Eswatini, and the directive treats electronic funds transfers between CMA countries as cross-border EFTs^{[SARB, checked 2026-11-05]}. A salary paid from Johannesburg to an account in Windhoek is one.
• The limit. The directive covers an EFT not exceeding R5 million^{[SARB, checked 2026-11-04]}. Payments above that are outside its scope.
• Settlement system participants. The directive is addressed to those that route these payments through SADC-RTGS. A fintech that pays out through a bank account is not one; its bank is.

This page is about the practical side: what changes for a fintech whose payouts cross a CMA border, and how to move them without losing a payment. For the full map of regional rails, start with cross-border payments in Southern Africa. For how TCIB itself works, read TCIB explained for developers.

Not directly, and that is the trap. The directive is addressed to settlement system participants, and as the SARB Governor put it in October, "at the moment, anyone who wants to access the payment system has to go through a bank"^{[BIS: Kganyago, checked 2026-11-05]}. So when your bank moves its CMA payments to TCIB, your payouts move with them, whether or not your code is ready for what comes back.

You are affected if any payment from your platform leaves South Africa for Namibia, Lesotho or Eswatini. Typical cases:

• payroll and contractor platforms paying people who live across a CMA border;
• marketplaces paying sellers in Namibia, Lesotho or Eswatini;
• lenders disbursing loans and insurers paying claims into CMA bank accounts;
• South African businesses paying CMA suppliers from their own systems.

If you only collect money inside South Africa, the directive does not change your integration. If you pay out within South Africa as well as across a border, only the cross-border share moves.

Under the directive, smaller CMA cross-border EFTs move to TCIB^{[Government Gazette, checked 2026-11-05]}. Payments above the limit are outside the directive, and so are payments to SADC countries outside the CMA, such as Zimbabwe or Zambia.

There is one complication worth knowing about. The SARB Governor has described a step with a lower figure: "By late April, qualifying regional transactions of up to R100 000 should move from SADC-RTGS to TCIB."^{[BIS: Kganyago, checked 2026-11-04]} The two figures differ. The directive is the legal instrument, so plan for its full scope, and ask your bank which payments it will move first. Your design should handle a bank that moves smaller payments early and larger ones later.

The other CMA countries have their own instruments. Eswatini lists its own CMA Retail EFT Payment Directive^{[Central Bank of Eswatini, checked 2026-11-05]}, and Namibia has published PSDIR-9^{[Bank of Namibia, checked 2026-11-05]} and PSDIR-10^{[Bank of Namibia, checked 2026-11-05]} on these cross-border EFTs, and Namibia's matching directive uses N$5 million as its limit^{[Bank of Namibia, checked 2026-11-05]}. If you also receive money from those countries, the sending bank follows its own country's rule.

The rail change is your bank's project. The consequences in your code are yours. Before you plan anything, put these questions to your bank and keep the answers:

Last verified: 2026-11-04. Sources, checked 2026-11-04: SARB. Get the answers in writing and date them: banks may refine their plans as the deadline approaches.

The answers land in three places in your system:

• The request. New mandatory fields, a different file layout or a new API, and limits on the reference you pass. Validate every payout before submission so a rejection never reaches the bank.
• The response. New statuses, new return reasons and different timing. Every one needs a mapping into your own payout states, or payments will sit in limbo.
• The records. Fees, currency conversion and settlement reports may change shape. Your reconciliation has to match the new reports line by line from the first day.

If you would rather hand the migration to a team that does this work, Mctaba Labs payment integration maps your current payout flow, works with your bank on the new route and rebuilds the reconciliation around it.

Put an interface between your business logic and the bank. Each bank product, today's route and the TCIB route alike, becomes one implementation of it, and the choice between them becomes configuration. A minimal version in TypeScript:

// Business logic depends on this interface; each bank product implements it.
export type PayoutStatus = 'created' | 'submitted' | 'accepted' | 'settled' | 'returned' | 'failed';

export interface PayoutRequest {
  id: string; // your idempotency key, saved before any call
  destinationCountry: string; // ISO country code, e.g. 'NA'
  amountMinor: number; // amount in cents of the paying currency
  currency: string;
  beneficiary: { name: string; account: string; bankCode: string };
  reference: string;
}

export interface PayoutRail {
  name: string;
  submit(req: PayoutRequest): Promise<{ railReference: string; status: PayoutStatus }>;
  fetchStatus(railReference: string): Promise<PayoutStatus>;
}

const CMA = new Set(['NA', 'LS', 'SZ']);

// The limit and the rails come from configuration, so cutting over is a config change.
export function pickRail(
  req: PayoutRequest,
  rails: { cmaRoute: PayoutRail; defaultRoute: PayoutRail },
  cmaLimitMinor: number,
): PayoutRail {
  const isCma = CMA.has(req.destinationCountry);
  return isCma && req.amountMinor <= cmaLimitMinor ? rails.cmaRoute : rails.defaultRoute;
}

Three habits make the cut-over boring, which is the goal:

• Save before you send. The payout row, with its idempotency key, exists before any call to the bank, so a retry can never pay twice.
• Store the rail's reference. Every payout records which route carried it and the reference that route returned. Reconciliation and support both start there.
• Flag by corridor. Move Namibia first, then Lesotho, then Eswatini, or whatever order your bank offers, and keep the old route switchable until returns and timing look normal.

Work back from your bank's date, not the regulator's. Your bank has to finish by the directive's deadline, so your real deadline is the bank's own date, which can only be the same or earlier.

1. Inventory. List every payout path that crosses a CMA border: which corridor, which bank product, what amounts, how many a month, and which customers depend on them.
2. Get the bank's plan in writing. Use the questions above. Date the answers.
3. Add the payout interface before the bank changes anything, and route today's payments through it.
4. Map statuses and return reasons for the new route, and extend reconciliation to its reports.
5. Test with real, small payments as soon as the bank opens the route to you.
6. Cut over corridor by corridor behind a flag, watching returns, timing and support tickets.
7. Keep a path for large payments if your bank keeps them on the old route.
8. Update customer promises last. Change what you tell recipients about arrival times only once you have measured the new route.

Teams that start this in the final month risk testing in production. Teams that start now have time to find out what their bank has not decided yet.

The same logic applies in reverse, under your own regulator. Namibia and Eswatini have their own directives, cited above, so a Namibian or Swati fintech should read its central bank's instrument alongside its bank's plan. For Lesotho, ask your bank which instrument applies; we have not confirmed one at its source.

Country detail lives in the pillars for Namibia and for Eswatini and Lesotho.

The directive moves one slice of regional traffic: CMA cross-border EFTs up to its limit. Payments above the limit and payments to SADC countries outside the CMA are outside its scope, so those follow whatever route your bank uses today.

How regional settlement works, and why the CMA is treated differently, is covered in SADC-RTGS and the Common Monetary Area. The other pan-African system builders ask about is in PAPSS in Southern Africa, and the country-by-country picture is in payments in Southern Africa.

If your payouts cross a CMA border and you want the migration done before your bank's date rather than on it, Mctaba Labs payment integration takes on exactly this work.