Upcoming changes for SEPA

[monofone]

http://www.ebics.de/spezifikation/dfue-abkommen-anlage-3-formatstandards/

[BorislavSabev]

@monofone also some banks will stop requiring the FRST payment for subscriptions as the whole process is quite unstable. This will happen for sure in France within 1 year.

This doesn't affect the library itself but I wanted to mention it.

[osopolar]

As stated in link of first post it will happen on 2017-11-19. Just wondering if would be fine to not use sequence type FRST anymore, just RCUR (using pain format pain.008.002.02)?

[BorislavSabev]

@osopolar you can use only RCUR but it dependens on the bank(s) you're working with. I have been doing this since 3 months - i.e. we switched from a FRST-then-RCUR-then-FNAL system to just RCUR.

[osopolar]

If I would just use RCUR, do I need to check for time-limits anyway. AFAIK the Transfers need to be submitted 5 TARGET2 days before due date for FIRST and 2 TARGET2 days for RCUR and FNAL.

I am working with Deutsch Bank.

[BorislavSabev]

I haven't noticed any rejects because of execution date in my practice. That said if you have information on the exact Reject Reason received in such cases please share it :)

You have to understand that while ISO20022 (and its subset SEPA) are standards, each institution will implement them a touch differently where they can. Thus we are in this situation that what the standard mandates could be validated a bit differently from different banks. And they could all have different per-validation & validation rules. Some banks will not even allow a transfer to be initiated when they absolutely know that it is going to be rejected by SEPA.

Thus it is important to check the rule set of the bank you are sending your files to (not the other party's banks).

[osopolar]

@BorislavSabev how do you transfer the SEPA-XML to the bank?

Today I called the Deutsch Bank hotline, they told me, that at least their online-banking makes sure that the due date will be 5 or 2 working days in advance for FRST and RCUR transactions. Starmoney probably should do the same, otherwise there should be an error. Although it the documentation allows the use of RCUR instead of FRST it does not say anything about changes in the time limit of execution date. So I guess it's still 5 days for the first RCUR and 2 days for the following RCUR's. That way I can't see any advantage using RCUR instead of FRST. But maybe it's important for collecting direct debit. Different Sequence Types could not be mixed in one sepa-xml file for collecting direct debit – multiple transfers for one payment (one call to TransferFileFacadeFactory::addPaymentInfo() and multiple calls to TransferFileFacadeFactory::addTransfer()).

[osopolar]

According to SEPA Direct Debit Payments: SEPA Rulebook Changes the FRST to RCUR changes will effect the collection time:

Firstly the current requirement to use the sequence type ‘FRST’ when submitting a new direct debit mandate will no longer apply. Instead, if preferred Creditors can use the sequence type ‘RCUR’ for all transactions be it the first payment collection or any of the payments in a series of collections for the lifetime of the mandate (i.e. where the direct debit mandate is recurring). This change will remove the confusion regarding which sequence type to use and if implemented by Creditors will also eliminate R transactions (failed payments) relating to sequence types. Worth noting, the current sequence types remain valid if Creditors wish to continue using them.

Secondly, Creditors will be able to avail of shorter end to end payment processing times. Currently direct debit files need to be submitted (to the bank) in a D-5 and D -2 timeline for FRST and RCUR sequence types respectively. The result of moving to a RCUR sequence type only will mean Creditors will collect the first payment of a newly established direct debit mandate quicker i.e. D – 2. Your bank may have advised that D-1 submission times will be available, this will be dependent upon getting the file(s) to the bank before a defined cut-off time e.g. 11am on D-1.

[ashish-dirkmedia-de]

Is the library already with http://www.ebics.de/spezifikation/dfue-abkommen-anlage-3-formatstandards/ I am using this library and want to know what changes do I need to adapt with the new guidelines.

[monofone]

On a first glance I couldn't spot any special cases, just something about not to use the PstlAdr for pain.001.001.03 this is something possible to use at the moment.

For pain.008.001.02 you shouldn't use it either, but it is only implemented for pain.008.003.02