Devices & Hardware

Multi-Currency Bulk Payments XML File Format

Description
Multi-Currency Bulk Payments XML File Format This document is the property of AIB Group. No official or other user of this document, may, without the prior written permission of the Bank,
Published
of 48
168
Published
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Similar Documents
Share
Transcript
Multi-Currency Bulk Payments XML File Format This document is the property of AIB Group. No official or other user of this document, may, without the prior written permission of the Bank, disseminate the contents in whole or in part to any person outside the AIB Group 2 Multi-Currency Bulk Payments XML File Format Contents 1. Overview Page Payment Types Page 4 2. General Comments Page XML File Structure Page The Character Set Page Multiple Occurrences of Data Page Recipient/ Account Details Page Charge Bearer Page 9 3. The Multicurrency (MCY) PAIN.001 File Page Page Group Header Page Payment Information Block Page Transaction Information Page Organisation or Private Identification Page Organisation or Private Identification Page Organisation and Private Identification Page Organisation or Private Identification Page 28 Appendix 1 Eligible Currency Codes and Decimal Places Page 32 Appendix 2 Country Codes Page 33 Appendix 3 Clearing Code Table Page 40 Appendix 4 Sample MCY XML File Page 41 Appendix 5 Revision History Page 46 This document was produced for information purposes only and is for the exclusive use of the recipient. No guarantee is made regarding the reliability or completeness of this document, nor will any liability be accepted for losses that may arise from its use. 3 1. Overview ibb is an internet based cash management system that provides balance and transaction information and single and bulk payment services. Linking with your Accounts Payable or ERP System, the Multicurrency (MCY) Bulk Payment Upload facility allows you to upload via ibb, in a single file, payment instructions and remittance data going to beneficiaries in the SEPA zone (including Ireland) and worldwide. The purpose of this document is to describe the MCY XML file format requirements, the layout of the file and the validation that will be performed. 1.1 Payment Types The table below details the types of payment that are supported in the file: Product SCT or Non-SCT Definition Debit Posting SEPA Credit Transfers (SCT) SCT All non-urgent euro payments debiting an AIB Branch Account going to an SCT reachable bank in Ireland and the SEPA Zone * A single debit will be posted to the Branch Account for all payments within the same payment block in a file regardless of how many individual payments are made from contained in the block. Recipient IBAN is mandatory. The two lines of debit narrative on the nominated account will be: Line 1 First 18 characters of the reference populated by you in the Customer Reference field at the time of file upload. Note: If you are submitting your file via SFTP or Connect Direct, the first 18 characters of the value populated in the Message Id field of the Group Header will appear as the first line narrative. Line 2 PFXXXXXXXXXXXXXXXX where PF stands for Payment File and XXXXXXXXXXXXXXX is the unique file reference generated by AIB when the file is uploaded. GBP Payments going to the UK at the debit of a Account Non-SCT Payments in GBP (Sterling) debiting an account with Sort Code , going to a recipient bank in the UK. The recipient bank must be connected to the UK FPS and/or CHAPS clearing systems. Debit entries for each payment are posted individually to the respective Account. The two lines of debit narrative will be: Line 1 GTSOGBCXXXXXXXXX a unique payment reference applied by AIB Line 2 18 characters of free text available to you. If you do not provide a reference, the value will be the first 18 characters of the recipient s name. All other International Payments Non-SCT 1. Euro payments debiting an AIB Branch Account going to a recipient bank outside the SEPA zone. 2. Non-euro payments, debiting an AIB Branch or AIB Currency Account going to a recipient bank in Republic of Ireland and worldwide. A debit entry for each International Payment is posted individually to the respective debit account. The two lines of debit narrative on the nominated debit account will be: Line 1 SPXXXXXXXXXXXXXX or GTSXXXXXXXXXXXXX a unique payment reference applied by AIB Line 2 18 characters of free text available to you. If you do not provide a reference, the value will be the first 18 characters of the recipient s name. 4 Multi-Currency Bulk Payments XML File Format Product SCT or Non-SCT Definition Debit Posting Payments within AIB 1. Euro and non Euro payments debiting an AIB Branch account and crediting an AIB Currency account. 2. Euro and non Euro payments debiting an AIB Currency account and crediting an AIB Branch account. A debit entry for each payment is posted individually to the respective debit account. Debit Reference = Line 1 = GTS Reference Line 2 = 18 characters of free text available to you. If you do not provide a reference, the value will be the first 18 characters of the recipient s name. Credit Reference = Line 1 = GTS reference Line 2 = Originator Name * SEPA Zone = See Appendix 2 Country Codes for list of countries that are currently SEPA reachable. Please note that ibb does not aggregate multiple payments to the one recipient into one single payment. 2. General Comments The XML format of this file is based on an XML standard published by the ISO organisation. ISO defines the formats for files used in the financial area. The format of the file to be used to submit Payment Instructions is part of the Payment Initiation (PAIN) suite. For Credit Transfers, the specific format is called PAIN.001. The version that AIB has used for these formats is pain The XSD validations attaching to these formats can be downloaded from the ISO20022 web site at page#paymentsinitiation3 Payments that have the same requested execution date, debtor account and transaction currency should be grouped together in a block within a payment file. There is a limit of 25 payment blocks per file. AIB will not accept files containing more than 25 payment blocks. 2.1 The XML file structure: A file must contain a single (Envelope), which contains one single XML message. The message is composed of 3 building blocks: 1. Group Header Block: This building block is mandatory and present once. It s function is to identify the file. It contains elements such as Message Identification, Creation Date and Time, Grouping Indicator. 2. Payment Information Block: This building block is mandatory and repetitive. It represents a logical grouping of your payments. It contains elements relating to the debit side of the transaction, such as the Account, Requested Execution Date and Currency for the transactions contained in the block. 3. Transaction Information Block: This building block is mandatory and repetitive. It represents the actual payments that you wish to make. It contains, amongst others, elements relating to the credit side of the transaction, such as creditor/recipient account and remittance information. 5 The diagram below shows how the is composed: Group Header Payment Information 1 Transaction Information 1 Transaction Information 2 Payment Information 2 Transaction Information 3 Transaction Information 4 Transaction Information 5 Payment Information 3 Transaction Information 6 The table below shows how these blocks are to be coded within the actual XML file. 6 Multi-Currency Bulk Payments XML File Format The XML Node column shows the xml node name used to describe the data (e.g. a node is used to start the file. The file will be ended with a / node. All the xml within these nodes are part of the file. The + signs in the XML Node column indicates the depth of the xml sub node e.g. the CstmrCdtTrfInitn is a subnode of , GrpHdr is a subnode of CstmrCdtTrfInitn etc. XML Node Cardinality Comments Only one per file Currently need to define the namespaces: xmlns:xsi= xmlns= urn:iso:std:iso:20022:tech:xsd:pain CstmrCdtTrfInitn ++ GrpHdr (Group Header) Only one per Only one per CstmrCdtTrfInitn One or more per CstmrCdtTrfInitn The Group Header Block +++CdtTrfTxInf One or more per PmtInf The Transaction Information Block: The actual Payment Instructions 2.2 The Character Set: The MCY XML format can support a range of characters, as follows: 1. a b c d e f g h i j k l m n o p q r s t u v w x y z 2. A B C D E F G H I J K L M N O P Q R S T U V W X Y Z A Payment Information Block. This is a logical grouping of Payment Instructions (CdtTrfTxInf blocks below) in a file. All the Payment Instructions within a Payment Information Block must be for: The same Account, The same Requested Execution Date and The same Transaction Currency 4. /? : ( )., + These characters are also valid characters but they should not be inserted as the first or last character within any field. If invalid characters are included within the file, they may be substituted by a space or the file may be delayed and/or not processed by AIB. Examples of invalid characters include ß Å and & 5. Space 2.3 Multiple Occurrences of Data: The XML file allows certain information to be specified at either the Payment Information Block level or Transaction Information Block level. For example, the information for any given payment can be specified at Payment Information Block Level or at Transaction Information Block level. If it is populated in both levels, the file will be rejected. The table below will specify the tags that this restriction applies to. 7 2.4 Recipient/ Account Details EU legislation states that for SEPA Credit Transfer (SCT) payments, the Recipient s IBAN must be used to specify the recipient s account. For all other payment types, the following information must be provided: 1. SWIFT BIC of the Recipient Bank 2. Recipient s IBAN number OR 1. SWIFT BIC of the Recipient Bank 2. Recipient Bank Sort Code/Clearing Code 3. Recipient s Account Number Exceptions: For GBP payments that debit a account and credit a bank connected to UK FPS and/or CHAPS clearing systems the following recipient details can be used: SWIFT BIC of the Recipient Bank and IBAN of the Recipient OR Recipient Bank National Sort Code and Recipient Account Number For USD payments going to the US, the following recipient details must be used: SWIFT BIC of the Recipient Bank Recipient Account Number, and; 9 digit Recipient Bank Fedwire/ABA Code Where the recipient bank does not have a SWIFT BIC the following recipient details can be used 9 digit Recipient Bank Fedwire/ABA Code, Recipient Account Number, and; Country Code of the Recipient Bank OR 8 Multi-Currency Bulk Payments XML File Format 2.5 Charges Bearer: This XML tag specifies which party will pay the charges associated with the processing of the payment instructions. For SCT payments, EU legislation mandates that the respective charges are borne by the sender and the recipient of the payment i.e SLEV (Service Level). AIB will default the value of SLEV for SCT payments. Similarly, for most other payment types, where the charges are borne by the sender and the recipient of the payment respectively, the Charges Bearer value is SHAR. AIB will default a value of SHAR for these payment types. In certain circumstances, for example, when sending payments outside the SEPA zone, you may elect to pay both the sender and recipient charges so that the recipient receives the full amount of the payment. In this case, DEBT must be used in the ChrgBr tag. Please see table below for further information on the DEBT charging option. Charging Option SLEV SHAR DEBT Impact on you You pay the AIB charge and the recipient/receiver pays the charges of all other intermediary and/or recipient banks. You pay the AIB charge and the recipient/receiver pays the charges of all other intermediary and/or recipient banks. You pay the AIB charge and the charges of all other intermediary and/or recipient banks. Comment Must be applied to all SCT payments. Used for non-sct payments Payments in EU/EEA currencies within the SEPA zone that involve no exchange on the sending side must be sent using this charging option. Intermediary and/or receiver bank charges may, in some cases, be deducted from the payment amount, before it is credited to the recipient s account. DEBT can only be used for: (1) Payments in an EU/EEA currency to SEPA zone destinations, where the currency of the debit account is not the same as the payment currency i.e. there is a currency conversion. (2) All other international payments if you select this charging option, your account will be debited with the AIB charges and with all other bank charges when notification is received from the relevant bank(s). Note: Foreign bank charges may take some time before being sent to AIB and applied to your account. Our recommendation is that, as far as practical, AIB customers should exercise caution when using the DEBT charging option as it may result in substantial charges being passed back to you. (1) EU/EEA currencies include the following: EUR euros, GBP Pound Sterling, CHF Swiss Franc, CZK Czech Koruna, DKK- Danish Krone, HUF Hungarian Forint, NOK Norwegian Krone, PLN Polish Zloty, SEK Swedish Krona. The following EU/EEA currencies are not currently available for sending/receiving international payments: BGN Bulgarian Lev, ISK Icelandic Krona and RON Romanian Leu. (2) SEPA Zone = EU Member States (including Ireland) and Iceland, Liechtenstein, Monaco, Norway, San Marino and Switzerland. 9 AIB endeavours to limit the amount of charges applied by intermediary (agent) banks, by routing payments through recognised clearing and settlement systems directly to the recipient s bank (e.g. STEP2 and Target2) or through preferred intermediary banks. The extent of the intermediary network required to allow us send payments to most countries in the world means that it is practically impossible for us to provide details of other bank s charges prior to our customers making a payment. 3. The MCY PAIN.001 File: The table below shows ALL the allowable XML tags, how they should be formatted and how they will be validated by AIB. The format for all tags is Alpha Numeric unless otherwise stated. The XPATH listed below for each field is the location of the field within the file. 3.1 Each file must begin with ?xml version= 1.0 encoding= UTF-8? xmlns= urn:iso:std:iso:20022:tech:xsd:pain xmlns:xsi= 3.2 Group Header Generic Field Name XPath Mandatory/ Optional Max Length Format/Comments GrpHdr Block Message Id ++ GrpHdr +++ MsgId Creation Date/Time Header No of Transactions Header Control Sum ++ GrpHdr +++ CreDtTm ++ GrpHdr +++ NbOfTxs ++ GrpHdr +++ CtrlSum M 35 Customer reference. This field can contain your own reference to assist you in identifying the file. If you are submitting your file using SFTP or Connect Direct, the first 18 characters of the value populated in this field will appear as a second line narrative on the debit account statement. M 19 This is the Date/Time that the file is created. YYYY-MM-DDTHH:mm:SS Example: CreDtTm T08:35:30 /CreDtTm M 15 This is a numeric field detailing the total number of transactions in the file. [0-9]{1,15} M 18 This value should be the total sum of all payments within the file (ignoring their currencies e.g $ = ) Decimal place must be included where applicable. 10 Multi-Currency Bulk Payments XML File Format Generic Field Name Initiating Party Organisation Id XPath ++ GrpHdr +++ InitgPty OrgId Othr +++ Mandatory/ Optional Max Length Format/Comments M 35 This is the Originator Identification Number (OIN). It will be validated against the OIN agreed with AIB. Sample OIN = IEXXMCYZZZZZZ where XX is a check digit and ZZZZZZ is a 6 digit identification number. 3.3 Payment Information Block Generic Field Name XPath Mandatory/ Optional Max Length Format/Comments Payment Information Id Payment Method Batch Booking Block Number of Transactions Block Control Sum +Id +++ PmtMtd +++ BtchBookg +++ NbOfTxs +++ CtrlSum PmtInf Block M 35 An identification assigned by you to identify the Payment Information Block within the file e.g. USD Supplier Payments. We recommend that you use a unique identification reference for each Payment Information Block within the file. This information will also be quoted back to you in a PAIN.002 file in the event of payment rejects. M 3 This field must contain the three letters TRF. O 5 Value can be true or false. Please note AIB will batch all SCT payments within each Payment Information Block, thereby resulting in one debit. M 15 This is a numeric field detailing the total number of transactions in the Payment Information Block. [0-9]{1,15} M 18 This value should be the total sum of all payments within the Payment Information Block. Decimal place must be included where applicable. The following six fields relate to Payment Type Information PmtTpInf and can appear either in the Payment Information Block or Transaction Information Block but not both. If used, the European Payments Council (EPC) recommends that they are included at Payment Information Block level and not at Transaction Information Block level. Instruction Priority +++ PmtTpInf ++++ InstrPrty O 4 Value can be HIGH or NORM. Please note AIB will treat payments received in a bulk payments file as normal priority (NORM). 11 Generic Field Name Scheme Identification Code Local Instrument Code Local Instrument Proprietary Category Purpose Code Category Purpose Proprietary XPath +++ PmtTpInf ++++ SvcLvl Cd +++ PmtTpInf ++++ LclInstrm Cd +++ PmtTpInf ++++ LclInstrm Prtry +++ PmtTpInf ++++ CtgyPurp Cd +++ PmtTpInf ++++ CtgyPurp Prtry Mandatory/ Optional Max Length Format/Comments O 4 If you wish to use this tag, specify a value of SEPA. AIB will route the payment via SEPA if appropriate. O 35 Applicable to SCT Payments only. The code entered here must be chosen from a defined list of ISO codes. Please refer to the most recent ISO documentation for further information; See note in Local Instrument Proprietary field below. O 35 Applicable to SCT payments only. This tag can only be used if the Local Instrument Code above is not used otherwise the file will fail. O 4 For SCT payments only this tag specifies the purpose of the payment. The code entered here must be chosen from a defined list of ISO codes. Please refer to the most recent ISO documentation for further information; O 35 This tag can only be used if the Category Purpose Code above is not used otherwise the file will fail. 12 Multi-Currency Bulk Payments XML File Format Generic Field Name Requested Execution Date XPath +++ ReqdExctnDt Mandatory/ Optional Max Length Format/Comments M 10 YYYY-MM-DD AIB will accept files with requested execution dates up to 30 calendar days into the future. The value entered on the FIRST Payment Information Block should be the earliest debit date in the file. Name +++ Dbtr ++++ Nm Postal Address Country Postal Address Line 1 Postal Address Line Dbtr ++++ PstlAdr Ctry +++ Dbtr ++++ PstlAdr AdrLine[1] +++ Dbtr ++++ PstlAdr AdrLine[2] The information contained in this tag will be used as part of the file duplication check. AIB will identify files as being potential duplicates if they have the same OIN number, Header Control Sum and Requested Execution Date. M 70 This tag should contain the name of the account owning entity making the payment. The name populated in this field will travel with the O 2 AIB will substitute this value with the country code of your account. M 70 AIB will substitute this value with the first line of the debit account address. M 70 AIB will substitute this value with the second line of the debit account address. The xml at this point may include additional information regarding your Organisation or Private Identification. This information is optional and is not required for processing of the payments. Its purpose is to identify you to the recipient (provided you have agreed with them that that is how you should be identified). It only applies to payments transmitted through the SEPA scheme. Account +++ DbtrAcct IBAN See Section 4 Organisation or Private Identification). M 34 [A-Z]{2,2}[0-9]{2,2}[a-zA-Z0-9]{1,30} Must be in IBAN format. This is the account number from which the payments in this b
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks
SAVE OUR EARTH

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!

x