IBOS MT101 to Initiate Pacs SCT

IBOS ASSOCIATION

Projecting SEPA Scheme Transactions back onto MT101 Follow-up to Workshop on Mapping SEPA Messages held on 15th/16th November 2006

Date: 20th April 2007

From: R J Lyddon

Background  It was agreed at the SEPA XML Workshop at KBC in Brussels on 15/16 November and confirmed at the GSL WG in Madrid that it would desirable to reach a common position on how to initiate the SCT via MT101  While we have a comparison table between ISO, SCT and MT101, we needed to draw out from it a layout of MT101 specifically  We can then cross-check that against the comparison table and then also against a comparison we have from SWIFT of SCT and MT103  Likewise we needed to ensure consistency and mapping between 101/SCT and SCT’s appearance in MT940 and 942 (which is a separate stream in IBOS)  Lastly we have updated our documents containing our direct comments on pain SCT and pacs SCT  This document is the first draft for an MT101 that would result in pacs SCT

Process  We now have a document that can be used as a basis by the SCT Project  The layout of MT101 to result in a SCT is a deliverable from that project  Credeuro will not be replaced as from 2/1/08  Some IBOS banks may not allow customers to create an SCT off an MT101  But others do want this deliverable and to incorporate it into the MT101 GSL specification – but not replacing Credeuro

Approach  All fields in MT101 Sequence A are laid out as per SWIFT Standards Release Guide – and the equivalent data elements in pacs SCT are set against them, highlighting differences in field sizes and other issues; most likely fields filled are highlighted  Same then for MT101 Sequence B; most likely fields filled are highlighted  List of Mandatory Fields in pacs SCT which can be system-filled by the Receiver of the MT101 and do not need to be in the 101 itself  List of Mandatory Fields in pacs SCT which, cannot be system-filled by the Receiver of the MT101, they have to be database-filled by the Receiver or given by the Originator – and list of issues

of 6 IBOS MT101 to initiate pacs SCT February 2007

MT 101 Sequence A

“EPC Field Name” is how this data element is referred to in the “Interbank Payment Dataset” (DS-02) in the SEPA Credit Transfer Implementation Guidelines v2.2. Where a field in 101 is shorter than EPC equivalent, the 101 contents can be mapped to pacs – and then through to 940/942

Field MT101 filling EPC Field Name Issues 20 Mandatory; 16 characters NB this does not become AT-43 21R Optional; 16 characters. Not relevant. If filled here, Does not become AT-41 Originator’s Reference to Pacs payments all individual, even if Originating single debit is requested for all items in Sequence B and the Credit Transfer, otherwise would be carried into Bank performing single debit/multiple MT101 in all items in any chained 101s all related SCTs 28D Mandatory, even if chaining not being used Not relevant to the individual pacs message 50a 50a must be present in A if all Sequence B items are If there is an instructing party that is not the “Ultimate Debtor” not adopted in v2.2. Frustrates (Instruc.) being debited to same account account owner, this is “Ultimate Debtor” replicating the relationship “Instructing “Instructing Party” is then filled when instructing Party”/”Ordering Customer”, especially if the customer is not also the account owner “Instructing Party” is not in the invoice chain but acting as agent 50a 50a must be present in A if all Sequence B items are Using Option H: GSL to agree how executing bank will want (Order.) being debited to same account AT-01 Account Number of the Originator (IBAN) “Name & Address” presented including Ordering Customer is filled when instructing party is the AT-02 Name of the Originator (up to 70 characters) “Country” in 2-charac ISO layout, with option of Optional account owner to which all Sequence B payments are to AT-03 Address of the Originator (up to two AT-10 with Country of Residence if Originator but often be debited instances of 70 characters each) wants to use Organisation Identification instead present Using Option H we can collect all three pieces of data Or of Address needed for pacs SCT Using Option G The data has to be presented so as to facilitate “Account” = IBAN AT-01 Account Number of the Originator (IBAN) mapping into their respective fields in pacs SCT But we can allow BBAN in IBOS because the Executing The BEI is presented as AT-10 Originator’s If BEI is used, check GSL to see if acceptance is Option H allows up to 34 characters for IBAN but then Identification Code up to 35 characters mandatory or if a bilateral agreement is needed only 140 in total for “Name & Address” between the two IBOS banks Using Option G as per current GSL, a BEI is sent and the pacs Originating Bank is assumed to be able to extract Name&Address from its databases and add it 52a Not to be used; the Receiver of the MT101 in IBOS N/A holds the account to be debited 51A BIC Sender of the MT101 that gives rise to a pacs SCT Sender of the MT101 that gives rise to pacs SCT not included in the pacs SCT not regarded as “Instructing Agent” 30 Mandatory – 6 characters Is related to, but is not exactly, AT-42 Settlement “Requested Execution Date” in MT101 X cut-off Requires also an agreed routine for Rejection and Date of Credit Transfer (in form of ISODate) time X service level results in AT-42 in pacs Hold/Process depending on missed cut-off/advance SCT despatch GSL to agree routines for Rejection and Hold/Process 25 Optional and not to be used N/A

