SEPA ISO20022 XML Transformer for Germany as of 2023 NOV
text from bank regarding SEPA transition
I am looking for guidance on which one of the many XML Transformers in Connect should be used in Germany to meet the October 2023 mandate for the SEPA format.
We currently have a rule with MESSAGE_FUNCTION = ‘SEND_SEPA_CREDIT_TRANSFER_DE_04’ that outpus the SEPA XML file to the Application Server. Our accountant in Germany has raised a red flag advising that we must use a new format. However, I am in US and unfamiliar with the work flow and handling of the SEPA XML file. No guidance that I can understand has been provided to me.
Page 1 / 1
Hi @Thom C
for Germany we use the following transformer for SEPA:
Hi and thanks for the response. I am setting this up in our non-production environment for our German IFS users to validate.
This is very much appreciated!
Hi Thom,
in germany the core template should be used as shown underneath. There will be no country specific Pain Format for germany. Pain.001.001.03 / 008.001.02 will be discontinued earliest 11/2025. For payments in foreign currency IS0 20022 should be used.
Formats in Detail
Following formats are discontinued:
SEPA-Payments PAIN.001
Version DK-Specification valid since
PAIN.001.001.02 2.2 29.10.2007
PAIN.001.001.02 2.3 15.11.2008
PAIN.001.002.02 2.4 01.11.2009
PAIN.001.002.03 2.5 01.11.2010
PAIN.001.002.03 2.6 17.11.2012
PAIN.001.003.03 2.7 04.11.2013
PAIN.001.003.03 2.8 17.11.2014
PAIN.001.003.03 2.9 23.11.2015
SEPA Core Version PAIN.001.001.03 is still valid and should be accepted by your payment institute
SEPA-Direct Debeting PAIN.008
Version DK-Specification valid since
PAIN.008.001.01 2.2 29.10.2007
PAIN.008.001.01 2.3 15.11.2008
PAIN.008.002.01 2.4 01.11.2009
PAIN.008.002.02 2.5 01.11.2010
PAIN.008.002.02 2.6 17.11.2012
PAIN.008.003.02 2.7 04.11.2013
PAIN.008.003.02 2.8 17.11.2014
PAIN.008.003.02 2.9 23.11.2015
SEPA Core Version PAIN.008.001.02 is still valid and should be accepted by your payment institute
As per my understanding the changes in the new Pain formats might be different depending on changes that banks would like to introduce. They are not even related to ISO20022.
The most drastic change between versions is that pain.001.001.09 (and other newer ISO messages) support the usage of the “SupplementaryData” field. Supplementary Data elements in the ISO message are defined as "xs:any", which means that they can contain any element, without restrictions on the data. For this reason, banks might release their own SupplementaryData schemas which are not related to ISO 20022 in any way. So finally it might be necessary to implement changes that are depending on the bank even if there is a “standard”.
Kind regards
Ralph
@Ralph Gericke
This is a valid request and I think this request has been transferred to R&D. I have given following feedback in the post,
Most of the banks now advise Corporates to migrate to the latest Common Global Implementation (CGI) ISO 20022 version (pain.001.001.09 or V9) in order to benefit from a harmonized cross-border payment experience and the latest value-add services. Although this version is based on the ISO20022 2019-2023 release, the bank adoption is very new and some global banks like Citi are going to support this version from 2023 onwards. Since IFS also follows the Common Global Implementation (CGI) releases, it is good to introduce pain.001.001.09 as a new XML transformer in IFS Core solution. However, pain.001.001.03 version should be continued until all the banks and clearing channels are completely moved to V9.
There are not a lot of differences between V3 and V9 versions from IFS perspective other than some points highlighted below.
Introduced additional attributes for postal addresses presentation
UETR - Unique End-to-end Transaction Reference (SWIFT gpi) to track the payment (added to PMTINF level)
LEI: Legal Entity Identifier to identify the payment initiating party (Initiating Party/Identification)
In addition to the above some XML tag names have been changed.
