TARGET Services T2 – System Analysis Article Series
Part 2: System Boundary and Context Analysis
Article 5
The system boundary of T2 defines which responsibilities belong to T2 and which belong to its environment. I use this boundary to separate the T2 core from connected TARGET Services and shared infrastructure. T2 combines Central Liquidity Management (CLM) and Real-Time Gross Settlement (RTGS). Other services exchange liquidity, data, or settlement instructions with T2, but that does not make them part of T2. A clear boundary therefore keeps requirements, interfaces, ownership, and testing precise.
When I analyse payment and market infrastructure systems, I do not start with screens. I do not start with message fields. Instead, I start with scope. This matches the Certified Professional Requirements Engineer (CPRE) certificate mindset from the International Requirements Engineering Board (IREB). I clarify the system context first. Then I identify interfaces. After that, I define responsibilities. As a result, I separate “my system” from “its environment”.
Why I Define the T2 Boundary First
Before I analyse individual processes, messages, or data objects, I define the scope.
This gives me a simple question for every function I encounter:
Does T2 perform this responsibility, or does another system perform it?
That distinction matters because modern payment infrastructures rarely work in isolation. T2 exchanges information and liquidity with other TARGET Services. In addition, it uses shared infrastructure for connectivity, reference data, monitoring, and other functions.
However, an interface does not automatically extend the system boundary.
I therefore define the T2 boundary according to responsibility, not according to connectivity.
This approach helps me allocate requirements correctly. It also makes interfaces visible and prevents me from assigning external behaviour to T2.
What Belongs Inside the T2 Boundary?
At the service level, I place two main components inside T2:
- Central Liquidity Management (CLM)
- Real-Time Gross Settlement (RTGS)
The Eurosystem describes T2 as its real-time gross settlement service. Its current documentation separates the service into CLM and RTGS. CLM provides the central mechanism for managing liquidity, while RTGS processes real-time payments and ancillary system transfers.
The diagram shows the most important boundary distinction. CLM manages the central liquidity position through Main Cash Accounts. RTGS then uses dedicated accounts for payment and ancillary system settlement. Liquidity can move between these areas without leaving T2.
CLM Belongs Inside T2
I treat CLM as one of the two main responsibility areas of T2.
CLM holds the Main Cash Accounts. Participants use these accounts as their central source of liquidity. In addition, CLM supports central bank operations and credit line management. It also provides tools for steering and monitoring liquidity across TARGET Services. European Central Bank
Therefore, I place functions such as these inside the T2 boundary:
- management of Main Cash Accounts
- central bank operations
- credit line management
- liquidity monitoring
- liquidity transfer initiation
- automated liquidity management
The important point is that CLM can manage liquidity across service boundaries.
For example, a participant can transfer liquidity between an MCA and accounts used by RTGS, T2S, or TIPS. Nevertheless, this does not make T2S or TIPS part of T2.
Instead, the transfer creates an interface between different services.
T2 owns the CLM side of the interaction, while the receiving TARGET Service owns its own processing.
This distinction becomes especially useful when I specify error handling, confirmations, settlement results, and interface requirements.
RTGS Belongs Inside T2
RTGS forms the second main responsibility area.
I use RTGS for the settlement of real-time interbank payments, customer payments, and ancillary system transfers. RTGS also provides liquidity controls such as priorities, reservations, limits, and optimisation mechanisms. European Central Bank
RTGS uses Dedicated Cash Accounts, or RTGS DCAs, for settlement.
Therefore, I include within the T2 boundary:
- RTGS payment processing
- RTGS DCA management
- settlement of interbank payments
- settlement of customer payments
- ancillary system settlement
- RTGS liquidity management functions
- processing of liquidity transfers involving RTGS accounts
The boundary between CLM and RTGS remains relevant even though both belong to T2.
CLM provides the central liquidity management layer. By contrast, RTGS performs the actual settlement of the payment and ancillary system transactions assigned to it.
This internal separation helps me model responsibilities more precisely.
Other TARGET Services Stay Outside T2
The TARGET landscape now consists of several distinct services. These include T2, TARGET2-Securities (T2S), TARGET Instant Payment Settlement (TIPS), and the Eurosystem Collateral Management System (ECMS). European Central Bank
I therefore keep the following outside my T2 service boundary:
T2S handles securities settlement.
TIPS handles instant payment settlement.
ECMS manages collateral for Eurosystem credit operations.
All three can interact with T2. However, each service owns a different business responsibility.
For example, CLM can provide liquidity to accounts associated with other TARGET Services. That relationship creates a cross-service process. It does not merge the services.
A cross-system process can cross several system boundaries while each system remains independently responsible for its own part.
That principle is essential in requirements engineering.
Shared TARGET Components Need a Separate Boundary
The TARGET architecture also contains common components.
For example, the Eurosystem Single Market Infrastructure Gateway, or ESMIG, provides functions such as connectivity, authentication, security services, and message routing for different TARGET services and applications. The current Common Components requirements explicitly describe ESMIG as infrastructure that multiple services can use, including CLM, RTGS, T2S, TIPS, and ECMS. European Central Bank
In addition, RTGS interacts with shared capabilities such as Common Reference Data Management, the Data Warehouse, and Business Day Management. European Central Bank
For a service-level T2 analysis, I therefore model these components as shared dependencies rather than as part of the CLM and RTGS business core.
This distinction matters.
If I analyse the complete technical TARGET solution, I may draw a wider boundary that includes common components. However, if I analyse the T2 service and its business responsibilities, I keep CLM and RTGS at the centre and model shared components through interfaces.
Consequently, the correct boundary always depends on the purpose of the analysis.
Accounts Help Me Recognise the Boundary
The account structure provides another useful way to understand T2.
CLM contains the Main Cash Account. The MCA acts as the central liquidity source.
RTGS contains Dedicated Cash Accounts for real-time settlement. In addition, RTGS supports accounts used for ancillary system settlement.
Liquidity transfers connect these account types.
Therefore, I can read the architecture from the accounts:
MCA points me toward CLM.
RTGS DCA points me toward RTGS.
T2S and TIPS accounts point me toward other TARGET Services.
This method does not replace a formal boundary analysis. However, it gives me a fast way to orient myself in complex process and message documentation.
Why the Boundary Matters for Requirements
Once I know the system boundary, I can write better requirements.
For every interaction, I can identify three elements:
- What T2 must do.
- What an external system must do.
- What the interface must guarantee.
For example, I should not write a T2 requirement that tells TIPS how to settle an instant payment. Instead, I specify what T2 sends, what response T2 expects, and how T2 reacts to that response.
Likewise, I do not assign ESMIG routing behaviour to RTGS simply because RTGS messages pass through ESMIG.
As a result, the boundary directly improves requirement allocation, interface specifications, testing, incident analysis, and change impact assessment.
My T2 Boundary Model
For a service-level system analysis, I use the following boundary:
Inside T2, I place CLM and RTGS together with the business functions and account structures that they own.
Outside the T2 core, I place other TARGET Services such as T2S, TIPS, and ECMS.
I also distinguish shared TARGET infrastructure, such as ESMIG and common components, from the CLM and RTGS business core.
Between these areas, I model explicit interfaces for liquidity, messages, data, and operational dependencies.
This gives me a boundary that remains simple without hiding the complexity of the TARGET architecture.
Conclusion
The system boundary of T2 becomes clear once I focus on responsibility.
T2 combines CLM and RTGS. CLM manages central liquidity through Main Cash Accounts. RTGS settles real-time payments and ancillary system transactions through its dedicated accounts. Other TARGET Services remain separate even when liquidity or information crosses between them.
At the same time, common components support T2 and several other services. Therefore, I distinguish them from the T2 business core when I create a service-level system model.
This boundary gives me the foundation for analysing T2 processes, interfaces, requirements, and responsibilities without mixing the system with its environment.
For more content and documents, consult the European Central Bank’s pages on TARGET Services.
Credits: The images are from iso 20022 payments.com.