MT101 Sequence B

Field MT101 filling EPC Field Name Issues 21 Mandatory up to 16 characters; unique transaction AT-41 Originator’s Reference to the Credit AT-41 can be up to 35 characters. If IBOS reference = E2E Identification in Scheme terms; would Transfer (being the E2E Identification) agrees on only 16 characters, we can map through to MT940 Field 61 subfield 7 handle it here and in 940/942 in 61/7 21F No, no FX, so NONREF N/A 23E Optional, should not be used so we follow the line of Options for 23E not relevant since the code Codewords = Value-added and not Core&Basic “SEPA” should go on all SCTs, this being AT-40 Identification code of the Scheme 32B EUR, plus the amount in up to 15 characters, with a AT-04 Amount of the Credit Transfer in Euro – in Note that “Total Interbank Settlement decimal but no “,” between millions and thousands up to 12 characters, with a decimal but no “,” Amount” can be up to 18 characters, with between millions and thousands a decimal but no “,” between millions and thousands 50a “Instructing Party” is filled when instructing customer is If there is an instructing party that is not the “Ultimate Debtor” not adopted in v2.2. (Instruc.) not also the account owner account owner, this is “Ultimate Debtor” Frustrates replicating the relationship “Instructing Party”/”Ordering Customer”, especially if the “Instructing Party” not in invoice chain but an agent 50a Ordering Customer is filled when instructing party is the AT-01 Account Number of the Originator (IBAN) Same issues as against 50a (Order.) in (Order.) account owner to which all the payments is to be debited AT-02 Name of the Originator (up to 70 characters) Sequence A, and against 59a below Using Option H in order to collect all three pieces of AT-03 Address of the Originator (up to two Option H allows up to 34 characters for Optional data needed for pacs SCT instances of 70 characters each) IBAN but then only 140 in total for but “Account” = IBAN preferred Or “Name & Address” present But we can allow BBAN in IBOS because the Executing Using Option G always if Bank can map BBAN in 101 into IBAN in pacs SCT AT-01 Account Number of the Originator (IBAN) not in Using Option G as per current GSL, a BEI is sent and The BEI is presented as AT-10 Originator’s Sequence the pacs Originating Bank is assumed to be able to Identification Code up to 35 characters A extract Name&Address from its databases and add it 52a Not to be used; the Receiver of the MT101 in IBOS N/A holds the account to be debited 56a Filled if relevant to the transaction i.e. if intermediary 1.31 and 2.28 “Instructed Agent” appear to fit, and “Pay via” not usual in IBOS so ignore agent is used then note the EPC Usage Rule for those fields Then Option A BIC “Only BIC is allowed”

Field MT101 filling EPC Field Name Issues 57a Mandatory. Would only not be filled if the payment was AT23 – BIC of the Beneficiary Bank “Books” payments would never need to be “books” within the Receiver of the MT101 – and then it done as SCT would not be an SCT. Option A BIC 59a Mandatory and needs to be the option called “No option AT-20 Account of the Beneficiary (IBAN) Same issues as against 50a (Order.) in letter” so that the SCT can have name and address and AT-21 Name of the Beneficiary (up to 70 Sequence A&B, but here regarding the IBAN characters) Beneficiary Need to cater for usage of an Organisation/Private AT22 – Address of the Beneficiary (up to two Limitation on size of name and address in Identification by the Beneficiary instances of 70 characters) MT101 to 4*35 characters Or Option called “No option letter” allows up AT-24 Beneficiary’s Identification Code (for either to 34 characters for IBAN but then only Organisation or Private one) 140 in total for “Name & Address”

