Trading Is Not Settlement: The Infrastructure Behind a Market Transaction

A buyer and seller may agree on an asset, a price and a date. A platform may display the transaction as matched or executed. Money may even have been instructed for payment.

None of those facts, by itself, proves that the asset or right has been transferred, that payment is final or that the correct authoritative record has been updated.

Financial markets separate these functions for a reason. Trading, clearing, settlement, record-keeping, payments and messaging address different risks. Treating them as one process can create false confidence about what has actually happened.

Key point: A trade records an agreement to transact. Settlement completes the resulting obligations through the required transfer of the asset or right and, where applicable, the corresponding payment.

One transaction can involve several distinct functions

The exact structure depends on the asset, jurisdiction and market. Not every transaction uses every type of institution, but the functions should still be distinguished.

The same organisation may perform more than one function. A market may also use bilateral arrangements instead of a central infrastructure. That does not remove the need to identify which record, act or system completes each obligation.

1. Trading creates the transaction obligation

Trading is the point at which parties agree—or a venue matches—the commercial terms of a transaction. Depending on the market, the trade record may include:

• the buyer and seller;
• the asset and quantity;
• the price and currency;
• the intended settlement date;
• conditions or contingencies;
• fees and taxes; and
• the accounts, agents or intermediaries involved.

Execution is important evidence of what the parties agreed. It is not necessarily evidence that either party has completed what it promised.

This distinction is easy to see in everyday commerce. Signing an agreement to purchase property does not itself update the land register. Agreeing to buy a receivable does not itself establish that all assignment requirements have been met. Accepting an offer for an intellectual-property licence does not itself prove that the relevant licence has taken effect.

The trade and the completion mechanism are connected, but they are not the same event.

2. Clearing determines what must be settled

After execution, the parties' obligations may need to be confirmed, calculated and prepared for settlement. This can involve:

• validating and matching trade details;
• calculating amounts and settlement instructions;
• netting multiple obligations where the applicable arrangement permits it;
• managing collateral or margin;
• applying risk limits; and
• using a central counterparty in markets where one is present.

Not every asset or bilateral transaction is centrally cleared. Even where clearing occurs, it does not mean that the asset and money have already changed hands. Clearing establishes or manages the obligations that settlement must complete.

3. Settlement completes the asset-side obligation

Settlement concerns the performance of the obligations created by the transaction. On the asset side, this may require a book-entry transfer, an assignment, a registry update, control of an authoritative electronic record, delivery of an instrument or another legally recognised act.

For traditional securities, central securities depositories and securities settlement systems provide defined post-trade functions. The international Principles for Financial Market Infrastructures address payment systems, central securities depositories, securities settlement systems, central counterparties and trade repositories as distinct forms of infrastructure.

In the EU, the Central Securities Depositories Regulation establishes requirements for CSDs and securities settlement systems and addresses settlement discipline. It does not mean that every contract, claim or other transferable right is a security eligible for CSD settlement. ESMA's overview of central securities depositories provides further background.

For a non-securitised asset, the legally relevant completion step may be outside securities infrastructure. The parties may instead need to satisfy contractual formalities, obtain consent, give notice, execute an assignment or novation, update an official or specialist register, and preserve evidence of the completed transfer.

4. Payment and asset transfer must be coordinated

If the buyer pays first but the asset is not delivered, the buyer is exposed. If the seller delivers first but payment does not arrive, the seller is exposed.

Securities markets can reduce this principal risk through delivery versus payment, or DvP. The asset transfer occurs if—and only if—the corresponding payment occurs. TARGET2-Securities is an example of infrastructure that enables securities and cash to be exchanged simultaneously on a DvP basis. The European Central Bank explains T2S as a securities settlement platform, while other TARGET services perform different functions, including payment settlement.

Non-traditional assets may not have access to the same infrastructure or may require different legal completion steps. Calling a workflow “atomic” does not, on its own, resolve whether:

• the seller had title or authority;
• the right was legally transferable;
• required consent or notice was completed;
• an official register needed to be updated;
• the cash transfer is irrevocable;
• the asset transfer is effective against third parties; or
• insolvency or mandatory-law rules can affect the result.

Technical coordination is valuable, but legal and operational finality depend on the applicable system, records, rules and law.

5. The authoritative record matters

Every market needs a reliable answer to a basic question: which record determines who holds the asset or right?

Depending on the asset, that answer might involve:

• a CSD or securities account;
• a land, company, vehicle or intellectual-property register;
• an authoritative electronic record maintained under a defined legal framework;
• a contractual register or servicing ledger;
• an executed assignment and notice package;
• possession or control of a recognised document or instrument; or
• several records that must be reconciled.

A marketplace database can record that a transaction was agreed. Unless the applicable arrangements give that database the necessary legal and operational effect, its entry does not automatically replace the authoritative ownership record.

The same caution applies to blockchain records. A ledger can preserve transaction data and make changes traceable, but the legal effect still depends on what the ledger represents, who controls it, which rules apply and whether external records or formalities remain necessary.

6. Messaging carries instructions—it does not complete them

Financial institutions and infrastructures need secure, standardised ways to exchange instructions and status information. Messaging networks, APIs and message brokers can help systems communicate reliably.

But a successfully delivered message is not the same as a successfully settled transaction. The message may still be rejected, unmatched, held for review or fail because of insufficient cash, missing assets, incorrect reference data or another restriction.

SWIFT describes itself as a secure messaging system and explains that it does not itself move money; the actual funds transfer takes place through banks and other institutions. SWIFT: Who we are

The same principle applies to internal technical tools. A message broker can route an instruction between applications, retry delivery and record technical status. It does not by itself:

