T2 provides the mechanisms for real time gross settlement (RTGS) of payment orders and capital transfers in central bank money (that‘s why is also referred to as RTGS) and is the "successor" of TARGET2 with respect to the specific functionality.
Basic design functionality
- RTGS is used for the settlement of individual payments and/or ancillary system settlement
- Participation in RTGS is optional (necessary only if payment bank wants to settle individual payments and/or wants to participate in the ancillary system settlement)
- RTGS is multi-currency enabled, i.e. the settlement services are technically designed to support settlement in different currencies, however it does not offer conversion between currencies
- Settlement takes place on RTGS Direct Cash Account (RTGS DCA) level
- RTGS DCAs are allowed a positive or zero balance only
- RTGS DCAs can be used for liquidity transfer from / to Central Liquidity Management (CLM) module
- RTGS supports direct parties (RTGS account holders), addressable BIC holders and multi-addressee access
in RTGS Processing
Example for the processing of a payment
Use case: Credit transfer from one RTGS DCA to another one
- RTGS Account Holder A sends
a FinancialInstitutionCreditTransfer (pacs.009) or
CustomerCreditTransfer (pacs.008) via ESMIG to
- RTGS settles the payment order on the RTGS DCAs of
RTGS Account Holders A and B - after sucessful validation
- RTGS sends a settlement notification (PaymentStatusReport (pacs.002)) via ESMIG to
initiating RTGS Account Holder (A)
- RTGS creates and forwards the payment (FinancialInstitutionCreditTransfer (pacs.009) or CustomerCreditTransfer (pacs.008)) via ESMIG to
RTGS Account Holder (B)
in RTGS Priorities
- Immediate execution of the cash transfer order, if no other urgent cash transfer order is queued
- FIFO principle applies for urgent cash transfer orders in RTGS
- BUT: automated liquidity transfers (inter-service) will always be settled first
- Immediate execution of the cash transfer order, if no other urgent and high classified cash transfer order is queued
- FIFO principle applies for as high classified cash transfer orders in RTGS, if no urgent cash transfer order is queued
- Processing of the payment according to the "FIFO-bypassing" principle – this means the queue is not decisely, rather the account balance, opposing cash transfer orders, reservations and limits are influencing factors
- "Normal" is used if no priority has been chosen (default)
in RTGS Execution
A payment order is executed during the business day. RTGS Account Holder may
define the following execution times.
"Earliest debit time indicator"
- Payments are stored until the execution time (FromTime) is reached and are then delivered to the entry disposition.
- If RTGS cannot immediately settle the payment order at the execution time the payment order is queued.
- If the payment order cannot be settled by the end of the business day and at the respective cut-off-time or possibly by reaching the RejectTime it is rejected.
"Latest debit time indicator"
- Option A: The payment has to be executed by a pre-defined time (RejectTime). Otherwise the payment order is rejected.
- Option B: The payment is ought to settle by a pre-defined time (TillTime). Otherwise the payment order is queued and – if it cannot be settled before – is rejected when reaching the respective cut-off.
- If a payment (option A + option B) is not settled 15 minutes before reaching the pre-defined time, RTGS informs the Account Holder via U2A (broadcast) and via A2A (admi.004), if subscribed.
in RTGS Warehoused
- Payment orders can be submitted up to 10 calendar days before the intended settlement day.
- Submission, change and revocation are done by the RTGS Account Holder.
- Warehoused payments are stored in RTGS until the intended settlement day starts. By then these will be validated against the business validation rules at the start of the business day.
- On the intended settlement day the payment order is executed with the start of the execution window for customer and interbank payments (as of 02:30) - In general, the payment is executed before all incoming payments with the same priority (provided that sufficient liquidity is available)
in RTGS Revocation/recall
- RTGS Account Holder sends FIToFIPaymentCancellationRequest (camt.056) to RTGS
- RTGS checks the request and checks the status of the message (not settled)
- RTGS sends a notification on the successful revocation to the RTGS Account Holder A (ResolutionOfInvestigation (camt.029))
- RTGS sends a notification (Payment StatusReport (pacs.002)) to the RTGS Account Holder A
If a revocation is not possible the RTGS Account Holder receives a camt.029 with negative status.
- RTGS Account Holder A sends
a FIToFIPaymentCancellationRequest (camt.056) via ESMIG to
- RTGS forwards the message to RTGS Account Holder B
- RTGS notifies RTGS Account Holder A about
forwarding with a ResolutionOfInvestigation (camt.029)
- RTGS Account Holder B checks the request
- RTGS Account Holder B sends
a PaymentReturn (pacs.004) to
- RTGS executes the payment order after successful validation
- RTGS sends a positive notification (Payment StatusReport (pacs.002)) to
- The PaymentReturn (pacs.004) will be
forwarded to RTGS Account Holder A
If B rejects the recall he sends a camt.029 with the rejection code which will be forwarded to A