Validation proposal/idee

[Nymuxyzo]

If a credit transfer contains several transactions with the same instruction identification, the bank rejects this with an error.

Example:

sct = SPS::CreditTransfer.new(
  name: 'Geld AG',
  bic: 'ZKBKCHZZ80A',
  iban: 'CH5400700110007900483'
)

sct.add_transaction(
  name: 'Maxima Musterfrau',
  bic: 'ZKBKCHZZ80A',
  iban: 'CH7700700110006771280',
  amount: 30,
  currency: 'CHF',
  instruction: '12346',
  reference: 'XYZ-1234/123/test3',
  requested_date: Date.today,
  batch_booking: false,
  charge_bearer: 'SLEV',
  category_purpose: 'OTHR',
  creditor_address: SPS::CreditorAddress.new(
    country_code: 'CH',
    post_code: '8048',
    town_name: 'Zürich',
    street_name: 'Hohlstrasse'
  )
)

sct.add_transaction(
  name: 'Klaus Martin',
  bic: 'CRESCHZZ80A',
  iban: 'CH0204835000626882001',
  amount: 25,
  currency: 'CHF',
  instruction: '12346',
  reference: 'XYZ-1234/125/test1',
  requested_date: Date.today,
  batch_booking: false,
  charge_bearer: 'SLEV',
  category_purpose: 'OTHR',
  creditor_address: SPS::CreditorAddress.new(
    country_code: 'CH',
    post_code: '4001',
    town_name: 'Basel',
    street_name: 'Bahnhofstrasse'
  )
)

sct.message_identification = "HGAHAVV1559"
XE2(sct.to_xml)

Fehler im Aufbau des XML-Elements /Document/CstmrCdtTrfInitn/PmtInf[1]/CdtTrfTxInf[2]
Fehlermeldung:
Die Instruction Identification '12346' wird im B-Level bereits verwendet.
Fehlercode:
DU05 (DuplicateInstructionID)
Dateiposition:
Zeile: 67
Spalte: 19

Or if you do a Z01 request

<?xml version= \"1.0\" encoding= \"UTF-8\" standalone= \"yes\"?>
<Document xmlns= \"http://www.six-interbank-clearing.com/de/pain.002.001.03.ch.02.xsd\">
    <CstmrPmtStsRpt>
        <GrpHdr>
            <MsgId>612725AFHD135338663117</MsgId>
            <CreDtTm>2025-07-03T13:53:38.663+02:00</CreDtTm>
            <InitgPty>
                <Id>
                    <OrgId>
                        <BICOrBEI>ZKBKCHZZ</BICOrBEI>
                    </OrgId>
                </Id>
            </InitgPty>
        </GrpHdr>
        <OrgnlGrpInfAndSts>
            <OrgnlMsgId>HGAHAVV1559</OrgnlMsgId>
            <OrgnlMsgNmId>pain.001.001.03.ch.02</OrgnlMsgNmId>
            <GrpSts>RJCT</GrpSts>
        </OrgnlGrpInfAndSts>
        <OrgnlPmtInfAndSts>
            <OrgnlPmtInfId>HGAHAVV1559/1</OrgnlPmtInfId>
            <PmtInfSts>RJCT</PmtInfSts>
            <StsRsnInf>
                <Rsn>
                    <Cd>DU05</Cd>
                </Rsn>
                <AddtlInf><![CDATA[Fataler Fehler: Element <InstrId> ist nicht eindeutig.]]></AddtlInf>
            </StsRsnInf>
        </OrgnlPmtInfAndSts>
    </CstmrPmtStsRpt>
</Document>

Perhaps a validation in message.rb in the add_transaction method would be useful?

[tobischo]

Does the bank also complain if multiple Instruction IDs are passed with the same value across multiple files within the same day (or another time period)?

My thinking is:
there is only so much we can do and eventually people need to read the specification.
This is a library to support building the pain files, but it does not encode all the different rules that a file may be subject to.

Page 33:
https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps-2025-en.pdf

Instruction Identification"
This reference is unique between the sending and receiving parties (sequence number). It is
reassigned by each party in the processing chain (in "pain.001" at the C level).

Maybe I am missing something, however to me, that would read as if it would also be required to be unique across files, making it a requirement either way and on a level where this library cannot do anything anyway.
I would rather not add an additional validation here and rather have people find their bugs earlier then.

[Nymuxyzo]

I tried it with 2 separate credit transfer files and the same instruction id and the submission was successful.

[Nymuxyzo]

It also makes sense to me that it only has to be unique within a credit transfer, as it serves as a source for the feedback for the Z01 request (pain 002) in order to refer to the corresponding payment in the event of an error.