From Monolith to Modular: How CSDs Are Rethinking Infrastructure for Changing Markets

This content is adapted from an article authored by Nasdaq’s Gerard Smith and which appears fully in Volume 18 Number 3 of Journal of Securities Operations & Custody (JSOC), published by Henry Stewart Publications (which owns the copyright) and Simon Beckett.

Settlement cycle compression, expanding data requirements and the growth of digital asset classes have brought central securities depository (CSD) infrastructure into focus. As market operators assess their technology, aging legacy systems have come under review as modern markets call for agility, innovation, transparency and network orchestration.

But how are CSDs strategizing the resilience and evolution of core functions including settlement, custody, asset servicing and governance?

The practical implication is a shift from monolithic platforms toward architectures that is more adaptable, scalable and resilient to meet evolving market and regulatory requirements.

Here’s a look at the convergence of forces shaping CSD infrastructure decisions and how the strategic implications are unfolding for cloud-enabled architecture, modularity, digital assets, data and the road to AI.
 

CSD's obligations span settlement of securities transactions against cash to achieve delivery-versus-payment (DvP), maintenance of a definitive book-entry custody record, administration of lifecycle events including income payments and corporate actions, issuance and registrar services, and collateral and pledge controls.

The settlement workflow in particular requires high straight-through processing rates (STP), bounded latency under peak volumes and compressed cycles, deterministic finality and the capacity to contain and recycle exceptions without compromising accuracy. These requirements motivate a multi-tier architecture with clear separation of concerns, stable interfaces and crosscutting controls.
 

Traditional CSD platforms can be described as monolithic systems: Tightly integrated transaction engines and servicing modules on mainframe or high-end UNIX infrastructure, typically written in COBOL or C/C++.

The constraint is that tight coupling makes incremental change difficult: modifying one component carries implications for others, capacity expansion is limited to hardware upgrades rather than distributed scaling. As change accelerates, the accumulation of technical debt increases and potentially exposes inefficiencies and rigidity.

Modular architectures address this by separating system functions into discrete, bounded-context services—validation and matching pipelines, reservation management, DvP coordination, servicing engines, analytics and integration gateways—each operating independently within a coherent overall workflow. Stable, versioned interfaces using standard protocols such as REST or gRPC allow each service to evolve on its own timeline without disrupting the rest of the system, support horizontal scaling at the edges and accommodate client-specific extensions at service boundaries.
 

Cloud hosting and containerized deployment patterns complement modular system design. Rather than pursuing full public-cloud migration, CSDs are increasingly exploring private or hybrid-cloud configurations that allow them to retain control over critical processes while benefiting from elastic scaling and distributed resilience. 

Containerization allows discrete components, such as settlement engines, registry modules and messaging interfaces, to be deployed and updated independently, enabling targeted resource allocation and reducing the risk of system-wide regression during updates.

Adoption, however, remains measured. Data residency obligations, supervisory access protocols and legal finality requirements vary across jurisdictions and may restrict where ledger maintenance, settlement processing and related functions can be hosted. Hybrid models retaining on-premises components alongside cloud-hosted services are also being considered for disaster recovery contingency. The design question is not whether CSDs can move to the cloud than which functions can be hosted, replicated or orchestrated in a manner consistent with jurisdictional expectations.
 

Tokenized securities, stablecoins, programmable instruments and synthetic exposures are creating new requirements for post-trade infrastructure. The challenge for CSDs is how to support these asset types alongside existing ones while preserving finality, auditability and regulatory alignment. Digital assets are issued, traded and serviced across heterogeneous platforms, and connectivity requires standardized protocols, canonical data models and secure messaging frameworks.

