1. EBA CLEARING
M-PEDD TWG Meeting
20th June 2006

2. Technical Working Group Meeting Agenda
Approval of Agenda and minutes
M-PEDD BWG follow-up and TWG roadmap
Questions and comments on Interface Specifications v0.2
AOB

3. BWG Follow-up
New feature: possibility for banks to receive DD instructions either at time of sending or D-5/D-2
BIC Cutover
Message key (TransactionID)
SDD will not support Entry Point
German alternatives timescales: Deferred to a later date

4. Project Aim
Creation of a STEP2 Multi Purpose Pan European Direct Debit Service (M-PEDD)
That supports but is not limited to the SEPA Direct Debit scheme
And in the future:
Can be extended for other SEPA Debit services
Can support Domestic Debit schemes

5. MPEDD Project requirements
The service must go live by 2008
this implies bank testing starting mid 2007
this in turn requires
Central System development beginning July 2006
Bank Participant system development ?Q3 2006
This timing constraint has led to a staged approach
In a first stage we gather sufficient information to start Software development.
In a second stage we define Service characteristics and peripheral (Browser) software requirements.

6. Central System Development
Project Delivery
Software Design
Central System Development
Bank Development
Service Decisions
Testing
Live
Ramp up Strategy
07/06
10/06
12/06
04/07
09/07

7. Service verses Software
Debit products and characteristics
Validation (against mandate information, Creditor DB and Interbank Limits)
Roll out strategy
Business Practices
Pricing / Governance / Legal
Processing Flow
Configuration Options
Message Format
Information storage
Settlement Engine and algorithm
Service
Software

8. Other Working Group Tasks
In subsequent stages work will also begin on:
Business Practices
User Documentation
Ramp Up Strategy
Testing and Acceptance
Considerations for Phase 2

9. Documentation Timetable
Applies to Business Requirements and Interface Spec:
21st June latest versions sent to Steering group for information and comment
30th June Steering Group meets
12th July ISO20022 updates come out
28th July Core documents stable and ready to be used for internal software design.
Work continues
27th October next version sent to Steering Group
24th November final documents published.

11. TWG Deliverables
Interface Specifications v0.2 was released, comments and questions have been collected
Following TWG 20th June meeting, V0.3 will be released
Version 1.0 will be released after v0.3 review and July 12th new ISO XML Schemas delivery
Objective for v0.3 is to clear all issues leaving only XML schemas as possible changes for v1.0

12. Interface Specifications v0.2 Comments and Questions
Tracked through the Excel document (tracking list)
Int. Specs Tab : All the typos, clarifications or general editing issues concerning the document
XML tab : Issues raised with ISO working group (SWIFT) on the available XML Schemas
TWG tab :Issues raised by TWG participants requiring discussions, more details or decision.
Some other questions are answered directly to Participants

13. EBA XML Schemas definition
EBA will provide XML Schemas (variant)
Follow ISO20022 format whenever possible
Allow full length fields even if only a subset of characters is actually used
Fields not present (removed from ISO Schema) are forbidden
Highlight changes to status or format in italic
All BIC are BIC11 but some fields only have BIC8 validation

14. [T1] General questions
Entry Points : SDD will not support EP
Limits : All system limits (nbr files, bulks, etc) will consist of a set of parameters. Exact numbers are not determined yet.
Delays in IDF/DVF processing : Best effort processing but no engagement
File retransmission is a system parameter
SWIFTNET 6.0 SDD/XCT : Request Types will follow same logic
All the Mandate Amendment fields have status Conditional
SIANet not supported

15. [T1] Usage of Instructing/Instructed Agent
IDF
DVF
Field
Level
Status
Instructing Agent
Group Header
Mandatory
Individual Transaction
Not Present
Instructed Agent
Field
Level
Status
Instructing Agent
Group Header
Not Present
Individual Transaction
Instructed Agent
Instructing Agent
IDF
DVF
BANK
STEP2

16. [T1] Usage of Instructing/Instructed Agent
DNF/SDF/CDF
Field
Level
Status
Instructing Agent
Group Header
Not Present
Individual Transaction
Mandatory
Instructed Agent
Instructing Agent
Instructed Agent
DNF/SDF/CDF
BANK

17. [T1] Usage of Instructing/Instructed Agent
RSF (Instructing Agent)
RSF (Instructed Agent)
Field
Level
Status
Instructing Agent
Group Header
Mandatory
Individual Transaction
Not Present
Instructed Agent
Field
Level
Status
Instructing Agent
Group Header
Not Present
Individual Transaction
Mandatory
Instructed Agent
Instructed Agent
Instructing Agent
RSF
BANK1
BANK2

