Originally published on Medium.
The interesting thing about putting traditional financial assets on-chain is not the token.
It is the record.
Nasdaq's approach to tokenized securities makes that distinction unusually clear.
Traditional and tokenized shares can participate in the same market structure with the same execution priority and underlying rights. The asset does not become economically different because one representation eventually settles through blockchain infrastructure.
That is the useful design principle.
Do not rebuild the asset around crypto.
Make the financial state machine-readable.
We have been applying the same idea to a much less liquid market: Canadian private mortgages.
A Mortgage Book Is Mostly a Data Problem
A private mortgage looks simple when viewed one loan at a time.
A borrower owes principal.
The loan has a rate.
There is collateral.
Payments arrive.
Eventually the mortgage matures, renews, gets paid off, is extended, or defaults.
The complexity appears when those loans become a portfolio.
Now you have dozens or hundreds of maturity dates, different lien positions, changes to principal, renewals, partial payments, extensions, servicing events, appraisals, investor positions, and cash movements.
And almost none of those systems were designed to share a common record.
The legal documents know one part of the truth.
The servicer knows another.
The bank account knows which cash actually moved.
A portfolio spreadsheet contains someone's latest interpretation of all of it.
Investors typically receive a projection of that state through reporting.
The problem is not that the spreadsheet is necessarily wrong.
The problem is that the spreadsheet is the thing you are being asked to trust.
Turn Each Mortgage Into an Object
Our approach is to give each mortgage a persistent machine-readable representation.
Not the borrower's identity.
Not their home address.
Not their credit file.
The financial state.
For a mortgage, that means fields such as balance, rate, term, lien rank, current status, payment events, and maturity.
Those fields form the public or permissioned financial object that systems can reason about.
Sensitive source material remains off-chain.
Borrower identity, property address, appraisal documents, and credit files do not belong on a public ledger. Instead, the system can retain those records in the appropriate controlled environment and anchor them cryptographically to the on-chain object.
The blockchain is therefore not the document store.
It is the integrity layer.
If an appraisal changes, the system can establish which appraisal informed which state of the mortgage.
If a term changes, that change becomes an event rather than a cell silently receiving a new value.
If a balance changes, its history remains reconstructable.
That is a much more useful definition of a "digital twin" than simply minting a token with an asset name attached to it.
The Token and the Digital Twin Are Different Things
This distinction gets blurred constantly in RWA architecture.
A token represents a position, entitlement, claim, or transferable unit.
A digital twin represents state.
You can have a token without a trustworthy digital twin.
In fact, many tokenized assets work exactly that way. The token exists on-chain, while the information necessary to understand what backs it still lives in PDFs, spreadsheets, administrators' systems, and periodic reports.
That improves distribution.
It does not necessarily improve verification.
For private credit, we think the state layer is at least as important as the ownership layer.
If an investor owns exposure to a pool of mortgages, the valuable question is not merely, "How many tokens do I own?"
It is, "What does the pool contain right now?"
Maturity Is a Good Example
Suppose a portfolio has mortgages maturing across September, October, November, December, January, and February.
A conventional report might show the amount maturing each month.
Useful.
But October arrives and the portfolio starts changing.
Mortgage 0007 renews.
Mortgage 0012 renews.
Mortgage 0015 pays off.
Mortgage 0019 renews.
Mortgage 0023 is extended.
The original maturity chart is no longer the whole story.
The important data is the transition.
A mortgage moved from one state to another, for a reason, at a point in time.
That is how we model the book.
The current portfolio becomes a projection of its history rather than a spreadsheet that overwrites its history.
Once the distinction is made, reporting gets much more interesting.
You can ask what the portfolio looks like today.
You can also ask what it looked like thirty days ago.
Which loans renewed?
Which paid down?
Which maturities were extended?
How much principal was expected to roll and how much actually rolled?
Those become queries instead of reconstruction exercises.
Three Systems Know Different Parts of the Truth
Putting data on-chain does not make the physical world disappear.
A blockchain cannot determine whether a borrower actually wired money into a bank account.
It cannot independently appraise a house.
It cannot decide whether the person behind a wallet passed KYC.
So we do not pretend one database is authoritative for everything.
Identity infrastructure is authoritative for identity.
The bank is authoritative for cash.
The blockchain is authoritative for immutable financial history.
The important layer is reconciliation between them.
Suppose the mortgage system expects a $20,000 payment.
If the bank confirms $20,000, the cash event reconciles.
If the bank confirms $19,800, the system has an exception.
If nothing arrives, absence itself becomes detectable.
That last case matters.
Most reporting systems are good at recording things that happened.
Financial control systems also need to identify things that were supposed to happen and did not.
Why Not Just Use a Database?
You should, when a database solves the problem.
If one company owns the system, controls every write, and every participant is comfortable trusting that company as the definitive historian, PostgreSQL is excellent technology.
Blockchains become interesting when the trust topology changes.
A mortgage portfolio can involve borrowers, originators, servicers, administrators, lenders, investors, auditors, custodians, banks, and eventually secondary-market counterparties.
Those parties do not all have the same incentives.
They do not all operate the same systems.
And they should not need to grant one participant unilateral power to rewrite the shared history.
The chain is useful because it gives those parties a common event record.
Not a common opinion.
A common record.
That difference is why we are interested in the technology.
The Nasdaq Analogy Is About Preservation, Not Reinvention
Nasdaq did not decide that tokenized shares should become economically different products with a completely separate market structure.
Its framework preserves the underlying security, its rights, its symbol, and its execution priority.
Tokenization changes how the position can be represented and settled.
That is a far more important precedent for real-world assets than the idea of creating thousands of synthetic wrappers.
The best tokenization architecture should preserve the legal and economic object while improving the infrastructure around it.
For mortgages, that means the loan is still a mortgage.
The lien still exists in the legal system.
The property still exists off-chain.
The borrower still pays through real banking rails.
The appraisal still comes from an appraisal process.
What changes is our ability to maintain a shared, verifiable representation of what happened.
What Goes On-Chain Matters as Much as What Stays Off
"Put it on-chain" is not a data architecture.
There are fields that benefit from immutable history and fields that create needless privacy exposure if published.
The line should be drawn intentionally.
Financial state is useful to expose or permission: outstanding balance, coupon, term, lien position, payment status, maturity, and state transitions.
Personally identifiable and source-document data should remain in controlled systems: borrower identity, addresses, credit files, appraisal documents, and similar records.
Cryptographic commitments connect the two.
This gives an investor a way to establish that a source document corresponds to the state that was represented without turning a blockchain into a permanent database of borrower information.
Privacy and transparency are not opposites.
The system simply has to be transparent about the right things.
Tokenization Does Not Fix Credit
None of this makes a bad mortgage good.
Putting a loan on-chain does not improve the borrower's ability to repay.
It does not increase the collateral value.
It does not replace underwriting.
It does not eliminate servicing risk.
It does not make legal enforcement automatic.
And it does not make an appraisal correct.
That is why the "tokenization creates better assets" argument is weak.
The asset keeps its credit characteristics.
What can improve is the infrastructure around the asset.
Ownership records can become easier to reconcile.
Portfolio changes can become visible sooner.
Historical state can become harder to manipulate retroactively.
Servicing events can be represented consistently.
Investor reporting can be generated directly from the underlying event history.
Auditors can inspect the same record the product uses.
Software can consume the portfolio without somebody emailing it a spreadsheet first.
That is the value proposition.
From Periodic Disclosure to Continuous State
Private-market reporting has historically been document-shaped.
Monthly package.
Quarterly report.
Annual audit.
Those documents are snapshots.
Between snapshots, the portfolio continues moving.
Loans pay.
Loans miss payments.
Balances change.
Maturities approach.
Terms are modified.
Collateral values change.
A machine-readable mortgage book turns reporting into a view over live state.
The quarterly report does not disappear.
It becomes reproducible.
That is a much stronger property.
Two analysts using the same state and the same rules should be able to reproduce the same portfolio view independently.
An investor does not have to trust that a PDF faithfully summarizes the source system.
The source system can be inspected.
The Bigger Opportunity Is Machine-Readable Credit
The reason this becomes more interesting now is that investors will not be the only consumers of these records.
Software will be.
Risk engines can evaluate portfolio drift continuously.
Treasury systems can model expected cash flows from actual maturity state.
Compliance systems can gate access based on structured rules.
Agents can rebalance exposure or flag servicing exceptions.
Auditors can verify event histories programmatically.
None of that works particularly well when the canonical representation of the asset is a PDF attachment.
The real infrastructure shift is therefore not "mortgages as tokens."
It is mortgages as programmable financial objects.
The Spreadsheet Was Never the Asset
A mortgage does not become more real because it is in a spreadsheet.
And it does not become more real because it is on a blockchain.
The mortgage is real because a legal agreement, a borrower obligation, and collateral exist outside the software.
The software's job is to represent that reality faithfully.
For decades, private markets have accepted infrastructure where understanding the current state of an asset often requires trusting an administrator, reconciling several systems, or waiting for the next report.
We can do better than that.
Nasdaq's move toward tokenized settlement is interesting because it does not require pretending traditional finance was wrong about what the asset is.
It asks whether the rails can improve.
That is the same question we are asking with private mortgages.
Keep the mortgage.
Keep the legal structure.
Keep sensitive information where it belongs.
Make the financial state machine-readable, reconcile it to the real world, and give every authorized participant the ability to verify the history for themselves.
That is the part of tokenization worth building.