Figure for payment flow in TARGET2
Below blog information gives a constructive idea about settlement and describes a simple flow of what happens in the settlement system sending 'pacs 008/009' via SWIFT to TARGET2.
Different payment clearing and settlement services managed by EPC (European Payment Council) or EBA (European Banks Association) or private need to maintain liquidity in its current account with TARGET2 an RTGS system for Euro domestic and cross-border payments. Even the direct participants needs to maintain liquidity in its current account with the RTGS.
Liquidity management applications (ICM/ASI/HAM) or Backup payments handling application (camt.023) are provided to the direct participants or Central banks of SEPA countries to add funds or receive return liquidity in its pre-settlement accounts or collateral accounts.
TARGET2 at present receives payment with SWIFTnet network from different direct customers or clearing systems. with pacs.008 or pacs.009
The different accounts used by participants and their meaning can be understood here in this link
Below is the flow or steps defined how Y copy service is used for making an RTGS payment settled and sent to the receiver.
Assumptions :
ordering or sender institution BIC - A, beneficiary or receiving institution - B
Flow Steps :
Step 1 : Sending institution on behalf of the ordering institution will process payment instruction and send clearing and settlement payment to move funds in RTGS accounts maintained with TARGET2 before the cut-off time set by EPC. The payment format would be pacs.008 or pacs.009 and is intended to send to institution B via SWIFT.
Step 2 : WIth Y-Copy service of SWIFTnet, the message would be copied (as pacs.008 or pacs.009) and submitted for processing in TARGET2 and a system response message xsys.002 (optional) can be sent to sending institution or app (all interfaces would be maintained between the apps/systems).
Step 3: TARGET2 will find the current accounts of institutions A and B and will do debit posting in A and credit posting in B current accounts. The XML payment message has to pass several validations (schema validation and application-oriented entry checks) before payment is created. The payment has to pass further validations, e.g. availability of sufficient cover, before it is debited on the RTGS account of A and simultaneously credited on the RTGS account of B
Step 4: TARGET2 will send system message xsys.001 to SWIFTnet which in turn sends pacs.008 or pacs.009 to Institution B for further processing by the PSP. TARGET2 may also send system message xsys.002 to institution A for giving confirmation on authorization on submitted pacs.008/009. The rejection of a payment message is notified to the sender by xsys.003 in case of a SWIFT-based participant as sender.
Please visit the image above for easy co-relating.
The following diagram illustrates the message flow in general for the payment interface of the PM for the direct debit message pacs.010 - using the SWIFTNet Copy service and SWIFTbased participants on senders and receivers side:
Note: In general the usage of pacs.010 requires an agreement between the sender (creditor) and the receiver (debtor) of the payment message.