Much of financial technology is easy to see. A person opens a banking application, scans a payment code or receives a notification. Other developments take place in the systems that institutions use to move money and assets between themselves. Project Khokha belongs to this less visible part of South Africa’s financial technology story.
The project is useful to understand because discussions of digital money often combine several different ideas. An experiment involving banks may be described as though it were a new consumer payment application. A token representing an asset may be discussed as though it were automatically an investment opportunity. Those shortcuts can obscure what researchers actually tested.
This article explains the documented project and then uses illustrative examples to examine the questions behind it. The focus is financial infrastructure and research, not instructions to buy a token or a prediction about future returns. The central question is how institutions might exchange value more effectively while maintaining clear responsibilities and dependable records.
Project Khokha tested technology in controlled settings
In a June 2026 speech, South African Reserve Bank Deputy Governor Rashad Cassim described Project Khokha as a series of proof-of-concept experiments beginning in 2018. He explained that the first project tested permissioned distributed ledger technology and that the 2022 follow-up added tokenised securities and forms of wholesale digital money. The speech also highlighted unresolved governance and legal questions. [1]
The Reserve Bank published the Project Khokha 2 report in April 2022. Its summary describes a proof of concept involving a tokenized debenture market and linked distributed ledger platforms. A debenture is a debt instrument; the experiment concerned financial market processes rather than a new everyday shopping application. [2]
These facts establish the project’s research setting. A proof of concept asks whether an approach can work under specified conditions and what difficulties emerge. It is not equivalent to an announcement that a national service has been deployed for unrestricted public use.
That distinction should remain visible whenever the project is discussed. Readers can recognize technical progress while asking what was tested, which participants were involved and what decisions would still be required before a similar design could operate as a live service.
Wholesale money and retail money answer different questions
The Bank for International Settlements distinguishes retail central bank digital currency, intended for general use, from wholesale arrangements designed for financial intermediaries. The distinction concerns the users and purpose of the instrument, not simply whether it is electronic. [3]
A consumer sees the balance and functions of a personal bank account. Institutions also need arrangements for settling obligations between themselves. Changing the technology used in that institutional layer does not necessarily change the application on the consumer’s phone or create an account that every individual can open.
An everyday comparison is a delivery company. Customers interact with ordering and tracking, while the company manages other systems for sorting and transferring parcels between facilities. Improving an internal process can matter to the overall service without giving customers direct access to that process.
The comparison has limits, but it helps explain why the intended user should be identified first. Before asking whether a digital money project will change shopping, a reader needs to establish whether the experiment was designed for shoppers, banks or another defined group of participants.
Tokenization changes how a claim is represented
The BIS describes tokenization as recording claims on assets on a programmable platform. Such a design can connect the asset record with rules governing actions involving it. This does not mean that creating a token automatically makes the underlying claim valid, valuable or easy to trade. [4]
Consider a hypothetical record representing a debt obligation. The digital representation needs a clear connection to the issuer’s obligation and the holder’s rights. A reader needs to understand what is promised, by whom and under which arrangements. The technical format alone cannot answer those questions.
This is why two tokens can represent very different things. One may relate to a debt instrument, another to a payment claim and another to something with no equivalent rights. Similar terminology does not establish identical risks or legal treatment.
For Project Khokha, the useful question is what the representation enabled researchers to test in a defined market process. It is less useful to treat tokenization as a single product category whose benefits can be assumed before examining the instrument and the system in which it operates.
Follow an illustrative exchange from agreement to completion
Imagine two hypothetical institutions agreeing that one will purchase a specified financial asset from the other. They need agreement on the asset, price, parties and timing. The transaction must then result in the appropriate movement of the asset and the corresponding payment.
Those steps create coordination questions. Has the buyer provided the required payment? Is the seller able to deliver the asset? Do both records reflect the same agreed transaction? What happens if one required condition is not met?
A digital platform might be designed to check specified conditions and coordinate actions. The example illustrates the attraction of programming parts of the process, but it does not establish that every check can be automated or that all information needed by the system is already available in a reliable form.
The system also needs an exception path. Suppose a required authorization is missing or an asset identifier is incorrect. A useful design should indicate why the transaction cannot proceed and who can resolve the issue. Automating successful cases without defining failures can leave the most difficult work unresolved.
Delivery versus payment links two sides of a trade
The BIS identifies delivery versus payment as an example of actions made conditional on one another: the transfer of an asset depends on payment, and payment depends on the asset transfer. Programmable arrangements can support this coordination, subject to the design and safeguards of the system. [4]
For a non-specialist, the idea can be understood as avoiding an exchange in which one party completes its side while the other side remains uncertain. The actual financial arrangements are more complex than an informal handover, but the coordination problem is recognizable.
An illustrative design could check whether both sides are ready before completing the exchange. That still leaves important questions. What counts as ready? Who verifies the asset? Which form of money is being used? What does completion mean if another system needs to recognize the result?
The technology should be evaluated against those questions rather than only the speed of a demonstration. A fast exchange is useful when the parties can rely on its meaning and consequences. Speed without clarity about the result is not a complete account of financial efficiency.
A shared record does not remove the need for governance
Suppose several institutions use a shared platform. They still need rules about who may participate, who can change software and what happens when participants disagree. Technical agreement about a record is only one part of an operational arrangement.
Imagine that a new version of the software changes how an instruction is processed. Who approves the update? How are participants informed? What tests are required before the change affects live transactions? These questions remain important whether the record is held in a conventional database or distributed across several participants.
Responsibility for mistakes must also be clear. A transaction may have been entered incorrectly even if the platform executed its instructions exactly as written. The affected institutions need a recognized procedure for investigating and resolving the problem.
These examples show why governance should be designed alongside the technical process. A project can use a demonstration to discover where decisions are missing. Identifying those gaps is a useful research result, because it prevents a working prototype from being mistaken for a fully specified operating institution.
Privacy requirements shape the design
Institutions may need to share enough information to complete a transaction while restricting access to details that other participants do not need. A shared platform therefore raises a practical question: which information should each participant be able to see and for what purpose?
Consider an illustrative market in which every participant can inspect all other participants’ activity. That visibility might simplify some checks while revealing information beyond what the transaction requires. A design with more restricted visibility would need another way to carry out the necessary verification.
Neither approach can be evaluated through a slogan about transparency. The appropriate design depends on legitimate operational needs and the rules governing the service. Researchers need to test whether access controls and verification can work together under realistic conditions.
Reporting should explain the trade-off being examined rather than imply that privacy and performance are automatically solved by the choice of a particular technology. A controlled experiment can provide evidence about one arrangement while leaving other configurations and operating conditions to be tested separately.
Existing systems still need to communicate
A new platform rarely exists in isolation from the rest of an institution’s work. Participants may have accounting, reporting and risk systems that need to recognize what occurred. A transaction completed in one environment can still require a dependable connection to another.
The Project Khokha 2 summary describes linked ledger environments, including a software bridge between them. This is a concrete example of integration forming part of the experiment rather than disappearing because assets were tokenized. [2]
An illustrative interface needs to answer several operational questions. How does the receiving system identify the transaction? What happens if a message arrives twice? How is a delayed update distinguished from a missing one? Who checks that the records remain consistent after an interruption?
These are useful questions for evaluating any financial infrastructure project. A demonstration may work smoothly when every component is available, but the complete arrangement also needs to handle communication failures and recovery. Integration deserves attention because users depend on the result across the whole process.
Faster settlement can change funding needs
The timing of a transaction affects when resources must be available. In a simplified hypothetical arrangement, an institution completing each payment immediately needs the required funds at each completion point. Another arrangement might organize obligations on a different schedule. The operational consequences depend on the rules and participants involved.
This means that evaluating speed also requires examining how participants prepare for transactions. A faster process could remove some uncertainty while changing the timing of funding or other tasks. The example does not establish that one arrangement is always preferable; it shows why a complete comparison needs more than elapsed seconds.
A useful trial can record when transactions are ready, what prevents them from proceeding and which resources are required. It can then examine whether the new design improves the intended process under realistic workloads. The measures should reflect the problem the project set out to investigate.
Readers should be cautious about a headline claiming that faster automatically means cheaper for everyone. Costs can move between participants or stages. A credible assessment identifies who benefits, who incurs new responsibilities and which assumptions support the comparison.
Research needs a clear boundary and a fair comparison
A proof of concept can test technical feasibility without answering every question about national deployment. The number of participants, transaction patterns, equipment and operating conditions may be deliberately limited. Those limits help researchers isolate a question, but they also constrain the conclusions.
Suppose an experiment completes a selected set of transactions successfully. That result supports a statement about those transactions under those conditions. It does not automatically establish performance during a major outage, with much larger participation or under a different set of legal requirements.
A fair comparison also needs a defined baseline. The new process should be compared with a relevant existing process performing a similar task. Comparing a simplified prototype with every responsibility of a live system can produce an impressive figure that does not answer the real operating question.
The strongest research reporting explains what worked, what did not and what requires further investigation. That is more useful than treating an experiment as either a complete revolution or a failure. Learning where an approach is unsuitable can be as valuable as identifying a promising use.
Consumers should distinguish research from a product offer
Project Khokha’s name in a technical discussion does not, by itself, identify a consumer service or an investment that members of the public can purchase. An article about the project should therefore avoid suggesting that readers need to obtain a related token to participate in South Africa’s financial future.
If someone encounters a product claiming a connection to public research, the connection needs independent verification through the responsible institution’s official information. A familiar project name in promotional material is not sufficient evidence of authorization, endorsement or a particular set of rights.
The same discipline applies to statements about digital currency policy. In the June 2026 speech, the Reserve Bank described a retail central bank digital currency as technically feasible while stating that there was no compelling need for immediate implementation. That dated position should not be transformed into an announcement of a public launch. [1]
For ordinary readers, the useful outcome is understanding the distinction between research, policy and an available product. Each requires different evidence. Keeping them separate makes technology coverage clearer and reduces the chance that a technical achievement is used to support an unrelated commercial claim.
What meaningful progress would look like
The next important development in a financial infrastructure project is not necessarily a more dramatic demonstration. It may be a clearer operating model, stronger evidence about recovery or an agreed way to connect systems. These details determine whether a promising design can support dependable activity outside a controlled experiment.
For South Africa, Project Khokha shows that local institutions have investigated questions about digital assets and settlement through practical experiments. Its significance should be assessed through what those experiments established and the questions they exposed, rather than predictions that extend beyond the evidence.
Readers can follow future developments by asking who the intended users are, what claim or asset is represented, what stage the project has reached and which responsibilities are defined. Those questions remain useful even as the technical vocabulary changes.
Financial technology becomes valuable when people and institutions can rely on the result. A new representation of money or an asset is only part of that achievement. Clear rights, workable operations and evidence about performance are what allow an experiment to inform a responsible decision about the future.
Sources
[2] South African Reserve Bank. Project Khokha 2 report release and summary report, April 2022.