Table of contents
ISO20022 describes EndToEndId as follows:
Definition: Unique identification assigned by the initiating party to unumbiguously identify the transaction. This
identification is passed on, unchanged, throughout the entire end-to-end chain.
Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction.
It can be included in several messages related to the transaction.
Data Type: Max35Text, Format: maxLength: 35, minLength: 1
To conclude, the element is mandatory by the schema and it has to be unique. Uniqueness is checked by the validator unless otherwise decided with the bank.
Here it's worth noting that the uniqueness combined with element being mandatory can bring certain problems. Common workaround is to allow element to be filled with value NOTPROVIDED. If bank uses this method our validator ignores the value NOTPROVIDED from the uniqueness check.
<PmtInf> <CdtTrfTxInf> <EndToEndId>1</EndToEndId> </CdtTrfTxInf> </PmtInf> <PmtInf> <CdtTrfTxInf> <EndToEndId>2</EndToEndId> </CdtTrfTxInf> <CdtTrfTxInf> <EndToEndId>NOTPROVIDED</EndToEndId> </CdtTrfTxInf> <CdtTrfTxInf> <EndToEndId>NOTPROVIDED</EndToEndId> </CdtTrfTxInf> </PmtInf>
(Various elements have been removed for the sake of the example)
The example is in valid format if NOTPROVIDED check has been agreed with the bank. By default EndToEndId is always treated as described in ISO20022 document, so according to it an error would be given from the example above.