Hi @Drausenhaus

Hash values are currently embedded in some payment standards. For an example, if we take ISO20022 based CT file (SEPA or non-SEPA), ControlSum value is used as a Hash value to validate the accuracy of the file amounts. When the bank validates the file, if has total is not matched with the amounts in the file structure the payment will be rejected. So, from IFS side, when payment file is created the control sum amount has been coded as a hash amount. 

Hope you are aware that in IFS we use Checksum algorithm in several places to validate the uniqueness of the number. For an example, we use Modula10/11 algorithm to calculate payment reference in live invoices, the same validation available when validating the incoming reference in supplier invoice entry level. Further, we have used similar validation for IBAN according to the ISO13616 standard. But, you might know checksum and hash algorithms are not identical although there are some similarities.

Do you have a specific requirement to implement a specific hash value?

Thanks Eranda, I was aware of the hash values. What I am looking for is a hash code that secures the whole file. With the hash value you can secure the amounts, but I would still be able to change other data in the file, like the bank account.

Additional info: there is a standard protocol (SHA-256) to create a hash code. Would be good if this protocol would be available in core functionality. Any comments from R&D?

Hi @Drausenhaus,

Did you match your requirement for implementing a hash code so that the whole file insecured?

We are also looking for a solution secure the payment file from IFS.

There are plans to implement this is a modification, but it seems a litle difficult to get the algoritm. There is information on the internet, but no "official” source. So the risk is, that the file is secured and the bank can not process it. So long story short: still work in progress.

Hi all, looking into same challenge - we have a modification (APPS10 UPD14) planned and estimated, but effort is substantial, if not huge. Customer is rightfully asking if this is not standard IFS - as it seems a legal / audit requirement in NL. Further comments appreciated

Bump,

Is there no solution for this?

What would be the process if this is not included in IFS?

Anyone from IFS? Considering that others are planning a modification with substantial effort on earlier versions of IFS, we would really appreciate it if we could skip this in IFS cloud.