Writing /giga/dw/dng/dokuwiki/data/meta/dev/010how/020doc/020msgs/0065target2.meta failed
dev:010how:020doc:020msgs:0065target2

TARGET2 Integration (after March. 2023)

  • T2 RTGS messages are generated via the workflow service SRVTAX.
  • T2 RTGS messages are in XML.
  • T2 RTGS messages use the DOM-function from Trade2 to create and built the required messages.
  • T2 RTGS messages consist per each message of two parts within one file
  • Business Application Header
  • Business content (full RTGS_pacs.008 or full RTGS_pacs.009)
  • When generating the technical message format, some special features have to be considered for T2 RTGS messages.
As of 20. March 2023 the existing Target2 Euro clearing service from the European Central Bank is ceased and fully migrated to the  
new clearing service for Real Time Gross Settlements called **T2 RTGS**.
 * The rulebook for T2 RTGS is a proprietary subset of the ISO20022 framework. 
 * DOKA-NG supports the RTGS messages 
   * rtgs_pacs.008 - Customer Payments Transfers (previously MT 103) 
   * rtgs_pacs.009 - Bank-to-Bank Payments (previously MT 202) 

Business Application Header BAH - head.001

Message item
Document/ ApplicationHeader/ …
<XML Tag>
<Document><AppHdr><…>
Content
From/ FinancialInstitutionIdentification/ BICFI <Fr><FIId><BICFI> The business sender that has created this message. FROM BIC must have exactly eleven characters.
From/ FinancialInstitutionIdentification/ ClearingSystemMemberIdentification/ MemberIdentification <Fr><FIId><ClrSysMmbId><MmbId> Inbound (Bank-to-RTGS):
The clearing system member identification is used to indicate system user reference and
is a logical piece of information that allows the identification of one system user in the reference data
for a privilege check.
Clearing system member identification must be present on BAH level in the case of a single message.
To/ FinancialInstitutionIdentification/ BICFI <To><FIId><FinInstnId><BICFI> The business receiver designated by the sender. TO BIC must have exactly eleven characters.
BusinessMessageIdentifier <BizMsgIdr> Identifies, unambiguously, the message. The BusinessMessageIdentifier has maximum 35 characters.

For inbound messages (Bank-to-RTGS):
In all cases, this value is used by RTGS in place of any me ssage ID value which
may be provided within the business message.

For outbound messages (RTGS-to-Bank):
Contains the unique message ID from RTGS. Any message ID field within the
business payload is populated with “NONREF”.
MessageDefinitionIdentifier <MsgDefIdr> Contains the MessageIdentifier that defines the business payload. It must contain a valid ISO 20022
MessageIdentifier supported by RTGS.

Bank-to-RTGS:
Message Identifier is checked by RTGS (the message type has to be supported by RTGS).
RTGS-to-Bank:
The published ISO Message Identifier corresponding to the message payload which follows is used.

For pacs.009, it will also be indicated if the payment is a CORE or COV payment.
Example:
pacs.009.001.08COV and
pacs.009.001.08CORE
CreationDate <CreDt> <CreDt> Date and time when this BAH was created.

Only ZULU time is used. Example: 2019-10-07T13:25:00Z
CopyDuplicate <CpyDplct> (optional - not used in DOKA) <CpyDplct> Date and time when this BAH was created.
PossibleDuplicate <PssblDplct> (optional - not used in DOKA) <PssblDplct> Indicates whether the business payload is a copy, a duplicate or a copy of a duplicate of a previously sent
ISO 20022 message. The value is ignored by RTGS and not forwarded to the business receiver
Signature <Sgntr> <Sgntr> Contains the digital signature of the business entity authorised to sign this business message.

Certificate which identifies the business sending user in combination with the Clearing system member identification
for single messages.

Note: The digital signature is part of the BAH in case of a single message.
Related <Rltd> (optional - not used in DOKA) Specifies the BAH of the business message to which this business message relates. It can be used when
replying to a query; it can also be used when canceling or amending.

Section 2 (Business content)

Consists of full XML messages

  • rtgs_pacs.008 or
  • rtgs.pacs.009COR

Normally, not the receiver BIC, but another BIC (e.g. the BIC of an internal payment system) is specified for T2 RTGS. Thus, it must be possible to assign this field as customized. This can be realized via the function “SRVSWT.GetIOBIC” (in $tag text, in $bic text)). It returns a BIC.

In case of standard T2 RTGS messages, this function returns exactly what is currently implemented.

dev/010how/020doc/020msgs/0065target2.txt · Last modified: 2024/04/05 10:10 (external edit)