On 26 October 2026, Paymentology announced an expanded partnership with Mukuru around a new South African proposition: Mukuru Account & Card. The product combines a transactional account, a Mastercard debit card, domestic EFT payments and the international remittance services already offered by Mukuru.
It could be described as another card launch. The official product and legal documents point to a deeper change. Mukuru is moving from a standalone prepaid card towards an architecture in which a transactional bank account supports day-to-day payments, salary receipt and money transfers.
For African fintechs, the useful lesson is not limited to the feature list. It lies in the distribution of roles across four participants: Mukuru owns the proposition and customer relationship, Bank Zero sponsors the account and card, Paymentology provides issuing and processing capabilities, and Mastercard supplies the acceptance network.
What materially changes for the customer
According to Mukuru’s official product page, customers can receive salaries and other EFT deposits, send money to South African bank accounts, make immediate payments, pay online or in stores, withdraw cash and continue sending remittances to more than 60 countries.
The published monthly spending limit is R150,000. Sub-limits still apply: outgoing EFTs, in-store payments and online purchases are each limited to R25,000 per day, while daily ATM withdrawals are capped at R15,000, with a maximum of R5,000 per transaction.
Paymentology says about 500,000 Mukuru customers already hold a prepaid card. This is a company statement, not an audited regulatory statistic. It nevertheless defines the migration challenge: the new product is not starting from zero and must transition an existing customer base without interrupting payments, cash withdrawals or salary receipt.
One visible brand, several lines of responsibility
The product’s official terms and conditions define the Account as a transactional current account made available by Mukuru and sponsored by Bank Zero. They also state that Bank Zero is a registered South African mutual bank and remains the owner of the debit card.
The architecture separates at least four functions:
- distribution and customer experience, managed by Mukuru through branches, the app, WhatsApp and USSD;
- banking responsibility, carried by Bank Zero for the account and card within the applicable regulatory framework;
- issuing and processing, provided by Paymentology;
- acceptance, provided through the Mastercard network.
This model enables a fintech to launch a broader banking proposition without building every underlying capability itself. It also creates an obligation: customers need a clear answer when a KYC hold, duplicate payment, card dispute, delayed EFT or technical outage occurs.
A single contact centre is not enough. The operating model needs a responsibility matrix showing who detects an incident, who makes the decision, who informs the customer, who posts the correcting entry and who absorbs any resulting loss.
Moving to an account changes the protection of funds
The earlier Mukuru Card was described as a prepaid card. The new proposition is built on a transactional account. That distinction has a concrete legal and financial consequence.
Mukuru’s terms state that money in the account is covered by the Corporation for Deposit Insurance, subject to eligibility and up-to-date KYC. The South African Reserve Bank explains that CODI protects qualifying balances up to R100,000 per depositor per bank when the bank is placed into resolution. Bank Zero appears on the official member-bank list.
This protection should not be described as insurance against fraud, payment errors or commercial losses. Deposit insurance applies to the specific event of a bank failure. It does not replace dispute handling or Mastercard’s card-transaction rules.
The account pays no interest and has no overdraft facility. A negative balance may nevertheless arise following a chargeback, correction, fraud recovery or processing error, in which case the customer must repay it. No commercial overdraft does not mean that operational debit-balance risk disappears.
Total cost combines subscription and usage
As of 27 October 2026, the official pricing page lists:
- a R30 monthly service fee;
- a R85 card activation fee;
- R5 for an outgoing EFT;
- R8 for a real-time payment;
- R1.50 for an online purchase;
- R15 for each R1,000 block withdrawn at an ATM;
- a R5 fee for a declined ATM, online or point-of-sale transaction.
In-store payments and incoming EFTs are listed as free. The product as a whole is not free, however, because monthly and usage-based charges accumulate.
A proper comparison with a bank account, wallet or prepaid card requires customer-use profiles. A salaried customer who receives EFTs and mostly pays in stores will incur a different cost from someone who makes several withdrawals, immediate payments and online purchases. Average monthly cost per active user is therefore more informative than an isolated fee list.
Migration is a payments project in its own right
The product page says that an existing card balance will move automatically when the customer upgrades to the new account, after which the previous card stops working. Separately, Mukuru asks affected users to share new Bank Zero-Mukuru EFT details with employers and other payers by 30 November 2026. The previous EFT details are due to stop working after that date.
Those instructions do not necessarily apply to the same customers or migration stage. Together, however, they illustrate the controls required:
- link the legacy wallet, new account and new card correctly;
- transfer each balance exactly once;
- prevent salary payments from being sent to obsolete details;
- monitor incoming payments on the old route during the transition;
- prevent phishing attacks built around the change in bank details;
- give the customer clear evidence that migration has completed.
The most important risk is not limited to a system-wide outage. Silent failures also matter: an untransferred balance, incorrectly communicated account details or an EFT sent after a legacy identifier has been retired.
Incidents reveal the quality of the model
The account terms say that an authorised transaction generally cannot be stopped unless applicable law or Mastercard rules allow it. They also tell customers to check their statement and contact Mukuru before resubmitting an instruction whose status is uncertain. A second attempt may create a duplicate payment.
This rule matters for every Banking-as-a-Service arrangement. When several systems are involved, a delayed display does not prove that the first instruction failed. Platforms need unique transaction identifiers, idempotency controls, status enquiries and shared rules for returns, reversals and correcting entries.
The indicators that should be monitored
The proposition should not be assessed only by the number of cards distributed. More useful indicators include:
- successful migration rate among legacy customers;
- share of accounts still active after 30 and 90 days;
- salary and incoming-EFT straight-through processing rate;
- card authorisation rate;
- normal and immediate EFT failure rates;
- number of duplicate or uncertain-status payments;
- dispute and chargeback resolution time;
- average monthly cost by customer profile;
- share of customers using both domestic payments and international remittances;
- fraud rate by channel and per thousand active accounts.
A replicable model, but not an automatically transferable one
The new Mukuru account shows how a remittance-focused fintech can deepen its customer relationship without becoming solely responsible for the entire banking chain. The sponsor bank, processor and network supply distinct capabilities. The fintech retains distribution, customer knowledge and the integration of use cases.
The model is relevant across Africa, but it cannot be copied without adaptation. Rules governing deposits, sponsorship, card issuance, safeguarding, deposit insurance and access to payment systems vary by jurisdiction.
The most useful lesson is operational: assembling partners can accelerate a launch, but product quality depends on clear ownership, customer migration, incident handling and the cost customers actually bear. That is where the move from prepaid card to bank account becomes a genuine transformation rather than a change of label.
