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)
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. |
|
Consists of full XML messages
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.