• hold money or assets;
• verify legal title;
• provide regulatory authorisation;
• create an assignment or security interest;
• update an external official register;
• determine settlement finality; or
• guarantee that the recipient completed the instruction.

Good infrastructure therefore separates at least three statuses: message delivered, instruction accepted and transaction settled.

Why a matched trade can still fail

A transaction can be commercially agreed but remain unsettled because:

• the parties submitted inconsistent instructions;
• the asset description or identifier does not match;
• the seller does not have the required asset or authority;
• the buyer does not have sufficient cleared funds;
• a transfer restriction, consent requirement or compliance hold applies;
• the intended account or register is incorrect;
• required tax, fee or corporate-action information is missing;
• an intermediary or infrastructure rejects the instruction;
• a deadline or settlement window is missed; or
• one completed step is not reconciled with another.

These are not merely technical inconveniences. A settlement failure can affect credit exposure, liquidity, ownership evidence, regulatory reporting and the ability to use or resell the asset.

What changes for contract-backed and non-traditional assets?

For a listed security, much of the market infrastructure and data model already exists. A contract-backed right, claim, licence or other non-traditional asset may begin as an inconsistent collection of documents instead.

Before any transaction workflow can be credible, the participants may need to determine:

1. Asset definition — What exact right or interest is being transferred?
2. Source evidence — Which agreement, document, register or event created it?
3. Current holder — Who owns or controls it, and what supports the chain of title?
4. Legal status — Is the right current, conditional, disputed, expired or already performed?
5. Transfer requirements — Do assignment restrictions, consent, notice or formalities apply?
6. Competing interests — Has the right already been assigned, charged, licensed or otherwise encumbered?
7. Transaction mechanism — Which documents and actions create the intended transfer?
8. Payment mechanism — How and when will payment become final?
9. Authoritative update — Which record must change, and who is authorised to change it?
10. Post-transaction evidence — What will show that both sides completed their obligations?

If these questions remain unanswered, adding a trading screen does not create a functioning market. It creates a place to agree transactions whose completion may still be uncertain.

The missing information layer before execution

Non-traditional assets often need preparation before they can enter a controlled transaction process. Documents must be collected, relevant information structured, parties and roles identified, restrictions made visible and uncertainties disclosed.

An Asset Passport can support that preparation by organising available evidence around the asset or right. It can help an authorised reviewer understand:

• what the proposed asset is;
• which documents support it;
• who the stated parties and holder are;
• which amounts, dates and obligations are recorded;
• which transfer or disclosure restrictions may require review;
• which information has been reviewed or remains unconfirmed; and
• what is missing before a possible transaction.

This is not settlement. It is the information layer that can make later legal, commercial, compliance and operational decisions more informed.

What DaDepo does—and does not do

DaDepo is designed to help turn fragmented asset documents into structured, traceable information and a reviewable Asset Passport. It can support controlled disclosure, transaction preparation and future interoperability with authorised participants and external systems.

This separation of functions is practical for the DaDepo team. Its earlier market-infrastructure experience includes ExecExchange using DEPEND CSD technology, where the trading environment and depository technology performed connected but distinct roles.

Unless a specific service expressly states otherwise, creating, reviewing or sharing an Asset Passport through DaDepo does not mean that DaDepo has:

• operated a securities exchange, multilateral trading facility or other regulated trading venue;
• cleared a transaction or acted as a central counterparty;
• acted as a CSD, securities settlement system, payment system, bank, custodian or escrow agent;
• transferred legal title or updated an official ownership register;
• moved, safeguarded or controlled client money or financial instruments;
• completed assignment, novation, consent, notice or registration requirements;
• confirmed that a transaction is legally final or effective against third parties;
• authenticated every document, signature or external record;
• guaranteed execution, settlement, payment, liquidity or enforceability; or
• determined the legal or regulatory classification of an asset or transaction.

Important: DaDepo provides technology and information tools. It does not provide legal, financial, investment, tax, accounting, payment, settlement, custody, regulatory or valuation advice. The relevant parties, infrastructures and professional advisers must determine the requirements and completion status of each transaction.

A practical transaction-readiness checklist

Before describing a transaction process as ready, ask:

1. Execution: What event proves that the parties agreed the transaction?
2. Obligations: What must each party deliver, pay or do?
3. Authority: Does each party have the capacity and authority to perform?
4. Asset record: Which record or document establishes the current holder?
5. Restrictions: Which consents, notices, approvals or filings are required?
6. Asset settlement: What act transfers the asset or right?
7. Cash settlement: Through which accounts or system does payment become final?
8. Coordination: How is delivery linked to payment, and what happens if one side fails?
9. Messaging: How are instructions, acknowledgements, rejections and status changes distinguished?
10. Reconciliation: How are the trade record, payment record and authoritative asset record compared?
11. Evidence: What records demonstrate completion and preserve the audit trail?
12. Exceptions: Who handles disputes, reversals, failed settlement and incorrect data?

The answers may involve several organisations and systems. What matters is not presenting them as one platform, but making each responsibility and completion event explicit.

Markets need connections—not blurred responsibilities

A market transaction is a sequence of connected decisions, records and transfers. Trading determines the agreement. Clearing prepares or manages the resulting obligations. Settlement completes them. Payment systems move money. Depositories and other authoritative registers record assets or rights. Messaging connects participants without replacing their legal and operational responsibilities.

For non-traditional assets, the first missing component is often not a faster trading engine. It is a reliable, structured account of the asset, its evidence, its holder, its restrictions and the steps required for a valid transfer.

Building that information layer does not eliminate the rest of the market infrastructure. It makes responsible connection to that infrastructure possible.

Further reading

• CPMI-IOSCO: Principles for Financial Market Infrastructures
• European Central Bank: What is TARGET2-Securities?
• ESMA: Central Securities Depositories
• SWIFT: Who we are