70 Remittance Information 4*35 characters = 140 AT-05 Remittance Information up to 140 AT-05’s 140 characters includes the tags GSL simply agreed to advise customers to use 100 characters so that they are not truncated, not because of whether information is structured or unstructured, but because references could otherwise eat into the available space 77B Regulatory Reporting; could be done as per IBOS GSL Reg Reporting is regarded as optional and is a Its inclusion would represent an AOS. now. Customer would then fill it and Countries should White Fields set of data; out-of-scope until EPC Would then be shared with all banks. Not then tie up with what is in Name&Address fields, definitions emerge worth the effort. including where customers opt for Organisation/Private Identification 33B See 32B; not used N/A – see above; no need to repeat 71A SHA N/A; 2.23 refers and must be populated “SLEV”. SCT is by definition an SHA payment due to Rulebook 25A IBAN or BBAN for any separate charges account N/A not relevant to the interbank message 36 Not used N/A

Mandatory data in pacs SCT that the sending bank of the SCT should be able to add from own processing applications and which therefore does not need to be in the MT101:

 May not be foreseen in 101 at all  May be about files sent from Receiver of MT101 to a third-party bank and including payments initiated in other ways  The ISO fields are in many cases simply for the tags <..>

Index Ref in Name Issues pacs SCT 1.0 Group Header 1.1 Message Identification 1.2 Creation Date Time 1.4 Number of Transactions 1.6 Total Interbank Settlement Amount 1.8 Settlement Information 1.9 Settlement Method 1.10 Settlement Account 1.11 Clearing System 1.20 Payment Type Information 1.22 Service Level 1.23 Code 1.30 Instructing Agent Agreed as not relevant in this case 2.0 Credit Transfer Transaction Information 2.1 Payment Identification 2.1 Instruction Identification 2.2 Payment Type Information 2.4 Service Level 2.5 Code 2.23 Charge Bearer 2.27 Instructing Agent Agreed as irrelevant and please cross-refer to the issue raised against Field 51A above: the Sender of the money would be relevant if it occurred in the IBOS context (which it doesn’t). The Sender of money is not relevant 2.37 Debtor 2.43 Creditor

List of Mandatory Fields in pacs SCT which do not always have to be filled if other data is present. But, if they are needed, they cannot be system-filled by the Receiver of the MT101, they have to be database-filled by the Receiver or given by the Originator – and list of issues:

Index Ref in Name Issues pacs SCT 2.37 Postal Address = AT-03 Address of the If it differs in the bank’s database from what is in the MT101 (RBS FATF Originator interpretation) 2.37 Country – see issue raised against 50a, and Got to be placed here if included in the MT101 specifically as an ISO 2-letter code, or 59a: the 101 must hold this in a place where if included as a name in the 101, it should be transposed as the ISO code. There would the Receiver can map it to pacs be a problem if it was not included in the 101 at all or is merged inextricably with the “Address” or included only in 77B with Reg Reporting. It cannot be taken from the IBAN 2.37 Identification = AT-10 Originator’s MT101 customer always a corporate, so Organisation Identification may be relevant Identification Code - see issues raised against but not Private Identification. 50a, and 59a: the 101 must hold this if the Organisations may decide to opt for this so we might like to cater for it in 101. We parties have agreed to use it instead of have done so if it is a BEI, but otherwise not Address As long as the 101 field length is not exceeded, it is a pass-through 2.39 Debtor Agent = AT-06 BIC of the Originator This is the BIC of the bank that the MT101 was sent to in IBOS, as it is always the one Bank where the debit account is held (so never contents of 52a) 2.43 Country - see issue raised against 50a, and Got to be placed here if included in the MT101 specifically as an ISO 2-letter code, or 59a: the 101 must hold this in a place where if included as a name in the 101, it should be transposed as the ISO code. There would the Receiver can map it to pacs be a problem if it was not included in the 101 at all or is merged inextricably with the “Address” or included only in 77B with Reg Reporting. It cannot be taken from the IBAN 2.43 Identification = AT-24 Beneficiary’s Beneficiary could be an organization or retail customer, so both Organisation Identification Code - see issues raised against Identification and Private Identification are relevant. 50a, and 59a: the 101 must hold this if the Organisations may decide to opt to identify beneficiaries in this way so we should try parties have agreed to use it instead of and cater for it in MT101 – but it is for the Originator to know the data. We might like Address to show them where they should put it in 10, but it isn’t catered for. As long as the 101 field length is not exceeded, it is a pass-through

RJL/20.4.07