Presentation Transcript

1. Break-out: practical questions

2. Discussed topics The schemes: Core vs B2B Mandate lifecycle management R-message flows R-message timings The migration in practice: what to know Remaining questions
3. What is the core Scheme? mandatory scheme, to which all SEPA-compliant banks must adhere mainly intended for business to consumer collections mandates can be automatically migrated possibility of refund by debtor different dates compared to B2B scheme
4. What is the B2B Scheme? Optionalscheme, with the followingcharacteristics: Not all banksadhere to the B2B scheme (virtually all belgianbanks have signed up though) No refund right fordebtor No unauthorizedtransactions: debtorbanks must verifymandate Specific B2B mandate Alsoapplicableonmicro-enterprises (<10 employees, turnover < 2m EUR) Different timelinescompared to Core scheme Creditor-centric: debtorwaivesprotection as set forthby PSD SDD B2B only possibility in Belgium to avoid refund  All amendments must be confirmed by the debtor!
5. SDD: core vs B2B SDD Core scheme for C2B transfers or between enterprises. SDD B2B scheme is optional for transfers between enterprises.
6. Mandate lifecycle management A mandate can be for one-time use: one-off (OOFF) Or for recurrent use: recurrent Recurrent mandates have a lifecycle that must be adhered to: First collection: FRST All collections after first successful collection: RCUR Final collection: FNAL  Xml tag: Sequence Type (SeqTp) The sequence impacts submission times
7. Mandate lifecycle management Next to recurrence, mandates must be amended in case of changes Only one amendment impacts the recurrence: First again: only in case of change of debtor bank (debtor agent) Implies a change in submission times All other amendments don’t affect recurrence: Change of creditor name Change of creditor ID Change of mandate ID Change of account within bank Not mentioned in Febelfin guidelines, but mandatory according to EPC; important for international customers!
8. Mandate lifecycle management Specific case: change of debtor bank: Change of debtor bank Change of debtor account Change of debtor account mustn’t be mentioned (logical consequence of changing banks) Change of debtor bank: SeqTp: FRST Old debtor account: not referenced (of no use to the new debtor bank) Original debtor bank (OrgnlDebtrAgt): SMNDA (same mandate, new debtor agent)
9. R-message flows PAIN.007: Reversal message Pre-settlementflows Creditor Debtor Request forcancellation The Creditorsubmitted the file twiceor wishes to withdraw the submitted file Debtor Bank Creditor Bank
10. R-message flows No fixed message: debtor calls his bank for refund Pre-settlementflows Creditor Debtor Reject: collections divertedfromnormalexecution prior to interbanksettlementfor a number of reasons Refusal: The Debtorrefuses the collection (noreasonrequired) towards the Debtor Bank. Debtor Bank Creditor Bank
11. R-message flows PAIN.002 status message Pre-settlementflows Creditor Debtor Reject: collections divertedfromnormalexecution prior to interbanksettlementfor a number of reasons Debtor Bank Creditor Bank
12. R-message flows Shown in CODA or bank/Isabel internal account information Post-settlementflows Creditor Debtor Return: rejectaftersettlement Reversal: request forcancellation Refund: debtor wants the collectionturned back Debtor Bank Creditor Bank
13. R-message flows PAIN.002 status message Post-settlementflows Creditor Debtor Reversal: request forcancellation Debtor Bank Creditor Bank
14. R-message flows Shown in CODA or bank/Isabel internal account information Post-settlementflows Creditor Debtor Return: money returned after settlement (e.g. When refund requested) Debtor Bank Creditor Bank
15. R-messages & timings
16. Practical approach to the migration New mandate vs existing mandate All existing mandates are migrated by means of migration file Can be downloaded in Isabel 6 after request with creditor bank Can be requested as test case Creditor is free to determine launch date of SDD Migration file follows strict layout, can be imported in ERP National Bank has migrated all DOM80 data & account numbers to SDD compliant data & IBAN/BIC Contains all extra information contained in SDD mandate Only concerns B2C mandates!
17. Practical approach to the migration STEP 1: request permission to creditor bank to obtain creditor scheme ID (=equivalent of creditor ID) STEP 2: Request migration file to the bank & compare with current debtors in ERP STEP 3: Test the different files & routines Amendments Sequences Splits STEP 4: Choose between B2B and core
18. Combining sequences & schemes Combining within one physical file (Group level): You can’t mix B2B & core in one physical file Combining within one payment batch: possible within physical file, but split on PmtInf level You can’t mix FRST and RCUR in one logical file (Payment) Only one requested collection date per logical file (Payment)

