Skip to main content

Hello,

Can someone help me with the below question please?  

We need to generate an ISO20022 Pre-Authorized payment file for Customers. Based on the guidelines received from the bank, this file needs to be in the format of “WIFT ISO 20022 pain.008.001.02”.

However, I have noticed that IFS Application has only below listed file formats available, and nothing representing “WIFT ISO 20022 pain.008.001.02”.

 

Has anyone implemented ISO20022 Pre-Authorized payment using the standard IFS application? If so, could you please share more details?

Thank You!

Best Regards

Sugandi

Hi Sugandi,

I think you are referring to a support for Direct Debiting Process through ISO. This has not been supported in core application yet, however there has been some discussions around this. 

We would like to know which country this has been requested? May be we will get more comments if the same is required for any other country. So, comments we get here would be useful to understand how widely this is required.

Kind Regards,

Rajith


Hi Rajith,

Thank you for reaching out!

Yes, your understanding is correct. This requirement is for a North American customer (located in Canada).

We are also looking into the below developments for ISO20022.

  1. Generating an integrated payment file (connecting all payment types such as WIRE, EFT, ACH & Cheque)
  2. Generating a cheque payment file using ISO20022 (Including defining ‘cheque remittance’ details and ‘Cheque number’ in the XML file)
  3. Generating E-Transfer payment file using ISO20022

We have noticed that these functionalities aren’t fully supported in core functionality.

Could you please advise whether we have to report this to IFS to consider for future developments? 

Best Regards
Sugandi 


Hi @Rajith Ekanayake

 

Just to follow up on this issue. May I know if R&D has taken any decisions on these missing ISO2002 related functionalities?

 

Best Regards

Sugandi 


Hi @Sugandi Nadeeshika 

I have not heard pain.008.001.02 based Direct Debiting requirement yet from the NA region. This is not yet supported in the IFS Core solution as any currency payment and this is only available for Single Euro Payment Area member countries for SEPA Direct Debit payments. When I see your comment, it looks like your customer is trying to use ISO20022-based credit transfer payment (i.e. Pain. 001.001.03). ISO20022-based electronic fund transfer is fully supported in IFS standard solution except for the Check payment. If the customer wants to use Check payment via ISO20022, they must go for customization (We have already done this to one of our IFS customers). Further, based on your customer’s bank, it might be required to do some minor adjustments to the Core file. 

 


Hi @Eranda ,

Thank you very much for your response. I would be grateful if you can help me with clarifying following,

Regarding Customer Pre-Authorized Payment

I have further reviewed customer’s & bank’s requirements after the details you have shared. The guideline document shared by the bank states as follows,

 

Also, I can find a section stating ‘Direct Debit Transaction Information’ in this requirement document. Since it states ‘direct debit’, can this be ISO20022-based credit transfer payment (i.e. Pain. 001.001.03)? Could you please advise? 

The client’s expectation under this is to automatically charge from their customer’s bank account, based on pre-authorization they have received. Since pain.008.001.02 is not yet support by core IFS, is our only alternative to continue using Pain. 001.001.03, subject to a customization? 

 

Regarding E-Transfer payment file using ISO20022

May I know if we have the ‘password masking’ option available as part of IFS Core solution, when using an E-Transfer file as per ISO20022? The customer requirement is to encrypt the password while sending the XML file. 

 

Best Regards

Sugandi 


@Sugandi Nadeeshika 

pain.008.001.02 is referring to Customer Direct Debit payments and it does not support Core solutions for non-SEPA member countries such as Canada or USA. You cannot use a standard credit transfer payment file for this purpose. Please double-check which country they are going to use this format, If they have a use case for NA region, you have to go for customization, which will be a bit challenging without having full source code access. There is a pre-requisites flow call “Mandate Management” for the direct debiting process in order to register the customer’s pre authorized agreement. 

 

Password Encryption:

There is no standard solution to encrypt the file from IFS side. However, you can include an encrypting solution as a modification. 

 

 


Hi @Eranda ,

Thank you for your prompt response. 

The used case for pain.008.001.02 is for a customer in NA region. Hence, we are thinking of going for a customization for that, since standard application doesn’t support it yet. One last question regarding following fact please,

“There is a pre-requisites flow call “Mandate Management” for the direct debiting process in order to register the customer’s pre authorized agreement.”

  • is there any mandatory requirement to maintain customer’s pre authorized agreement details in the application if we are using ISO20022 Pre-Authorized payments? If we customize the payment file generation process and maintain agreement details separately, will that be okay? 

Best Regards

Sugandi 

 


@Sugandi Nadeeshika 

It is recommended to keep the mandate details stored within the application since you have to fetch the Mandate number and some related details to the file. If you maintain a separate window, make sure you keep the required info. e.g. Mandate ID and Date of signature. 

But, there can be complex scenarios when the supplier’s bank details or supplier details are modified. In this case, your customer should include Amendment details in the first file after the details are changed. You have to capture those details, if you are building a solid solution.

 


Hi @Eranda - Thank you for the clarification. 


Reply