Tokenized fund register reconciliation
A tokenized fund runs two books, the ledger the token moves on and the shareholder register a transfer agent maintains, and three published regimes now say which one wins when they disagree, in two opposite directions. None of them says how anyone learns the two diverged, at what cadence or where the investor stands between a bad entry and its reversal.
18 min read
31 views
Technically reviewed by Olena Zaichenko, D.Sc.
- Two SEC filings picked opposite authoritative registers within six months of each other A Form 497 prospectus supplement filed 29 July 2026 makes the blockchain book-entry records official and the off-chain copy a back-up, while a Form 40-APP filed 21 January 2026 makes the transfer agent's Official Share Register authoritative over the DLT platform, and both branches were already named in the SEC staff taxonomy of 28 January 2026.
- A tie-break clause only settles an argument somebody has already noticed The one public cadence is a daily floor, discrepancy resolution is described as something that may require investigation with no stated bound on the delay, and no filing or rulebook states an alarm condition or an investor's position while the two books disagree.
- The UK removed the second register rather than choosing between two COLL 6 Annex 4 lets the on-chain record be the primary books and records, drops the duplicate mirror requirement and requires the responsible firm to be able to amend the register without any third party's consent and to have processes to identify incorrect entries, specifying none of them.
- Luxembourg's control agent reconciles the wrong pair of books Its statutory duty is to verify that the issuance account total equals the sum of the account keepers' securities accounts, both sides sitting inside the same ledger, which is a supply-integrity check rather than a chain against off-chain comparison, and article 9(2 bis) separately preserves the issuer's own register with no rule for divergence.
- A failed cash leg produces an error a reconciliation is structurally blind to When a securities leg confirms and the cash leg fails afterwards, both registers can agree perfectly and both be wrong, so the only signals that would surface it sit in the cash system outside either book, and no source names who watches for it or who is holder of record meanwhile.
A tokenized fund's two registers now have three published winners, and nobody says how you would know they disagree
ERC-3643, a Final Ethereum standard created on 9 July 2021, underpins most of the permissioned token infrastructure the tokenized fund market runs on. It decides who may hold a token: the identity registry, the isVerified() check and the compliance modules all answer whether a wallet is eligible. It nowhere mentions legal title, a register of members, a transfer agent or an authoritative register.
That silence is a boundary rather than an omission. A tokenized fund runs two books: the ledger the token moves on, and the shareholder register kept by a transfer agent, an authorised fund manager or the issuer. The two can disagree, and three regimes now write down which one wins. An SEC-filed prospectus supplement gives the win to the chain. A separate SEC application gives it to the off-chain register. A UK rulebook removes the second book entirely.
None of the three says how anyone learns the books diverged, on what trigger, at what cadence or where an investor stands between a bad entry and its reversal. A tie-break presumes the argument was noticed. The standard governing who may hold the token records no view on who owns the share (EIP-3643).
The claim is about what regimes, rulebooks and filed documents specify, not about whether anyone has built detection. At least one vendor already markets continuous reconciliation between an on-chain fund record and an off-chain official record, and publishes no method behind it. A real capability you buy, cannot inspect and cannot point a supervisor at is a different thing from a duty somebody wrote down.
Two SEC filings picked opposite winners, in writing
F/M Investments LLC and The RBB Fund, Inc. filed a Form 40-APP on 21 January 2026 that designates the transfer agent's Official Share Register as the authoritative shareholder record, controlling where it and the DLT Platform records disagree. It also describes reconciliations between the two and protocols for breaks. The off-chain book wins.
Dreyfus Government Cash Management Funds' Form 497 prospectus supplement, filed 29 July 2026 and covering the BLIQUID share class serviced through BNY's digital transfer agency, states that the blockchain entries constitute the transfer agent's official records of share ownership, that a duplicate off-chain record is kept as a back-up and that the two are reconciled on at least a daily basis. Where an inconsistency cannot be reconciled after investigation, the blockchain records control and the off-chain copy is adjusted to match. The on-chain book wins. BLIQUID's chains are Ethereum and Solana, used within a closed ecosystem of allow-listed wallets.
Neither filing answers the detection question. BLIQUID states a cadence, then describes discrepancy resolution as something that may require investigation and could delay transaction processing, with no method, no alarm condition and no bound on the delay. F/M describes break protocols without saying what runs them or how often. A daily floor still leaves up to a day in which the books disagree and the holder's position is unstated. Both postures were written down (F/M 40-APP; Form 497).
The SEC's own taxonomy said either winner was always available
Neither filing invented its posture. On 28 January 2026 SEC staff published a Statement on Tokenized Securities defining a tokenized security as one whose record of ownership is maintained in whole or in part on or through one or more crypto networks, then setting out the available arrangements. In the integrated model the issuer or its agent builds DLT into the master securityholder file, so a transfer of the crypto asset is the transfer of the security on that file. In the notification model the crypto asset sits outside that file and its transfer operates only to notify the issuer or its agent to record the change. Two further branches sit alongside them, third-party custodial arrangements over a security entitlement and synthetic ones built on a separate linked instrument.
BLIQUID is a live instance of the first model and F/M of the second, so the two are not a market disagreeing with itself but two firms picking different branches of a taxonomy their regulator had already written. That taxonomy names architectures and stops: no reorg, no failed settlement, no forced transfer, no lost key, no sanctions freeze. This article assumes the fund unit is already a financial instrument, and the MiCA and MiFID II classification test is where that is settled. The US posture is a published choice of model, not one mandated answer (SEC staff Statement).
The UK deleted the mirror instead of choosing which register wins
The FCA took the third route. Policy Statement PS26/7, in force 30 April 2026, inserts COLL 6 Annex 4 into the Handbook, covering registers for authorised funds maintained on distributed ledger technology. Annex 4.5G states that "the on-chain DLT record of transactions may be considered the primary books and records for this activity." Paragraph 2.17 removes the second book outright: "We have taken on board feedback and altered our guidance to confirm that firms need not maintain a duplicate ‘mirror’ of on‑chain information where our requirements are met." (PS26/7)
With one register there is no divergence to adjudicate, so the failure mode moves rather than vanishing. Annex 4.8G requires that "the responsible firm will need to ensure that it can amend that register as necessary without requiring the consent or agreement of any third party." Annex 4.13G comes closer than any source here to naming the detection problem, then leaves it open: "The responsible firm will also need to have processes and procedures in place to identify incorrect entries and take remedial action." A duty to have processes, with no cadence, method or trigger attached. Annex 4 is guidance rather than rules, 4.5G is permissive, and the instrument itself (PS26/7) reaches only UK UCITS and non-UCITS retail schemes.
Luxembourg legislated a reconciliation, and it is the wrong pair of books
Luxembourg is the instructive near-miss. The law of 20 December 2024, amending the 2013 law on dematerialized securities, created the agent de contrôle, whose duty at article 1er point 10 bis) is to "vérifier que le montant total des titres émis de chaque émission inscrit dans un compte d’émission au sein ou par le biais d’un dispositif d’enregistrement électronique sécurisé" and check it against the sum recorded in the account keepers' securities accounts, held in the same kind of device (unofficial translation). Both sides sit inside the ledger, so it is a supply-integrity check against over-issuance rather than a reconciliation between a chain and an off-chain transfer agent's book (Legilux).
There is no tie-break vocabulary in it: a search of the amending law and the consolidated 2013 text for discordance, divergence, prévaut, prime sur and fait foi returns zero in every case, and blockchain never appears. The two-register world survives anyway: new article 9(2 bis) ends "L’émetteur adapte son registre des titres nominatifs en conséquence" (unofficially, the issuer adapts its register of registered securities accordingly), preserving the issuer's own off-ledger register with a duty to update it and no rule for divergence. The role runs on a two-month prior notification to the CSSF, given by the control agent rather than the issuer, with a power to prohibit (law of 20 December 2024). So Luxembourg legislated a reconciliation of the wrong pair, and it binds Luxembourg alone.
The reconciliation duty that already bites was written without DLT in mind
CSSF Circular 22/811 requires a reconciliation between a fund's accounts and its shareholder register, without once naming DLT, blockchain or token. The duty attaches to the register, not to the medium it is kept in, so a Luxembourg fund whose shareholder register is a chain already inherits the comparison obligation. It is the one duty in this set pointed at the right pair of books.
A technology-neutral duty says the comparison must happen and leaves the fund every parameter a tokenized register needs: what counts as an entry when the register is a chain, how deeply a transfer must be confirmed before it is treated as one and how fast a break has to surface. The circular reaches Luxembourg funds and nothing else.
Nobody else has closed the question. Central Bank of Ireland Discussion Paper 12 poses it rather than settles it, an open consultation with responses due 5 June 2026 that frames the tokenized fund unit as an on-chain duplicate referencing the actual instrument off-chain. At Union level ESMA records persisting legal uncertainty about recognition of DLT transfers under settlement finality law and about cross-border enforceability of ownership records on public chains. Another asset class is surveyed in tokenized real estate regulations. That is four answers to one question, and none binds a fund outside its own perimeter.
A chain reorg leaves the register saying something the chain no longer does, and nobody says how fast that gets noticed
A transfer confirms on-chain, the transfer agent writes the off-chain register to match, then the chain reorganizes and the transaction drops back into the mempool. The register now records a transfer the chain no longer contains, and neither book knows it.
Each written tie-break produces a different consequence. Where the chain is the official record, the register entry is wrong and must be reversed, so an investor who saw a confirmed holding loses it by operation of a clause. Where the off-chain register controls, the register stands and someone must push a compensating transaction so the ledger agrees with the book that already won. Under a single-register model the reorg creates no divergence at all, it edits the register directly and the unilateral amendment power is the only remedy.
All three presuppose somebody noticed. No source in this set states a confirmation-depth threshold before the register may be written, the one parameter deciding how often this happens. Permissioning changes the odds without removing them: ESMA describes CSD Prague running a permissioned model with a closed validator set, and nowhere in that report, in PS26/7 or in either SEC filing is reorg probability stated as zero or a depth named. The FCA duty to have processes identifying incorrect entries is the closest anyone comes, and it names no cadence, method or trigger.
Nobody says who is watching when a cash leg fails after the securities leg confirms
In a delivery-versus-payment structure the legs can fail independently. The securities leg confirms on-chain, the cash leg fails afterwards and for that window somebody is holder of record for a trade that never completed. Whether they can redeem, vote or transfer meanwhile is addressed by none of the three tie-breaks: none is a rule about incomplete settlement.
ESMA records that CSD Prague is exempted from Articles 39 and 40 of CSDR and relies on functional equivalents instead, including a fallback plan to migrate to traditional book-entry or paper certificates. A regime whose stated contingency is paper has no settled answer to a partial settlement failure on a ledger.
What separates this from a reorg is that reconciliation cannot catch it. BLIQUID's daily comparison checks the blockchain records against the duplicate off-chain copy. In a failed cash leg both books can agree perfectly and both be wrong, because the register faithfully copied a securities leg that did confirm. A reconciliation between two books is blind to an error the two books share, and the signals that would surface it live in the cash system, outside both registers. No source found states who watches for that mismatch, on what trigger or who counts as holder of record while it lasts.
A written override power does not say what triggers it
The power to overwrite a holding is documented three times. ERC-1400 permits a forced transfer "to reverse fraudulent transactions, resolve lost private keys and responding to a court order" (ERC-1400, issue #1411). ERC-3643 supplies the mechanism as forcedTransfer and says nothing about its legal effect. BLIQUID's prospectus confirms the transfer agent can correct ownership records through the fund's integrated books and records system, unwinding erroneous, unauthorized and otherwise impermissible transactions. The FCA states the principle: "Under our existing framework the person responsible for the register must retain authority over it, including to process decisions of a court or to resolve consumer issues. We believe this is an important consumer and market integrity expectation, including in a tokenised setting." (PS26/7, paragraph 2.4)
None settles whether calling the function is the legally operative act. On the integrated reading the on-chain call is the act and the register amendment is its bookkeeping consequence. On the notification reading amending the register is the act and the on-chain call is a mechanical echo that can lag or fail. The direction decides which artefact a court is enforcing against.
Nothing states what evidence starts an override, who reviews it or how a wrongful invocation would be caught. A full-text search of the F/M application for the words court, forced, lost, freeze, frozen, sanction and fail returns zero occurrences of each, which is a statement about the document's vocabulary and not a finding that any obligation is absent.
A lost key can be recovered, and nobody says what evidence unlocks it or how a wrongful recovery would be caught
ERC-3643 exposes recoveryAddress(_lostWallet, _newWallet, _investorOnchainID), moving a balance from a lost wallet to a new one bound to the same on-chain identity. The function is the entire published answer: no precondition beyond the identity binding, and no record of why the call was made.
BLIQUID's prospectus is the first source found naming the scenario in binding disclosure language, listing loss or the compromise of a private key or other access credential among the events the transfer agent may act on, alongside fraud and theft. The power exists and is disclosed in advance. No evidentiary standard is stated anywhere: nothing says what an investor must produce to establish that a key is genuinely lost rather than that a wallet is being claimed by somebody else, who adjudicates it or what would surface a recovery that moved a holding to the wrong wallet.
F/M answers by removing the question. Its architecture permits only whitelisted wallets, bans self-hosted wallets and leaves intermediaries holding every private key, so there is no investor-held key to lose. That is an observed design choice with a real cost, since it reintroduces the intermediated custody chain tokenization was meant to shorten, and it is not evidence the evidentiary question was resolved elsewhere. Key custody, recovery authorization and the audit trail behind both belong in the same review as everything else in the institutional platform due-diligence checklist.
Freezing the token does not touch the register, and nobody says who checks that it should have
ERC-3643 gives a compliance operator setAddressFrozen, blocking an address from transacting, and freezePartialTokens, immobilizing part of a balance. Both act on the token. Neither writes to a shareholder register or changes who the holder of record is.
That splits along the tie-break. Under the notification model the sanctioned party stays recorded as legal holder in the authoritative book while their tokens sit immobile. Under the integrated model the frozen balance is the register entry, so the holder of record cannot move a holding they still legally own. Either way the freeze restricts transfer and leaves ownership untouched, and no source states whether that discharges the underlying obligation or merely delays a breach.
The unanswered question is who reconciles the two layers. Nothing in either SEC filing, in COLL 6 Annex 4 or in the ERC-3643 specification names the party responsible for confirming that a token freeze was matched by whatever register action the sanctions regime requires, or the reverse. A freeze applied on one layer and missed on the other is a compliance failure before it is a data problem, and it accrues to the firm that owed the control rather than to whichever register turns out to be authoritative. That split is examined more generally in what compliance can and cannot be encoded in a smart contract.
Which register each standard quietly assumes it is, and whether it could tell if that assumption broke
ERC-1400's controllerTransfer presumes an off-chain controller with legal authority to act, the notification model in a function signature. The ERC-3643 identity registry presumes that eligibility truth lives on-chain while saying nothing about where ownership truth lives, so it fits either model. ERC-1404 returns a restriction code and a human-readable reason, a detection-and-messaging interface with no opinion on ownership.
None of the three carries a divergence alarm, and that is measured rather than assumed. Searching ERC-3643 and the issue text that is the only published form of ERC-1400 and ERC-1404 for divergence, diverge, discrepancy, mismatch, reconcile, reconciliation and drift returns zero hits in all three. The event inventories agree. ERC-3643 defines 31 events, ERC-1400 defines 13 and ERC-1404 declares none of its own and carries only the two it inherits from ERC-20. Not one of those 46 reports a difference between the ledger and a record kept off it.
One near miss keeps that negative honest. ERC-1400 defines a Document event carrying a name, a URI and a document hash, together with a getDocument function. That is an anchor between the chain and a document held off it, the closest any of the three comes to acknowledging a second record. It is still not a drift detector. It pins the hash of one document and requires no comparison, so it cannot tell an integrator that a register and a ledger have parted company, and the specification itself disclaims giving an investor any way to signal on-chain about those documents.
The scope is three documents and no more, saying nothing about standards nobody searched. Within them the detection layer is unspecified, left to application code in each deployment. How ERC-3643, ERC-1400 and ERC-1404 enforce compliance, including identity and claim mechanics, is compared in RWA compliance controls.
What a fund can put in writing before any of this happens
All four decisions below are available today, and each closes a gap no filing, statute or rulebook closes for you.
- Name the tie-break in the service agreement, not just the prospectus, and name it in the direction the architecture implements. An integrated deployment whose contract says the off-chain register controls has written a clause its own code contradicts.
- State a detection cadence, not only a reconciliation cadence, and state it tighter than the daily reconciliation BLIQUID discloses. A continuous balance comparison with a defined alert threshold is a different commitment from an end-of-day run, and it is what bounds an investor's exposure window.
- Write the forced-transfer authorization chain down: what evidence opens a case, who signs off, which artefact is legally operative and what record the call leaves behind. The standards give you a function and no procedure.
- Decide the freeze-versus-register question before a sanctions listing forces it, including who confirms both layers moved together and within what time.
Not every fund is placed to write any of that. A fund buying a packaged transfer agency service from a large provider is generally taking that provider's standard terms, and a detection cadence is rarely a negotiable line in them. The realistic move there is to find out what the cadence already is and what the provider commits to once a discrepancy is found, then decide whether that is enough. Knowing the answer is worth something even where changing it is not on offer.
Each is an engineering commitment as much as a legal one: the cadence is a monitoring system, the authorization chain is a workflow ending in a signing key and the freeze reconciliation runs against two data stores never designed to be compared. Our tokenization and RWA development work builds those register and ledger paths, and our compliance and RegTech practice covers the controls layer above them.
BNY describes its own digital transfer agency this way: "Those capabilities are directly connected to the firm's underlying TA recordkeeping infrastructure, creating a trusted source of ownership and transaction data across both traditional and digital environments." (PRNewswire) One trusted source spanning two environments is a design goal, not a guarantee that the systems feeding it agree at any moment. The regimes above tell you which to believe when they do not. Finding out is yours to build.
Sources: EIP-3643 (ERC-3643 T-REX); ERC-1400, Ethereum EIPs issue #1411; ERC-1404, Ethereum EIPs issue #1404; the SEC staff Statement on Tokenized Securities of 28 January 2026; the F/M Investments and RBB Fund Form 40-APP filed 21 January 2026; the Form 497 prospectus supplement for Dreyfus Government Cash Management Funds filed 29 July 2026; the FCA's PS26/7 and the COLL 6 Annex 4 instrument inside it; the Luxembourg law of 20 December 2024 and the law of 6 April 2013 consolidated at 31 December 2024, both in French, translations here unofficial; ESMA's report on the functioning and review of the DLT Pilot Regime; Central Bank of Ireland Discussion Paper 12; CSSF Circular 22/811 as amended; and BNY's digital transfer agency announcement of 29 July 2026. Read on 27 August 2026. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 6
No matches
Try a different keyword, change the topic or clear filters
-
It depends on which regime the fund filed under, and the published answers point in opposite directions. The Form 497 prospectus supplement for Dreyfus Government Cash Management Funds, filed 29 July 2026, designates the blockchain book-entry records as the official records and states they control where an inconsistency cannot be reconciled after investigation.
The F/M Investments and RBB Fund Form 40-APP filed 21 January 2026 takes the opposite position, designating the transfer agent's Official Share Register as authoritative in any discrepancy with the DLT Platform records. Under the FCA's COLL 6 Annex 4 the question can be removed instead of answered, because the responsible firm may treat the on-chain record as the primary book and is not required to keep an off-chain mirror.
-
There is no market-wide cadence, and only one filed number is public. The Form 497 supplement for the BLIQUID share class states the transfer agent reconciles the blockchain book-entry records against the duplicate off-chain record on at least a daily basis.
F/M's application describes reconciliations and break protocols without stating a frequency. The FCA requires processes to identify incorrect entries and specifies no interval. A daily floor means up to a day can pass before a divergence is even looked for, and no source states what an investor's position is during that window.
I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.
My focus is on complex products where mistakes are costly:
- Web3 and blockchain platforms
- FinTech and regulated products
- High-load startup systems
- MVP → scale transitions
We don’t do body-shopping.
We don’t sell generic outsourcing.Instead, we help founders:
- build the right team structure from day one
- keep technical ownership and transparency
- scale delivery without losing control
- avoid vendor lock-in and hidden risks
Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.