19. Questions sent beforehand

20. Questions Hoe wordt de klant/schuldeiser geïnformeerd omtrent al of niet uitgevoerde SDD-opdrachten wanneer hij geen CODA heeft. Dus hoe is de afhandeling van de boodschappen omtrent SDD? Welke programma’s heeft de schuldeiser ter beschikking om de mandaten te beheren in Isabel?
21. Questions CORE / B2B Verschil tussen beide? Kan je beide combineren in 1 DD-xml-file? Klopt het dat niet alle banken B2B ondersteunen?
22. Questions Hoe omgaan met wijzigingen aan identificatie schuldeiser, mandaatreferte, datum ondertekening, rekeningnummer klant? Verschil tussen beide? Wijzigingen aan identificatie schuldeiser, mandaatreferte, datum ondertekening, rekeningnummer klant worden niet doorgegeven in het XML-bericht maar worden behandeld als ‘eerste invordering’ (FRST). Dit is een vereenvoudigde manier om het doorgeven van wijzigingen te vermijden. Wijzigingen aan identificatie schuldeiser, mandaatreferte, datum ondertekening, rekeningnummer klant worden wel doorgegeven in het XML-bericht (= veel complexer)
23. Questions Wat houdt de omschakeling van DOM80 naar Europese domiciliëring in? Te volgen stappen? Hoe omgaan met terugbetalingen? (bij Europese domiciliëringen kan dit niet meer)
24. Questions Hoe nauw zijn de grote ERP- leveranciers zoals Oracle en SAP hierbij betrokken?
25. Questions SDD Wat is correcte lay-out van dit bericht, en de laatste versie? Momenteel verschillen de documenten Febelfin en XSD-schema. Hoe met buitenlandse SDD? Blijkbaar lukt dit nog niet voor een aantal Nederlandse banken. Info voor overgang van de DOM80 naar Direct Debit Core?
26. Questions Focaliser sur l’état de la connaissance SEPA au niveau du marché et les modes de communications qui permettraient de mieux sensibiliser les entreprises
27. Questions Voor ERP-softwareontwikkelaars: Het SEPA-bestand bevat ter controle een ‘som bedragen’. Voor zover wij weten is dit de enige voorziening die de integriteit van het bestand kan waarborgen. Gezien de eenvoud waarmee dit manueel kan gewijzigd worden, vragen wij ons af of er nog mogelijkheden zijn ter voorkoming van het aanpassen van deze bestanden. Bv. Hash totaal controle.
28. Questions Uitleg e-mandates SDD Hoe moet een debtor zijn SDD-mandaat annuleren bij de creditor? Via aangetekend schrijven zoals testaankoop adviseert? Verplichte bevestiging van de annulatie door de creditor? Via de bank van de debtor?
29. eMandates: the pull model Routing service Validation service
30. In short: the pull model The customer enters a form on the creditor website The creditor sends this form to a central Routing Service which “calls” the debtor bank’s authentication framework (the Validation Service) The debtor electronically signs the mandate by means of a Validation Service The validated mandate, together with the reference to the signature, is sent back to the creditor, again using the Routing Service. No paper flow required Conforms to European requirements
31. The “pull” model in practice Debtor bank Signature window Enter pin: Routing service Sign Zoomit Validation service
32. Questions Serait-il possible de rappeler les différentes (?) échéances et leurs contraintes ?