Insights
The Settlement Clock Behind a 24/7 Token
Pontes connects tokenised wholesale transactions with central bank money, but a settlement process still has a calendar, a cash leg and defined completion points. Its published pilot design makes the distinction concrete: technical access to a token and the ability to complete the intended exchange are different operational questions.
A buyer and seller can agree a tokenised securities trade while the network carrying the asset remains available around the clock. Completing the intended exchange also requires a payment arrangement, available liquidity and the relevant settlement process. Those dependencies become particularly visible when the asset platform connects to a cash system with a defined operating day.
The Eurosystem launched Pontes on 21 September 2026 to enable wholesale tokenised-asset transactions to settle in central bank money. The ECB described an initial set of services, with additional features and longer hours to follow gradually and full implementation expected by 2028. That announcement establishes a staged launch, rather than a promise that every component of a tokenised transaction is continuously available. ECB launch announcement
For an asset manager, the practical question is what has to be available at the intended settlement time. Network uptime describes one part of that answer. The payment calendar, the parties' funding arrangements and the evidence that the exchange completed describe other parts. A transaction record becomes more useful when it preserves each of them.
Read the settlement window with its document and calendar
The ECB's Pontes Pilot Business Description Document, version 1.0 dated 3 February 2026, specifies settlement in line with the T2 RTGS euro calendar and a window from 09:00 to 16:00 CET. This is the published pilot design used for the example here; exact live cut-offs, exceptions and later changes need the current operator documentation. Pilot BDD, section 3.4, page 14
Settlement window
09:00–16:00 CET
Specified in Pontes Pilot BDD v1.0, dated 3 February 2026. Check current operator documentation for live cut-offs and changes.
Operating days
T2 RTGS euro calendar
The same pilot document ties settlement availability to this calendar. A continuously available asset network does not replace it.
The distinction matters before anyone sends an instruction. A trade agreed late in the day may depend on whether the relevant processing window remains open, whether funding can arrive and whether both parties can complete their operational steps. Putting an earlier timestamp on a blockchain does not resolve those dependencies. Nor should an application silently assume that an instruction submitted outside a window will be carried into the next one under unchanged conditions.
A useful hypothetical is a trade prepared on a Saturday. The asset platform may accept instructions, while the parties intend to use a cash-settlement arrangement governed by a business-day calendar. The review needs to identify how the transaction will wait, which conditions remain valid and what evidence will establish completion when processing resumes. This illustration describes a question to resolve under the applicable arrangements; it is not a statement about Pontes's handling of every out-of-hours instruction.
Coordinate the asset and the payment
Pontes links market distributed-ledger platforms with TARGET Services. The ECB's design overview describes two settlement models and an all-or-none mechanism for delivery-versus-payment transactions across platforms. It also places final cash settlement in central bank money at completion of the corresponding transaction in T2. ECB Pontes design overview
Delivery versus payment, usually shortened to DvP, links delivery of the asset with the associated payment. Its practical purpose is to make the exchange depend on the required conditions being met. The operations team still needs to know which arrangement applies to the trade, which party must fund it and which confirmations demonstrate that the intended process completed.
| Part of the transaction | Operational question | Relevant evidence to retain |
|---|---|---|
| Asset leg | Which instrument and amount are to be delivered? | Applicable terms, asset reference and delivery instruction. |
| Cash leg | Which currency, payment arrangement and funding are required? | Payment terms, funding basis and the applicable calendar. |
| Coordination | What links the two movements? | The agreed settlement model and its completion conditions. |
| Completion | What actually happened, and when? | The relevant asset and cash confirmations and unresolved exceptions. |
The table is a review framework, not a list of literal Pontes message states. It helps separate preparation from outcome. An instruction can be complete enough to submit while the transaction still awaits processing, and a technical acknowledgement can confirm receipt without answering every question about completion.
Legal conclusions also need their proper scope. The ECB's description of the cash leg does not establish ownership of every security that might be represented on a market platform. Instrument terms, the relevant system rules and applicable law remain part of that assessment. A review should preserve the confirmations and governing basis rather than treating a generic transfer flag as a universal legal answer.
Liquidity and exceptions remain operational work
When two systems have different availability, the preparation of a trade needs to account for the tighter dependency. A party may be ready to deliver an asset but still need to arrange cash in time. Conversely, committing cash before the asset is ready can create a different operational problem. The relevant team needs to understand those conditions before scheduling the exchange.
There is also a difference between the planned workflow and the handling of an exception. A delay, an unmatched instruction or a missing confirmation needs an agreed response. Who investigates, what can still be changed and whether a new instruction is required should follow the applicable rules. A continuously available interface can be helpful, but it cannot supply an operational decision that the underlying arrangements leave unresolved.
This is where clear records provide practical value. The trade terms explain what was intended; the instructions explain what was requested; the confirmations explain what was completed. Keeping the sequence makes it possible to investigate a delay without replacing the original expectation with the final outcome. It also reduces the risk of treating a resubmitted instruction as a second independent trade.
Longer hours will change the workflow, not remove the need to understand it
The launch announcement's plan to extend services and hours is relevant to adoption, but a roadmap is a dated expectation. Teams preparing a transaction need the capabilities and rules available for that transaction. Future availability should enter planning as a dependency to verify, rather than as an assumption silently carried into today's settlement instructions. ECB's staged implementation announcement
Longer cash-settlement hours could make more trading times practical, while also changing staffing, liquidity and exception-management requirements. An organization would still need to decide how its own operations cover the available window. Continuous system access and continuous readiness inside every participating institution are separate operational matters.
Pontes is therefore a useful case for reading tokenisation through the whole transaction. The asset's technical availability, the cash calendar and the completion evidence belong in the same operational view, with each retaining its meaning. That gives a buyer, seller or operations team a clearer basis for deciding when a proposed trade can actually be completed.