18. [T2] Bulks Creation Rules and Sorting
Bulks are created according to Interbank Settlement Date of the Transaction
R-messages bulks follow the same logic
Rule also applies to STEP2 generated files
Bulks are sorted in a file based on the type of message :
Direct Debits
Request for Cancellation
Rejects
Reversals
Returns

19. [T3] Duplicate Checking
Comments received from Participants indicate that the uniqueness period should be Instruction’s full lifecycle
However this would require Banks to make sure uniqueness keys are not reused
Current proposal is : Uniqueness is verified for a single STEP2 business day

20. [T3] Duplicate Checking - Transaction
Keys for Transaction Uniqueness:
Transaction ID
InterbankSettlementDate
Creditor Agent BIC
Which ID should be used?

21. [T3] Duplicate Checking – Bulk and Files
Keys for Bulk Uniqueness:
Message ID (GroupID)
InterbankSettlementDate
Instructing Agent
Keys for File Uniqueness:
Network File Name (Or File Reference?)
Reception TimeStamp
Sending Institution

22. [T5] BIC Validation and Routing
New proposal from BWG: BIC are validated when instructions are received and not against a future BIC directory or routing table
For Post settlement R-messages: STEP2 still does not archive past routing tables or BIC directory so all rejected R-messages become manual handling

23. [T6] Indirect Participants
File size limits and number of files for Indirect Participants are to be defined
Separate bulks or files are possible for Indirect Participants as long as bulking/sorting rules are met

24. [T6] Direct/Indirect Participant routing
Message routing is done according to Debtor Agent information available in Debit Request
Instructed Agent is the Direct Participant to which the message is routed
DEBIT REQUEST
TO CENTRAL SYSTEM
FROM CENTRAL SYSTEM
Instructing Agent
Debtor Agent
Instructed Agent

25. [T6] Direct/Indirect Participant routing
BIC8 Match? Y
If BIC8 is present in DP routing table, message is routed directly to DP N
BIC11 Match? Y
If BIC11 is present in IP routing table, message is routed to DP N
BIC8XXX Match? Y
If BIC8+XXX is present in IP routing table, message is routed to DP
Note: The Direct Participant is the Instructed Agent of the forwarded Debit Request

26. [T6] Direct/Indirect Participant routing
The Debtor Agent field CAN be either a BIC8 or a BIC11 for a Direct Participant
Only the first eight characters of the Debtor Agent are used for the first matching rule (DP)
Indirect Participants BIC always exist as BIC11 in the Routing table (as ‘real’ BIC11 or as BIC8XXX)
Instructing Agent accepts BIC8 or BIC11 but routing to this Participant (ie. Return or Reject) is done using BIC8 only

27. [T8-T23] Other issues
[T8] Alternate Mandate Flow Usage of LocalInstrument Payment Code : AMF and Amount=0
[T9] CreditorID Using CreditorSchemeID instead of CreditorID
[T10] IBAN Validation Are IBANs validated to make sure account is in Europe?
[T11] Regulatory Reporting Is this structure used in the XML message? Is it optional or mandatory
[T12] STEP2 Migration to RBAC
[T13] German Timetable Proposal

28. [T8-T23] Other issues
[T14]Push and pull Modes Are both modes required?
[T15] Errors and File reject Details on configurable maximum number of errors before file is rejected
[T16] Rejected DD Are they stored? Can the ID be reused?
[T17] New fields for RSF, SDF and CDF Header? Number of Transactions Sum of transactions
[T18] Bulk Creation Date and Time Is the field validated against a rule? Can files be generated on non-STEP2 business days?

29. [T8-T23] Other issues
[T19] Figures for XMl structure definition Are XML schemas to be published enough or are figures need in the document?
[T20] Transaction/Instruction ID/End to EndID Are they all supported? EndtoEndID mandatory?
[T21] XML ISO Compliancy Logic is : - Follow ISO20022 format whenever possible - Allow full length fields even if only a subset of characters is actually used - Highlight changes to status or format in italic - All BIC are BIC11 but some fields only have BIC8 validation - EBA will provide XML Schemas - All Id should be 35x - Fields not present (removed from ISO Schema) are forbidden

30. [T8-T23] Other issues [T22] Use different names for DSR and MRR?
[T23] Copy (or functional copy) of the original transaction Still not clear on how to carry the information
[T24]
Next to being explicit on duplicate check, also have to be explicit on all other validations. E.g. - mandatory fields - reachability (will EBA do routing to other PEACH if debtor bank is not connected to EBA?) - correct values, use of codes (e.g. existing IBAN, existing direct debit type, etc) - AOS for closed community
[T25] Multiple occurences of same data InstrdAmount vs InterbankSettlementAmount RequestedCollectionDate vs Interbank Date
[T26] No use for Initiating Party, Intermediary Agent

31. EBA CLEARING