TARGET Services T2 – System Analysis Article Series
Part 1: Strategic & Business Context
Article 2
When I analyse a payment and market infrastructure system, I start with “why”. I do not start with screens, messages, or data fields. Instead, I clarify business goals and policy aims first. This mindset fits the CPRE approach from IREB. CPRE anchors requirements in goals, stakeholders, and context. Therefore, T2 Objectives become my compass for every later requirement decision.
In this article, I explain why T2 exists inside the TARGET Services landscape. Moreover, I connect T2 to three core objectives: monetary policy, financial stability, and operational efficiency. Finally, I translate these objectives into concrete requirements thinking, so you can reuse the method in your own system analysis work.
Where T2 sits in TARGET Services
TARGET Services aim to ensure the free flow of cash, securities, and collateral across Europe, with settlement in central bank money. Within that landscape, T2 provides the settlement service for payments in central bank money in Europe. T2 is not a single “box”. Instead, it combines two major capabilities:
- CLM (Central Liquidity Management): It provides information about participants’ overall liquidity across TARGET Services, manages credit lines and central bank operations, and provides funds that support settlement in other TARGET Services.
- RTGS (Real-Time Gross Settlement): It processes high-value payments and supports settlement for ancillary systems, using real-time gross settlement logic.
This split matters for requirements work. The “why” stays the same. However, the “what” differs between CLM and RTGS. Consequently, I always keep the policy objectives visible while I decompose scope.
My CPRE lens: goals first, then requirements
In CPRE terms, I start with goals and stakeholders, and I place the system into its context. Then I derive functional requirements and quality requirements from that foundation. This order reduces rework. Moreover, it makes discussions with stakeholders faster and less emotional, because we can point to goals instead of opinions.
For T2, the official documentation already gives me strong goal signals:
- T2 enables settlement in central bank money in Europe and supports the implementation of monetary policy.
- CLM processes central bank operations, including monetary policy operations and standing facilities, and books them on the main cash account.
- RTGS commits to strict availability, recovery, performance, and cyber resilience targets, which clearly supports stability-oriented goals.
Now I turn these signals into a structured “why T2 exists” explanation.
Policy objective 1: T2 exists to support monetary policy implementation
Monetary policy needs operational execution. It needs liquidity, accounts, credit, and settlement in central bank money. Therefore, a central bank must run infrastructure that can implement policy decisions safely and consistently.
T2 supports monetary policy through central bank money settlement
T2 exists as the Eurosystem settlement service for payments in central bank money in Europe, and it explicitly supports monetary policy implementation. That statement is not marketing. It is the strategic “why” that drives the system.
CLM operationalises monetary policy-related cash operations
CLM processes multiple Central Bank Operations and books them on the Main Cash Account. The CLM documentation lists, among others, standing facilities, monetary policy operations, interest payment orders linked to marginal lending, overnight deposits, minimum reserves, and other activities carried out by central banks as central bank of issue.
So, when I translate this into requirements work, I immediately see a stable core use case family:
- maintain credit lines,
- execute monetary policy operations,
- handle standing facilities,
- calculate or support reserve-related processes,
- prioritise and control liquidity usage.
Moreover, CLM defines priority behaviour for liquidity tapping and even triggers automated liquidity transfers when needed for main cash account operations. That is pure requirements gold, because it already expresses rules, priorities, and system reactions.
T2 connects policy cash flows across TARGET Services
Monetary policy also interacts with securities settlement flows. For example, the T2S specifications describe rebalancing cash stemming from the settlement of monetary policy operations and transferring liquidity to the relevant RTGS account automatically. In addition, ECMS documentation explicitly names interaction with CLM for settling payments stemming from monetary policy operations and standing facilities.
From a system analysis perspective, this means I must treat T2 as part of a wider ecosystem. Therefore, my context model must include at least CLM, RTGS, and the major interacting services (for example, T2S and ECMS), plus the common components that support user access and messaging.
Policy objective 2: T2 exists to strengthen financial stability
Financial stability is not an abstract promise. It becomes real through settlement finality, resilience, predictability, and controlled failure modes. Therefore, I look for “stability language” in requirements such as availability targets, recovery objectives, scalability, and cyber resilience.
RTGS supports stability through real-time gross settlement and intraday finality
The documentation defines RTGS as real-time gross settlement, meaning continuous settlement of transactions on a one-by-one basis with intraday finality. This matters because high-value payments and settlement obligations must not depend on netting cycles alone. Instead, they need predictable and final settlement.
Moreover, RTGS supports ancillary system settlement flows and processes transfer orders on technical accounts and settlement bank accounts. So, RTGS sits in the critical path for market-wide obligations. Consequently, stability requirements become non-negotiable.
Stability drives strong availability, disaster recovery, and cyber resilience requirements
RTGS sets a clear availability target: availability, calculated quarterly, shall be at least 99.7%. In addition, RTGS defines disaster recovery objectives, including an Recovery Point Objective (RPO) of zero minutes for site failures (and a tolerated two minutes for complete region loss), plus an Recovery Time Objective (RTO) of one hour (and two hours for complete region loss).
It also mandates compliance with information security and cyber resilience requirements. From a CPRE angle, these are quality requirements. They express measurable constraints and targets. Therefore, I treat them as first-class requirements, not as “non-functional afterthoughts”.
Stability also requires capacity and shock tolerance
RTGS explicitly requires upward scalability to cope with short-term market shocks and foreseeable increases, including handling 20% higher workload within 15 minutes and up to doubling workload (with limits) within 365 days.
This requirement links stability to operational reality. Markets spike. Incidents happen. Therefore, the system must degrade gracefully or scale quickly.
Policy objective 3: T2 exists to improve operational efficiency and integration
Efficiency in market infrastructure does not mean “cheap”. It means predictable processing, harmonised access, controlled liquidity usage, and consistent interaction across services. Therefore, T2 exists not only to settle, but also to standardise and integrate settlement operations across Europe.
TARGET Services need a harmonised cash backbone
TARGET Services aim for free flow of cash, securities, and collateral across Europe, with settlement in central bank money. T2 sits at the centre of that cash layer. Consequently, integration and consistency become core design drivers.
CLM centralises liquidity information and control across services
CLM provides information about participants’ overall TARGET Services liquidity and supports liquidity provisioning for settlement services such as T2S, TIPS, and RTGS via dedicated cash accounts. So, CLM enables a single liquidity view and coordinated liquidity movements. This reduces fragmentation. Moreover, it reduces operational risk caused by manual, disconnected liquidity management.
RTGS supports efficient settlement for high-value payments and ancillary systems
RTGS covers high-value payment settlement and ancillary system transfers. It describes structured processes, account constellations, and settlement procedures for ancillary systems. In practice, that supports operational efficiency because banks and infrastructures can use defined procedures rather than inventing ad-hoc settlement patterns.
Efficiency also shows up as performance requirements
RTGS requires that 95% of transactions complete within 2 minutes and 100% within 5 minutes. It also defines a peak workload capability. These constraints directly support operational efficiency because they set a predictable service level for critical settlement flows.
Turning “why T2 exists” into a requirements structure
Here is how I convert the three objectives into a requirements management structure, CPRE style.
1) Start with a goal model
I write a simple goal map:
- G1 Monetary policy execution works end-to-end (policy goal)
- supported by CLM processing central bank operations and monetary policy operations
- G2 High-value obligations settle safely and predictably (stability goal)
- supported by RTGS real-time gross settlement with intraday finality
- supported by availability and recovery objectives
- G3 Liquidity management stays efficient across services (efficiency/integration goal)
- supported by CLM’s overall liquidity view and provisioning for multiple settlement services
2) Derive requirement types explicitly
Then I split requirements into:
- Functional requirements: “what the system does”
Example: CLM processes standing facilities and monetary policy operations. - Quality requirements: “how well it must do it”
Example: RTGS availability at least 99.7% quarterly.
Example: RTGS cyber resilience compliance. - Constraints and business rules: priorities, tapping order, irrevocability rules
Example: CLM defines a predefined liquidity tapping order and automated liquidity transfer triggering.
3) Build traceability from goals to requirements
I create trace links like this:
- Monetary policy goal → CLM capability → CLM rules & processes
- Stability goal → RTGS finality & resilience → availability/RPO/RTO/cyber requirements
- Efficiency goal → harmonised liquidity control → CLM cross-service liquidity provisioning
This traceability matters because it keeps later design debates grounded. Moreover, it supports structured change impact analysis.
Conclusion: T2 exists because policy needs reliable execution
T2 exists because Europe needs settlement in central bank money that supports monetary policy operations, strengthens financial stability, and improves operational efficiency. The documentation expresses this “why” through T2’s monetary policy role, CLM’s central bank operations scope, and RTGS’s strict resilience and performance requirements.
When I apply CPRE thinking, I treat these objectives as my root requirements source. Therefore, I can derive functional scope, quality targets, and traceability in a structured way. As a result, my system analysis becomes clearer, faster, and easier to defend.
For more content and documents, consult the European Central Bank’s pages on TARGET Services (opens in a new tab).