TARGET Services T2 – System Analysis Article Series
Part 2: System Boundary and Context Analysis
Article 5
I define the T2 system boundary with a clear, CPRE-style scope cut. I place CLM and RTGS inside T2, because they form the T2 Service core. Then I keep connected systems outside on purpose, even if liquidity and messages flow constantly. This way, I prevent scope creep. Moreover, I write requirements with stable ownership and test scope.
Why I start with a boundary before I start with details
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”.
In practice, this boundary becomes my anchor for:
- requirement allocation
- interface ownership
- test scope
- incident responsibility
- change impact analysis
Therefore, I treat the boundary as a product decision, not as a drawing exercise.
T2 in one sentence
The TARGET operating schedule defines T2 clearly: T2 is a TARGET Service composed of Central Liquidity Management and Real-Time Gross Settlement. This sentence gives me my first, strong boundary clue:
- If something belongs to CLM or RTGS, it belongs to T2.
- If something belongs to another TARGET Service, it does not belong to T2, even if T2 exchanges liquidity or data with it.
What belongs to T2
1) Central Liquidity Management belongs to T2
The operating schedule describes CLM as a settlement service of T2 that:
- provides information on participants’ overall TARGET Services liquidity
- manages credit lines and central bank operations
- provides funds that facilitate settlement in other TARGET Services
From a system boundary view, I translate that into “CLM owns liquidity management capabilities”. Then I look for the concrete CLM processes that prove it.
For example, the CLM user requirements describe inter-service liquidity transfers. The goal explicitly allows a CLM account holder to transfer liquidity from a CLM account to a T2S, RTGS, or TIPS account, so those settlement services can use it for their own transactions. CLM does not just “mention” other services. It actively sends an inter-service liquidity transfer order to the receiving settlement service for further processing. Moreover, CLM processes feedback from that receiving settlement service, including confirmation and rejection behaviour.
That gives me a clean inside/outside cut:
- Inside T2: CLM creates, validates, and routes liquidity transfers from its side.
- Outside T2: the receiving service (for example TIPS or T2S) books the credit on its account and returns the outcome.
CLM even relies on dedicated transit accounts for this cross-service movement. It specifies one dedicated transit account per receiving settlement service and currency. So, I treat “transit account mechanics” as part of the T2 boundary, because CLM uses them to connect to the outside world.
Finally, CLM offers monitoring functions that give a consolidated liquidity view across several services. For example, a CLM query can return relevant information about available liquidity in CLM, RTGS, TIPS, and T2S, including balances and even collateral-related values in T2S. That does not pull TIPS or T2S inside T2. However, it proves that T2 includes cross-service visibility features inside CLM.
2) Real-Time Gross Settlement belongs to T2
The operating schedule describes RTGS as a settlement service of T2 for:
- high-value payments
- ancillary system settlement
- transaction-by-transaction real-time processing
So, in my boundary definition, I include:
- payment order processing within RTGS
- liquidity transfer processing within RTGS
- ancillary system settlement processing within RTGS
The RTGS user requirements also show that RTGS participates in the inter-service liquidity chain. It explicitly states that the “process inter-service liquidity transfer order from MCA to DCA” is the RTGS part of the CLM process, and it references the CLM process as the other part.
That boundary statement matters a lot:
- CLM owns the “liquidity management decision and initiation side”.
- RTGS owns the “RTGS-side booking and handling side”.
- The complete cross-service liquidity story spans multiple systems, but T2 owns the CLM and RTGS pieces.
3) T2 includes its shared concepts, but not all shared components
Both the CLM and RTGS requirement documents state that many business entities they use are defined in the User Requirements Document for Common Components, because other services use them too. For instance, RTGS references Party, Cash Account, Payment, Liquidity Transfer, User, Role, and Access Rights as shared definitions.
CLM references a similar shared set, including Service and Access Rights.
So, I set a rule for my boundary work:
- I keep the concepts inside my analysis model, because T2 uses them.
- I keep the common component itself outside the T2 core boundary, because it serves multiple services and needs separate ownership.
This distinction makes my models cleaner. It also avoids a classic mistake: “Everything shared must belong to my system.”
What deliberately does not belong to T2
1) Other TARGET Services stay outside T2
The operating schedule defines TARGET Services as a set that includes T2, T2S, TIPS, and ECMS. Therefore, I draw a hard line:
- T2S stays outside T2.
- TIPS stays outside T2.
- ECMS stays outside T2.
Yes, T2 exchanges liquidity with them. Yes, CLM queries may display cross-service liquidity.
However, system boundaries do not follow convenience. They follow responsibility. So, I model those services as external systems with defined interfaces.
2) Network access and routing stay outside T2
ESMIG gives actors a “single access point” for external communication to TARGET Services, common components, and applications. It authenticates inbound traffic, performs technical checks, and routes messages to the relevant backend service.
That means:
- ESMIG touches every T2 interaction.
- Nevertheless, ESMIG is not “inside T2”. It is a gateway used across multiple services.
The operating schedule even highlights that the optional maintenance window affects CLM/RTGS/T2S/common components processes, but it does not affect ESMIG availability. So, I treat ESMIG as external infrastructure in my T2 boundary model.
3) Screen design stays outside the scope of requirements
This boundary point sounds small, but it saves projects. The CLM requirements explicitly state that user interaction requirements do not imply any particular consideration regarding the design and implementation of actual screens.
So, in my CPRE-style boundary definition, I include:
- what users must be able to do
- what information they must obtain
- what rules must apply
However, I exclude:
- exact screen layouts
- UI widget decisions
- visual design choices
I can still model UI concepts later. Yet I keep them out of “system boundary of T2” on purpose.
4) Reference data management as a service stays outside T2
The operating schedule explains that common reference data can be captured during all periods except the maintenance window, and that changes propagate to CLM, RTGS, TIPS, and T2S at specific times.
This tells me two things:
- T2 consumes reference data.
- Another function manages it and distributes it across services.
Therefore, I model reference data management as an external dependency of T2, even if T2 cannot run correctly without it.
My practical boundary checklist for T2
When I define the system boundary in a requirements project, I apply a consistent test. I recommend the same for your T2 analysis.
Step 1: Name the core components
I write down:
- T2 consists of CLM and RTGS.
Then I treat CLM and RTGS as “inside”.
Step 2: List the core responsibilities
I derive responsibilities directly from the documents:
- CLM: liquidity overview, credit lines, central bank operations, and liquidity support for other services.
- RTGS: high-value payments and ancillary system settlement in real time.
Step 3: Identify cross-boundary flows
I look for explicit cross-service processes:
- inter-service liquidity transfers from CLM to RTGS/T2S/TIPS, including sending and feedback processing.
- RTGS participation as the RTGS-side part of CLM liquidity transfer processes.
Step 4: Decide what stays outside, even if it feels “close”
I keep outside:
- other TARGET Services (T2S, TIPS, ECMS).
- ESMIG connectivity and routing layer.
- screen design decisions.
- common reference data capture and propagation mechanisms.
As a result, my scope stays stable.
Conclusion and what comes next in the series
In this Part 2 article, I defined the system boundary of T2 in a way that supports real requirements work.
I keep the boundary simple:
- T2 contains CLM and RTGS.
- T2 interacts with other TARGET Services, but it does not include them.
- T2 relies on ESMIG for access, but ESMIG stays outside the T2 core.
Next, I can build on this boundary with confidence. In the following parts of this series, I can derive stakeholders, interfaces, and business processes without mixing responsibilities.
If you want to continue with the clean CPRE flow, the next strong step is: identify T2 external actors and interfaces, then map them to the CLM and RTGS responsibilities.
For more content and documents, consult the European Central Bank’s pages on TARGET Services (opens in a new tab).
Credits: The images are from iso 20022 payments.com (opens in a new tab).