Legal finality is non-negotiable to institutionalizing and scaling digital assets. Administrative controls including freeze, quarantine and reversal mechanisms should be embedded in the transaction lifecycle regardless of whether assets are serviced through centralized APIs or permissioned ledgers. The integration of digital assets is a matter of architectural extension: The benefits of programmability and cross-entity coordination are realized only when layered behind stable interfaces and governed by institutional policy. Overlay architectures, in which tokenized representations coexist with canonical records, allow for incremental adoption and continuous reconciliation during the transition.
 

Well-structured, high-quality data provides the foundation for AI applications within CSD operations. AI models can assist with exception triage, gridlock prediction and performance analytics, but deployment needs to be appropriately scoped and supported by verifiable, structured data. Explainability, override mechanisms and auditability are relevant wherever model outputs intersect with regulated processes.

Jurisdictional compliance adds further complexity. Model hosting should conform to approved regional boundaries, and supervisory authorities may require visibility into model behavior, training data provenance and inference logic. Infrastructure needs to be able to support auditability at the model level, including traceable lineage from input data through transformation pipelines to output decisions. Governance- and compliance-by-design means regulatory logic is embedded directly into transaction workflows, data pipelines and orchestration layers rather than applied as a subsequent layer. 
 

Technical modernization at a CSD requires coordination across risk, compliance, legal and operational functions, supported by organizational cultures that value transparency, shared accountability and continuous learning. Regulators benefit from early engagement; stakeholders across the institution require consistent visibility as changes are sequenced and implemented.

The goal is infrastructure that is extensible, interpretable and resilient, built on the principles of market integrity, legal certainty and operational continuity that define the function of a central securities depository, and capable of supporting the demands that continued market development will place on post-trade infrastructure.
 

Discover How Nasdaq Financial Technology Empowers Over 3,800 Leading Finance Organizations

We are committed to helping market operators and participants overcome infrastructure, operational and regulatory challenges. Our solutions empower you to focus on your core competencies, driving market growth and progress.

Learn More
 

_{Information set forth in this post contains forward-looking statements. Nasdaq cautions readers that any forward-looking information is not a guarantee of future performance and that actual results could differ from those contained in the forward-looking information. Forward-looking statements can be identified by words such as “will,” “believe” and other words and terms of similar meaning. Forward-looking statements involve a number of risks, uncertainties or other factors beyond Nasdaq’s control. Nasdaq Eqlipse, Nasdaq Trade Surveillance, Nasdaq AxiomSL and Nasdaq Calypso are products of Nasdaq’s Financial Technology business and is operationally independent and distinct from The Nasdaq Stock Market, LLC.}

_{© 2026 Nasdaq, Inc. The Nasdaq logo and the Nasdaq ‘ribbon’ logo are the registered and unregistered trademarks, or service marks, of Nasdaq, Inc. in the U.S. and other countries. All rights reserved. This communication and the content found by following any link herein are being provided to you by Nasdaq Financial Technology, a business of Nasdaq, Inc. and certain of its subsidiaries (collectively, “Nasdaq”), for informational purposes only. Nothing herein shall constitute a recommendation, solicitation, invitation, inducement, promotion, or offer for the purchase or sale of any investment product, nor shall this material be construed in any way as investment, legal, or tax advice, or as a recommendation, reference, or endorsement by Nasdaq. Nasdaq makes no representation or warranty with respect to this communication or such content and expressly disclaims any implied warranty under law. At the time of publication, the information herein was believed to be accurate, however, such information is subject to change without notice. This information is not directed or intended for distribution to, or use by, any citizen or resident of, or otherwise located in, any jurisdiction where such distribution or use would be contrary to any law or regulation or which would subject Nasdaq to any registration or licensing requirements or any other liability within such jurisdiction. By reviewing this material, you acknowledge that neither Nasdaq nor any of its third-party providers shall under any circumstance be liable for any lost profits or lost opportunity, direct, indirect, special, consequential, incidental, or punitive damages whatsoever, even if Nasdaq or its third-party providers have been advised of the possibility of such damages.}

_{© 2026 Nasdaq, Inc. All rights reserved.}

https://www.nasdaq.com/legal