A Strategic Navigation Framework for Banks in the Tokenised Economy
Download the PDF · 14 pagesBanks across the world are building digital-asset capability. Deutsche Bank announced an institutional custody service on 16 September 2026. The BIS and the Institute of International Finance have taken Project Agorá from prototype to real-value settlement using tokenised central bank reserves and tokenised commercial bank deposits. In South Africa, the Reserve Bank demonstrated tokenised securities settlement in Project Khokha 2 four years ago.
Almost none of this work is blocked on technology. It is blocked, or ought to be, on a legal question that most strategy papers pass over in a single bullet point:
When the ledger and the register disagree, which one is wrong?
This paper argues that the answer to that question is the organising decision in digital-asset banking, and that it has a different answer in different jurisdictions. Switzerland answered it in statute in 2021. The United States answered it through the SEC in January 2026. South Korea legislated an answer the same month. South Africa has not answered it at all. The Financial Markets Act 19 of 2012 does not define a security token, a gap Project Khokha 2 identified in 2022 that remains open.
The consequence is direct and commercial. A bank that builds custody, tokenised deposits, tokenised securities and digital markets without resolving where title lives has built programmable infrastructure over an unresolved legal question. It will discover which side of that question it was on during its first dispute, its first insolvency of a counterparty, or its first unexplained on-chain balance.
We set out a five-stage evolution framework, running from Custody through Digital Money, Tokenised Assets and Digital Markets to Digital Banking, and at each stage identify the specific form the register question takes, what a bank must decide, and what the current evidence shows about how others have decided.
Our central recommendation is that South African banks should build on the assumption that the authoritative record remains off-chain, with the ledger as a derived and reconcilable mirror, and should build in such a way that this assumption can be relaxed rather than reversed if the law changes. We explain why that is a migration path rather than a hedge.
Digital-asset strategy documents tend to converge on the same architecture diagram. A blockchain layer at the bottom, a compliance layer above it, products above that, customers at the top. The diagrams are broadly correct and almost entirely unhelpful, because they describe where systems sit rather than where legal authority sits.
Consider what a bank is actually promising when it offers custody of a tokenised bond.
If the token is the bond, meaning the ledger entry constitutes title, then safekeeping the private key is safekeeping the security, and the bank's custodial obligation is discharged by cryptographic control. If the token is not the bond, and title lives in a register maintained elsewhere, then the bank holding the key is safekeeping a representation. Its client's ownership is unaffected by what happens to the token, and equally unprotected by the bank's control of it.
These are different products with different liabilities, different insurance requirements, different insolvency treatment and different failure modes. They look identical on an architecture diagram.
The question generalises. At every stage of digital-asset development, the same fork appears:
| Capability | If the ledger is authoritative | If the register is authoritative |
|---|---|---|
| Custody | Key control is title control | Key control is control of a mirror |
| Tokenised deposits | Token transfer discharges the obligation | Token transfer instructs a book entry |
| Tokenised securities | Smart contract enforces restrictions | Register enforces; contract cannot |
| Digital markets | Atomic settlement is legal settlement | Atomic settlement is operational only |
| Integrated banking | One record | Two records and a reconciliation duty |
The right-hand column is not a degraded version of the left. It is a different system, and it is the one South African law currently describes.
Four jurisdictions have now given explicit answers, in three different legal traditions, within five years.
The Swiss DLT Act amended ten existing federal laws rather than creating a parallel regime. Its centrepiece, article 973d of the Code of Obligations, created the ledger-based security: an uncertificated security whose legal existence is the register entry itself. Rights transfer with the token. The ledger is not evidence of title; it constitutes title.
Crucially, Swiss law did not achieve this by abolishing the concept of a register. It achieved it by specifying what a register must do, namely integrity, transparency, and the ability of holders to verify their own entries, and then permitting a distributed ledger to satisfy those requirements. This point is easy to miss and important to the argument in Section 7.
On 28 January 2026 the SEC published its Staff Statement on Tokenized Securities. Its core holding is that the recording format does not change how the federal securities laws apply. A share remains an equity security whether recorded in a conventional database or on a blockchain, and a distributed ledger network can form part of the official securityholder register.
Market infrastructure followed within three months. The SEC approved a Nasdaq rule change in March 2026 permitting tokenised securities to trade in the same order book as conventional ones with the same execution priority, and NYSE Rule 7.50 took effect in April. The Depository Trust Company holds a no-action letter for a tokenisation service in which digital versions of securities retain the same entitlements as their conventional counterparts.
Note the phrasing that recurs: part of the official register. Not instead of it.
The National Assembly amended the Electronic Securities Act and the Capital Markets Act to permit securities to be issued, recorded and managed on a distributed ledger, bringing DLT inside an existing dematerialised-securities regime rather than beside it.
The Financial Markets Act 19 of 2012 is the foundation of South African capital markets and was drafted for a dematerialised world rather than a distributed one. Uncertificated securities are recorded in registers administered through a licensed central securities depository and its participants. That structure is not incidental. It is the Act's answer to who is accountable for the accuracy of the record.
Security tokens are not defined in the Act. Project Khokha 2 said so in 2022 and called for the legislation to be updated. It has not been.
What South Africa does have is a functioning conduct perimeter for crypto-asset service providers. The FSCA has processed over 500 CASP applications since June 2023 and licensed approximately 300, and the FATF greylisting that shadowed that process has been lifted. By the standard of crypto-asset conduct regulation, South Africa has moved faster than most comparable jurisdictions.
But a CASP licence regulates the conduct of a service provider. It does not make a token a security, and it does not make a ledger entry a transfer of title. These are different questions in different statutes, and only one of them has been answered.
The resulting position is unusual and worth stating plainly: comparatively advanced crypto-asset regulation, no securities tokenisation regime.
The five stages below are capabilities, not a mandatory sequence. A bank may develop them in a different order or stop at any point. What follows each stage description is the specific form the register question takes there, because that is what determines whether the capability is durable.
Objective: establish trusted control over digital assets and the cryptographic material that governs them.
Core capabilities: wallet infrastructure, private-key management, cold and warm storage, transaction authorisation, multi-party approval, asset segregation, blockchain monitoring, recovery mechanisms, reporting and compliance controls.
Custody is the right entry point, and the market agrees. Deutsche Bank announced on 16 September 2026 that it plans to launch digital-asset custody for European institutional and corporate clients, initially supporting Bitcoin, Ether and a limited set of stablecoins including USDC, EURC and EURAU, with the bank managing client wallets and private keys across warm and cold storage. Go-live remains subject to completion of regulatory checks. Its stated roadmap extends from crypto-assets to tokenised securities.
That sequencing is itself evidence for this paper's argument. The bank is starting with instruments where the ledger is the asset, since a bitcoin is not a claim recorded elsewhere, and moving later to instruments where it is not. Those are different custodial products, and building the first does not automatically qualify an institution to offer the second.
The register question at Stage 1: custody of what?
For a native crypto-asset, key control is close to ownership, and the custodial obligation is reasonably described by the cryptography. For a tokenised security in a jurisdiction where the ledger is not title, key control is control over a representation. A bank that markets both under the single word "custody" is describing two obligations with one term, and will be held to whichever interpretation its client reasonably formed.
What to decide: whether custodial terms distinguish between asset classes by reference to where title sits, and whether the institution's insurance, capital treatment and client disclosures follow that distinction.
Objective: enable money to operate within programmable infrastructure.
Three forms are emerging: stablecoins, tokenised commercial bank deposits, and central bank digital currency at wholesale or retail level. Potential products include tokenised deposit accounts, stablecoin settlement, digital corporate wallets, programmable payments, 24/7 treasury services, cross-border digital payments, automated escrow and machine-to-machine payments.
The strategic transition is from a bank account to a programmable bank account: payments that execute when conditions are satisfied rather than when a customer instructs.
The register question at Stage 2: whose obligation is it, and does tokenising it change that?
Here the evidence is unusually good, because the BIS has tested the question directly at scale. Project Agorá published prototype findings on 27 May 2026, involving the Bank of England, the Federal Reserve Bank of New York, the Bank of France for the Eurosystem, the Bank of Japan, the Bank of Korea, the Bank of Mexico, the Swiss National Bank and more than 40 private-sector institutions. The prototype demonstrated atomic multi-currency settlement of wholesale cross-border transactions using tokenised central bank reserves and tokenised commercial bank deposits, securely and with finality across all seven jurisdictions.
The project then moved to real value. In July 2026, 22 financial institutions and five central banks completed 30 transactions worth approximately CHF 800,000 across six currencies, with average time from initiation to settlement of around 80 seconds. This was achieved without connection to central bank settlement systems or participants' core banking systems. The project remains experimental with no commitment to production.
The finding that matters most for this paper is not the speed. It is that the BIS found tokenisation does not change the legal characterisation of reserves or deposits. A tokenised deposit is a deposit. The claim is on the issuing bank, governed by the law that governs deposits, and the token is the mechanism by which the claim is moved and recorded.
That is the same proposition this paper advances about securities, tested by central banks, about money.
What to decide: whether the institution's tokenised deposit product is structured as a deposit claim recorded on a ledger, or as a bearer instrument. The first is conventional banking with new plumbing. The second is a different business requiring different permissions.
Objective: extend from digital money into digital ownership.
Candidate assets include government and corporate bonds, investment funds, money-market instruments, private credit, property-related instruments, commodities, infrastructure and carbon-related assets.
Banks can develop tokenisation-as-a-service: asset onboarding, token creation, investor identity, compliance rules, ownership registers, custody, distribution, corporate actions, payments, settlement and reporting.
Published frameworks routinely list "ownership registers" as one item among eleven. It is not one item among eleven. It is the item that determines what the other ten mean.
The register question at Stage 3: where does title live, and what follows from that?
In South Africa today the answer is that title lives in the register and the chain is a derived mirror. Three consequences follow, and they are not optional.
Transfer restrictions must be enforced at the register, not at the token. Minimum holdings, lock-ups, holder counts and eligible-transferee tests exist because private placements depend on exemptions, and a breached exemption is an unregistered public offer. Enforcing those rules in a smart contract is intuitive and, where the token is not title, ineffective: the contract has prevented a token movement while the underlying rights sit wherever the register placed them. The restriction engine must run where the legal effect lands.
The register must be event-sourced rather than state-stored. Holdings should be a fold over an append-only sequence of events, with corrections written as new reversing events rather than edits. This is not architectural preference. The question a court or regulator asks is never "who holds this today" but "who held this on 14 March, and what did the registrar know then." A mutable table cannot answer that. A sequence of events reconstructs any historical position and shows its own corrections.
Reconciliation must be asymmetric. When register and ledger diverge, the ledger is corrected and the register is never adjusted to match. Adjusting the register to match the chain concedes that the chain is authoritative, and does so in an operations script rather than in a statute.
The asymmetry has a further refinement that is legal before it is technical. A holder short on-chain is credited; a holder over is debited. But an address holding units with no register position at all is frozen, not burned. Burning restores the invariant in one operation and is the wrong response, because an unexplained balance is not a data inconsistency. It is evidence of an unauthorised transfer, a control failure, or a defective mirror, and the on-chain state looks identical in all three cases. Freezing halts the harm and preserves the evidence. Burning halts the harm and destroys it. The code cannot determine which of the three it is looking at, which is precisely why freezing is the correct default rather than a judgement call.
It follows that the freeze must itself be a governance decision rather than an engineering one. The authority to impose it should sit apart from the party that operates the record, it should carry an evidential basis, and it should have a review date requiring affirmative renewal rather than persisting by inertia.
One further capability deserves attention because it is where the ledger earns its place. If the register is authoritative, a reasonable question is why a chain is needed at all. The answer is that an authoritative record held by a single operator is only as reliable as that operator's honesty about its own history. Publishing a running hash of the register's event log on-chain at intervals commits the registrar publicly to a sequence it cannot later alter undetected. That is tamper-evidence for an off-chain record, and it is the first function in the architecture that the chain provides and the register cannot provide for itself.
What to decide: whether tokenisation-as-a-service is sold as a token-issuance capability or as a register-operation capability. The second is a regulated-adjacent, liability-bearing role. It is also the more defensible business.
Objective: create markets in which tokenised money and tokenised assets interact.
A conventional securities transaction involves separate organisations for execution, clearing, settlement, custody, reconciliation and payment. Tokenised infrastructure allows a tokenised bond and tokenised money to exchange simultaneously, producing delivery-versus-payment at the infrastructure level. Products include digital-asset trading, tokenised securities settlement, digital collateral management, intraday liquidity, tokenised repo, securities lending and institutional brokerage.
The register question at Stage 4: is atomic settlement legal settlement?
Only where the law says the ledger record constitutes the transfer. Elsewhere, atomicity is an operational property. The two legs complete or fail together on the ledger, which eliminates a class of operational risk and does not, by itself, effect the transfer of title. Legal finality still arrives when the authoritative record says it does.
This is not an argument against building it. Operational atomicity is valuable on its own terms. It is an argument against describing it to clients, auditors or regulators as something it is not.
There is a further constraint that becomes visible at this stage and is almost absent from the literature. A connection between two ledgers in two jurisdictions is a connection between two mirrors. Cross-border tokenised settlement requires not only that the ledgers interoperate but that each jurisdiction's authoritative record recognises and honours an instruction originating in the other. Interoperable ledgers over non-interoperable titles do not produce the liquidity pool the economic case assumes. Agorá's layered architecture, in which each central bank retains autonomy over its national currency within an interoperable shared platform, is an acknowledgement of exactly this problem in the money leg.
What to decide: whether settlement documentation, client terms and risk models distinguish operational finality from legal finality, and where the residual gap between the two is held.
Objective: integrate digital assets into mainstream banking products.
At this stage digital assets stop being a technology programme. A corporate banking relationship spans conventional accounts, tokenised deposits, approved stablecoins, potential CBDC balances, tokenised securities, digital collateral facilities and programmable treasury services, without the customer needing to know which rail underlies which service.
The register question at Stage 5: which record governs?
The technology can disappear behind the product only if this question has been answered, because the customer no longer sees the distinction and the bank retains all of the liability for it. An institution that reaches Stage 5 without a settled answer has not resolved the problem. It has concealed it from the only party who might have noticed.
Digital-asset architecture is usually described in seven layers, running from customer experience at the top down to external financial infrastructure at the base. The stack set out below has eight. The additional layer is the authoritative record, and its absence from the conventional description is the reason so many digital-asset programmes are built without the question in Section 1 ever being asked.
Layer 3 sits deliberately above the digital-asset services layer and below the products layer. It is not a component of blockchain infrastructure. It is the legal record that the blockchain infrastructure serves, and in jurisdictions that have legislated ledger-based securities it is the layer into which the ledger has been formally admitted.
Placing it correctly is the difference between an architecture that survives a change in the law and one that has to be rebuilt.
Banks can assess their position using five levels. The fourth column is what distinguishes this assessment from a conventional technology maturity scale, and it is the column that matters.
| Level | Bank position | Primary capability | Register question answered? |
|---|---|---|---|
| 1. Explore | Experimental | Research, sandboxing, regulatory engagement | Not yet asked |
| 2. Enable | Foundations established | Custody, wallets, identity, compliance | Asked for native crypto-assets only |
| 3. Participate | Digital products introduced | Digital money, tokenised assets | Answered per product, inconsistently |
| 4. Integrate | Connected to core banking | Payments, markets, collateral, treasury | Answered institutionally, documented |
| 5. Transform | Mainstream banking capability | Programmable, interoperable services | Answered, and the architecture can absorb a change in the answer |
An institution can reach Level 4 on conventional measures while sitting at Level 2 on the register question, and that combination is the specific failure mode this paper is written to describe: mature infrastructure over an unexamined legal premise.
South Africa is not waiting, and this is the fact that makes the question urgent rather than academic.
The JSE has been in discussion on tokenised bonds. RainFin has issued the country's first R100 million of tokenised debt on a permissioned network, working within the CASP perimeter and focusing on private credit rather than listed equities. The Reserve Bank demonstrated DLT-based settlement in Project Khokha and added tokenised securities and alternative forms of settlement money in Khokha 2.
Khokha 2 is usually cited as evidence that South Africa is engaged with tokenisation. It is better read the other way. The project identified that security tokens sit outside the Financial Markets Act and recommended the Act be updated. Four years later the gap is open, issuance has begun regardless, and the first tokenised private-debt structures in this market are being built against a statute that does not contemplate them.
For South African banks this produces a narrow and clear design constraint:
Build on the basis that the register is authoritative and the ledger is a derived, reconcilable mirror. Build so that this assumption can be relaxed rather than reversed.
Priority development areas where that constraint is workable today: institutional digital-asset custody, tokenised deposits, cross-border settlement, tokenised private credit and infrastructure investment, digital collateral, trade finance and programmable corporate payments.
Areas requiring statutory change before they are viable at scale: anything that depends on the ledger constituting title, including on-chain enforcement of transfer restrictions in listed instruments and true legal delivery-versus-payment.
The obvious objection is that building for the current constraint is wasted effort, and that an amendment to the Financial Markets Act recognising ledger-based securities would render the off-chain register redundant.
Two reasons this does not follow.
First, no jurisdiction that legislated has deleted the register. The SEC's position is that a distributed ledger can form part of the official securityholder register. The DTC's tokenisation service places tokenised assets inside existing depository infrastructure. Switzerland's article 973d requires the ledger to satisfy conditions on integrity, transparency and holder verification before the law will treat it as a register at all. Every jurisdiction that answered the question answered it by specifying what a register must do and then permitting a ledger to do it.
Second, the migration path runs from an explicit register, not from an implicit one. An event-sourced register with a documented restriction engine and an explicit reconciliation policy already states, in enforceable form, what every event means and which rules applied when. Moving that to a ledger-based statutory register changes where the authoritative sequence is written. It does not change what the sequence means. The equivalent migration from an undocumented state table is a rebuild.
Building honestly against the current constraint is therefore the shortest route to being ready when the constraint lifts.
The difficult questions are not technological.
Where do we participate? Custody, payments, tokenisation, trading, settlement, or a defined subset.
What is strategic intellectual property? In our view the register operation and its reconciliation policy are strategic and the wallet infrastructure is not, which is the reverse of how most institutions currently allocate build effort.
What do we buy? Specialist providers deliver key management and blockchain analytics more efficiently than most banks can. Deutsche Bank's use of Taurus and Bitpanda Technology Solutions is the reference case.
Where do we partner? Networks, market infrastructures, CSDs and technology providers, with particular attention to whether a partner's model assumes the ledger is authoritative.
Which assets do we support? Not every tokenised instrument belongs in a regulated banking environment, and the register question is a useful screen. Instruments where title is unambiguous are materially easier to support.
How does existing infrastructure evolve? Digital-asset platforms cannot remain isolated from core banking, treasury, risk, data and compliance.
What risks are acceptable? Set out in Section 10.
Phase 1. Establish the legal position. Before technology selection, obtain a written internal determination of where title sits for each instrument class the institution intends to support, under South African law, with the CSD and participant structure of the FMA expressly addressed. This phase is usually skipped and is the cheapest phase to get right.
Phase 2. Build the trust foundation. Custody, wallets, identity, compliance, blockchain analytics, governance. Distinguish custodial terms by instrument class per Phase 1.
Phase 3. Introduce digital money. Tokenised deposits, programmable payments, stablecoin settlement, cross-border. Structure the deposit product as a deposit claim, consistent with the Agorá finding.
Phase 4. Introduce tokenised assets. Register first, tokens second. Event-sourced record, restriction engine at the register, asymmetric reconciliation with freeze rather than burn, anchoring for tamper-evidence.
Phase 5. Develop digital markets. Settlement, collateral, repo, liquidity. Document the distinction between operational and legal finality in client terms.
Phase 6. Integrate. Core banking, treasury, risk, payments, data, channels.
Phase 7. Prepare for statutory change. Maintain a documented migration path from off-chain authoritative register to ledger-based register, and revisit it whenever the FMA review produces output.
| Risk | Description | Mitigation |
|---|---|---|
| Title risk | The institution's assumption about where title sits is wrong or undocumented | Phase 1 legal determination, per instrument class, in writing |
| Reconciliation risk | Register and ledger diverge without detection or with incorrect repair | Asymmetric reconciliation policy, divergence taxonomy, freeze as the default response |
| Evidential risk | The institution cannot reconstruct historical holdings for a disputed date | Event-sourced register; no destructive corrections |
| Governance risk | Incident powers such as freezing sit with the operator of the record | Separate the freeze authority; evidential threshold; expiry with affirmative renewal |
| Key management risk | Loss or compromise of cryptographic material | Hardware protection, multi-party approval, segregated warm and cold storage, tested recovery |
| Smart contract risk | Defects in on-chain logic | Restrict contract authority to mirroring; audit; minimise privileged functions |
| Interoperability risk | Cross-border settlement assumes recognition between registers that does not exist | Assess legal recognition, not only protocol compatibility |
| Regulatory change risk | Statutory recognition of ledger-based securities alters the architecture's premise | Maintain documented migration path (Phase 7) |
| Concentration risk | Dependence on a single ledger, custodian or technology provider | Multi-provider strategy; exit planning |
The tokenisation debate is usually conducted as a question about technology, and occasionally as a question about regulation. It is better understood as a question about records.
Money is becoming programmable. Assets are becoming tokenisable. Settlement is moving towards continuous operation. None of that resolves the question of which record the law will believe when two records disagree, and that question determines what every capability in the stack actually is.
Four jurisdictions have answered it. South Africa has not. Issuance here has started anyway.
For South African banks the practical conclusion is not to wait, and not to pretend. It is to build on the answer the law currently gives, namely that the register is authoritative and the ledger is a derived mirror, and to build in a way that treats that answer as a parameter rather than an assumption, so that a change in the statute becomes a migration rather than a write-off.
The objective is not tokenisation. It is a financial system that is more programmable, more efficient and more transparent, built on records that hold up when tested.
TokenWyze Research produces analysis on tokenised financial infrastructure with a focus on South African and African market conditions. Our work is grounded in working implementations rather than survey data, on the view that architectural claims about financial records should be inspectable.
This paper is not legal advice. It takes current South African law as a constraint and does not express a view on what the law should become.
← Back to Research