TARGET Services T2 – System Analysis Article Series
Part 1: Strategic & Business Context
Article 4
When I analyse payment infrastructures, I start with context. I skip screens and message fields at first. Instead, I map where T2 in TARGET Services sits and why its neighbours matter. This matches the Certified Professional Requirements Engineer (CPRE) of the International Requirements Engineering Board (IREB) mindset. First, I define scope and interfaces. Then, I derive requirements that fit reality. T2 works with CLM, TIPS, T2S, and ECMS. Therefore, I treat interactions as core analysis objects and avoid rework.
In this first part of my T2 system analysis series, I explain how T2 interacts with CLM, TIPS, T2S, and ECMS, and why these dependencies define your real requirements baseline. TARGET Services include T2, T2S, TIPS, and ECMS, and they support the free flow of cash, securities, and collateral across Europe.
1) The landscape in one sentence: what TARGET Services connect
From a strategic viewpoint, the Eurosystem operates several services that work together:
- T2 settles payments and provides liquidity management through its components.
- T2S supports securities settlement and cash-related liquidity transfers.
- TIPS supports instant payments and stays available continuously for that purpose.
- ECMS supports collateral management for Eurosystem monetary operations, and it replaces national collateral systems with a single system.
So, when I draw the system context (CPRE artifact), I do not draw T2 as a box with “users”. I draw T2 as a node in a settlement-and-liquidity network.
2) What T2 is in TARGET Services: one service, two components
The TARGET documentation defines T2 as a TARGET Service composed of Central Liquidity Management (CLM) and Real-Time Gross Settlement (RTGS). That split matters for analysis, because it shapes your interfaces:
- CLM handles “liquidity and control” topics.
- RTGS handles “payment processing and settlement” topics.
Even if a stakeholder says “T2”, their requirement often belongs to one component. Therefore, I always map requirements to the right component early.
3) CLM: the liquidity hub that connects T2 to T2S, TIPS, and RTGS
If I have to pick one “integration center” in the landscape, I pick CLM.
3.1 CLM’s strategic role
CLM provides information on participants’ overall TARGET Services liquidity, it supports credit line management, and it provides funds for settlement in other TARGET Services. This single sentence already creates requirements pressure:
- I need a consolidated liquidity view.
- I need controlled liquidity movement between services.
- I need rules for credit lines and central bank operations.
3.2 Inter-service liquidity transfers: CLM moves liquidity into T2S/RTGS/TIPS
CLM includes a business process explicitly for transferring liquidity from a CLM Account to a T2S/RTGS/TIPS Account, so that those services can settle their specific transactions. Moreover, CLM structures these transfers using Dedicated Transit Accounts, and it holds one Dedicated Transit Account per receiving settlement service and currency.
Also, CLM expects operational feedback. If the receiving settlement service confirms, then CLM treats the transfer as successfully booked in that service. If the receiving service rejects, then CLM automatically reverses the initial transfer. From a CPRE perspective, I treat this as a clear interface contract:
- CLM initiates a transfer.
- The receiving service confirms or rejects.
- CLM reacts deterministically.
So, if I specify requirements for “liquidity provisioning to T2S”, I must include the full feedback loop, not only the outgoing request.
3.3 Cross-service liquidity monitoring: CLM can aggregate balances across services
CLM also supports cross-service transparency for central banks. For example, CLM provides a query for an aggregated view of liquidity with breakdowns that include balances on MCA, RTGS DCA, TIPS DCA, and T2S DCA. This matters because it turns “monitoring” into a real functional requirement. In other words, the landscape forces observability.
4) RTGS: settlement engine for payments and a key partner for liquidity transfers
RTGS is the settlement service inside T2 for real-time processing. The TARGET schedule describes RTGS as a settlement service of T2 for high-value payments and ancillary system settlement, with transaction-by-transaction processing in real time. Now the key point for the landscape: RTGS does not only settle “payments”. It also participates in liquidity transfer processes that CLM starts.
The RTGS user requirements document explicitly describes RTGS parts of inter-service liquidity transfer processes between MCA and DCA, and it links those processes to the CLM processes. So, in system analysis terms, CLM and RTGS form an internal collaboration boundary inside T2. Therefore, I never model “T2 liquidity transfers” without showing both components.
5) T2 and T2S: liquidity and securities settlement meet
T2S sits next to T2 in the TARGET landscape. Even when I focus on T2, I must understand T2S touchpoints, because T2 participants often need liquidity in T2S to settle securities.
5.1 The main integration mechanism: liquidity transfer orders to T2S dedicated cash accounts
T2S defines business validation requirements for liquidity transfer orders, including orders “between RTGS and T2S dedicated cash account”. It lists mandatory fields such as currency, transfer amount, RTGS system, and the target dedicated cash account. So, when I elicit a requirement like “move liquidity from T2 to T2S”, I immediately translate it into:
- a liquidity transfer instruction,
- with specific data fields that must exist,
- and with validation rules.
That translation is exactly what requirements engineering should do: turn intent into testable statements.
5.2 Real-time behaviour: liquidity transfers execute in real time (with defined exceptions)
T2S describes liquidity transfers as executed in real time, except during night-time settlement when a settlement cycle runs. This creates practical requirements:
- I need predictable processing windows.
- I need user expectations for when liquidity becomes available.
- I need operational monitoring, especially around night-time settlement.
6) T2 and TIPS: instant payments plus liquidity coordination
TIPS operates in a different rhythm than classic high-value payment settlement.
6.1 TIPS as a TARGET Service with continuous processing for instant payments
The TARGET operating schedule shows that TIPS processes instant payments continuously (24/7/365) for instant payments and related activities, even while other components may face maintenance constraints. It also states that TIPS changes its business day following CLM and RTGS closure. So, strategically, I treat TIPS as “always-on” for payment processing, while liquidity movements still depend on shared scheduling constraints.
6.2 Liquidity transfer between RTGS and TIPS accounts
The TIPS user requirements documentation defines a liquidity transfer as an instruction to transfer central bank money from an RTGS account to a TIPS account or vice versa. Also, CLM explicitly supports liquidity transfers involving TIPS accounts, because CLM’s inter-service liquidity transfer process covers transfers from a CLM Account to a T2S/RTGS/TIPS Account.
So, in the system context diagram, I connect TIPS to T2 via:
- liquidity transfers (often mediated through CLM processes),
- monitoring and queries (operational control),
- scheduling and maintenance constraints.
6.3 Operational transparency: TIPS queries for liquidity and transactions
TIPS provides query functionality for information about payment transactions, liquidity transfer orders, and accounts, and it processes queries based on authorisation and validation. Therefore, requirements for operations teams rarely stop at “process payments”. They include “explain what happened”, and TIPS already embeds this idea via query capabilities.
7) T2 and ECMS: collateral becomes liquidity via credit lines, and settlement runs via T2S
ECMS adds a crucial dimension. It turns eligible assets into collateral value that supports monetary credit operations. In practice, it also affects liquidity conditions in T2 through credit lines.
7.1 Why ECMS exists: one collateral system for the euro area
The ECMS business description explains the rationale clearly: the Eurosystem provides credit only against adequate collateral, and complex systems are needed to manage collateral effectively. ECMS replaces the individual NCB collateral management systems with a single system and increases efficiency for mobilisation and management of collateral. So, at a strategic level, ECMS standardises collateral handling across jurisdictions.
7.2 ECMS and T2S: ECMS sends settlement instructions for (de)mobilisation
For marketable asset mobilisation, the ECMS transmits instructions to T2S in the form of settlement instructions. Moreover, ECMS updates the asset position only after settlement has been confirmed by T2S. This creates a clean dependency chain:
- Counterparty instructs ECMS.
- ECMS sends settlement instruction to T2S.
- T2S confirms settlement.
- ECMS updates positions.
So, if I write requirements for “mobilise collateral for monetary credit operations”, I must include T2S settlement confirmation as a required event in the lifecycle.
7.3 ECMS and CLM: credit line changes connect collateral and liquidity
The CLM central bank annex defines the credit line as the maximum collateralised overdraft position on the Main Cash Account (MCA) in CLM. It also states that credit line changes can be initiated through a modification order sent by the instructing collateral management system. This is exactly where ECMS enters the T2 world.
The ECMS business description document describes a “floating credit line” approach. When the suggested credit line in ECMS increases, the increase can be automatically repurposed to increase the credit line in CLM. Conversely, decreases in available collateral can trigger reductions of the credit line (subject to CLM confirmation).
The ECMS message catalogue also shows concrete message behaviour for modify-credit-line requests between ECMS and CLM, including status reporting like pending and rejected outcomes. So, from a requirements engineering viewpoint, I treat “credit line” as an integration object:
- It belongs to CLM as a value and constraint.
- It depends on ECMS collateral status.
- It triggers operational consequences for liquidity and payments.
7.4 A hidden but important interaction: CLM can trigger liquidity transfers to settle a credit line change
There is a detail that often surprises people. If CLM cannot settle a credit line modification request due to insufficient liquidity on the MCA, CLM can automatically trigger an inter-service liquidity transfer order for the missing amount from the RTGS DCA to the MCA. This single rule connects collateral, liquidity, and RTGS queue priority. Therefore, it belongs into the strategic context, not only into low-level design.
8) Shared operating constraints: schedules and maintenance windows shape “what is possible”
Even with perfect functional design, the operating day imposes constraints. The TARGET operating schedule describes optional and non-optional maintenance windows. It also states that an optional maintenance window affects CLM/RTGS/T2S/common component processes and settlement of liquidity transfer orders in TIPS, while it does not affect TIPS processing of instant payments and some other activities.
So, when I write requirements, I always ask:
- “Which processes must remain available?”
- “Which processes can pause?”
- “Which cut-offs exist, and who owns them?”
Also, CLM includes explicit dependencies between liquidity transfers and end-of-day processing. For example, CLM states that end-of-day processing shall not start if pending inter-service liquidity transfer orders still exist. This is not a technical curiosity. It is a business constraint. It affects incident handling, operational controls, and user expectations.
9) how I turn this landscape into a requirements baseline
In CPRE terms, this part of the series builds the system context and the business context. Here is the practical checklist I apply:
Define the system boundary precisely
- T2 includes CLM and RTGS.
- T2S, TIPS, and ECMS are external systems relative to T2, yet they couple tightly through liquidity, settlement, and credit line mechanisms.
Identify the external interfaces that drive most requirements
In this landscape, I see four interface families:
- Liquidity transfer orders between CLM/RTGS/T2S/TIPS accounts.
- Credit line modification between ECMS and CLM, with defined status outcomes.
- Securities settlement instructions between ECMS and T2S for collateral (de)mobilisation.
- Operational queries and monitoring, because control and transparency are built into the services.
Capture constraints early
- Schedules, maintenance windows, and cut-offs define availability.
- Some processes must complete before end-of-day can proceed.
Once I have these artifacts, I can elicit and specify requirements with less ambiguity. Moreover, I can validate them against documented service behaviour.
Conclusion: why this landscape view is the real start of T2 analysis
T2 sits at the heart of payment settlement. However, its real behaviour emerges from interactions:
- CLM provides cross-service liquidity management and inter-service liquidity transfers.
- RTGS settles payments and participates in CLM-driven liquidity transfer processes.
- T2S receives and validates liquidity transfer orders and executes liquidity transfers in real time with defined exceptions.
- TIPS processes instant payments continuously, while liquidity transfers follow shared operational constraints.
- ECMS manages collateral for Eurosystem credit operations and connects into CLM credit line logic, while it relies on T2S settlement confirmation for collateral movements.
In the next parts of this series, I build on this foundation. Next, I will translate the landscape into a clean system context model, identify the most important business events, and then derive requirement clusters for liquidity, settlement, operations, and resilience—always traceable back to the official documentation.
For more content and documents, consult the European Central Bank’s pages on TARGET Services (opens in a new tab).