Break-out: practical questions

Presentatie over: "Break-out: practical questions"— Transcript van de presentatie:

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? Optional scheme, with the following characteristics: Not all banks adhere to the B2B scheme (virtually all belgian banks have signed up though) No refund right for debtor No unauthorized transactions: debtor banks must verify mandate Specific B2B mandate Also applicable on micro-enterprises (<10 employees, turnover < 2m EUR) Different timelines compared to Core scheme Creditor-centric: debtor waives protection as set forth by PSD SDD B2B only possibility in Belgium to avoid refund  All amendments must be confirmed by the debtor! 4

5 SDD: core vs B2B SDD Core scheme for C2B transfers or between enterprises. SDD B2B scheme is optional for transfers between enterprises. 5

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 Pre-settlement flows Request for cancellation
PAIN.007: Reversal message Pre-settlement flows Creditor Debtor Request for cancellation The Creditor submitted the file twice or wishes to withdraw the submitted file Debtor Bank Creditor Bank

10 R-message flows Pre-settlement flows Refusal:
No fixed message: debtor calls his bank for refund Pre-settlement flows Creditor Debtor Refusal: The Debtor refuses the collection (no reason required) towards the Debtor Bank. Reject: collections diverted from normal execution prior to interbank settlement for a number of reasons Debtor Bank Creditor Bank

11 R-message flows Pre-settlement flows Reject:
PAIN.002 status message Pre-settlement flows Creditor Debtor Reject: collections diverted from normal execution prior to interbank settlement for a number of reasons Debtor Bank Creditor Bank

12 R-message flows Post-settlement flows
Shown in CODA or bank/Isabel internal account information Post-settlement flows Creditor Debtor Refund: debtor wants the collection turned back Reversal: request for cancellation Return: reject after settlement Debtor Bank Creditor Bank

13 R-message flows Post-settlement flows
PAIN.002 status message Post-settlement flows Creditor Debtor Reversal: request for cancellation Debtor Bank Creditor Bank

14 R-message flows Post-settlement flows
Shown in CODA or bank/Isabel internal account information Post-settlement flows 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 29

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 30

31 The “pull” model in practice
Debtor bank Signature window Enter pin: Routing service Sign Zoomit Validation service 31

32 Questions Serait-il possible de rappeler les différentes (?) échéances et leurs contraintes ?