Applicability in GRIP-Channels............................................................................... 6Uploading PAIN.001 Files..............................................................................................................................6Authorization Procedure ...............................................................................................................................7Mapping Details .................................................................................................................................................7
Appendix: Example PAIN.001 File .......................................................................... 8
2
IntroductionPart of the Single Euro Payment Area (SEPA) legislation is the introduction of a new file format for payment initiation: the PAIN.001 format.
Payment initiation upload using the PAIN.001 format is going to be made available by ABN AMRO Clearing Bank in GRIP-Channels during the second quarter of 2014. PAIN.001 will be available in addition to the already existing instructing methods (i.e. SWIFT MT101, SWIFT MT103 and manual input via GRIP-Channels). Use of the PAIN.001 upload will be limited to the non-urgent EUR transactions in the SEPA zone and must be submitted before the SEPA cut-off time 12:30h (CET).
This document describes the format and usage within ABN AMRO Clearing Bank systems.
PAIN.001 StructureSEPA customer credit transfer instructions are transmitted using PAIN.001 files. There is no practical limitation to the number of instructions in each file, other than system resource limits (such as the maximum file size that an operating system supports or the network capabilities). The files are typically created by administrative software, similar to historic file formats such as the Dutch formats ClieOP03 and BTL91 or the German format DTAUS. The PAIN.001 files are normally too complex to be generated manually.SEPA is becoming common practice: if your administrative software does not support the PAIN.001 format as one of its output options, a next version probably will have that option.
PAIN.001 file batches are XML files that must be structured according to the XML Schema Definition (XSD) pain.001.001.03. This is the recommended version from the European Payment Council, EPC.
ABN AMRO Clearing Bank recommends to verify your PAIN.001 XML files against the schema definition before submitting them. In this way most errors can be caught and adjusted. We also refer to the section Resources below.
XML DetailsThis section describes some of the details of PAIN.001 requirements.
Unique Message IDThe field MsgId in the group header of PAIN.001 files must be unique for each submitted file. The field is used to avoid duplicates: i.e., when a file is re-submitted, then it is rejected based on the occurrence of a duplicate message ID.
Customers are free to apply their own method of choosing unique message ID’s. Typically message ID’s are system-generated sequential numbers (001, 002 etc.), sometimes prefixed by the date (2014-02-11-001, 2014-02-11-002, etc.).
The restriction that is imposed by the XML Schema Definition (XSD) is that the length ofmessage ID’s may not exceed 35 characters.
The message ID is mapped to the Client Reference Number.
3
Example: The message ID in the below snippet is 2014-02-11-MsgId.
Payment Information BlocksA PAIN.001 file must contain at least one Payment information block (PmtInf. In most cases PAIN.001 files contain only one block, with one set of payment instructions.
The purpose of grouping payments in separate PmtInf blocks is the following. General properties, such as the execution date, the debtor, the debited account and the debtor agent are stated once, at the level of the PmtInf block. That way, the payment information of separate transactions can be briefer.
Therefore it may be convenient to place more than one PmtInf block in one PAIN.001 file when, e.g. the file instructs to debit more than one account (in this case, a PmtInf block is required per debited account) or on different dates (in this case, a PmtInf block is required per date, see below for an example).
Payment Information: IDThe first tag in each PmtInf block is the ID PmtInfId. This ID is not further used, neither as a batch identifier (this is the above stated MsgId), nor in individual payments.
Payment Information: Category PurposePAIN.001 files may state a “category purpose” which often invokes special handling at the bank. ABN AMRO Clearing Bank ignores the category purpose. (An example of a category purpose is a batch of salary payments. Most banks will make sure that the individual payments are not reported on end-of-day statements so that the privacy of the employees is ensured.)
Payment Information: Requested Execution DateEach PmtInf block has its own Requested Execution Date, ReqdExctnDt. It is thereby possible to create e.g. one file with two payment information blocks, each with a different date.
For every payment in its PmtInf group, affected by the stated requested execution date, the date is mapped to the payment’s requested execution date, its value date, and its release date.
PaymentsSeparate payments are stated inside their PmtInf blocks, in Customer Transfer Transaction Information blocks (CdtTrfTxInf). Per payment an end to end ID must be stated. This ID may be anything (up to 35 characters), and does not need to be unique.
However, the end to end ID is transported throughout the SEPA chain:• On intermediate bank to bank messages• On statements of the beneficiary• On statements of the instructing party (the debited account).
The purpose of the end to end ID is to make it possible to track payments throughout the SEPA chain. It is therefore advisable to make these ID’s unique and to use them for tracking and reconciliation.
Remittance InformationEach payment must have a remittance information field. This information can be used as identifying information when a payment is rejected or returned, though the end to end ID can be used as well.
5
Remittance information in PAIN.001 files can occur in structured or unstructured format. Both formats are supported. An example of unstructured remittance information is given below.
Structured information allows the optional specification of referred document information (RfrdDocInf), a remittance amount (RfrdDocAmt), creditor reference information (CdtrRefInf), invoicer and invoicee (Invcr/Invcee) and additional remittance information (AddtlRmtInf). Below is an example.
When structured remittance information is encountered, GRIP-Channels converts it to an internal representation of tag/value pairs, separated by spaces. This internal
6
representation is passed down the SEPA payment chain and returns to the originating party in the case of a rejection or return.
The following two examples are equivalent. In both cases the information in the case of a reject or return is: Cd/SCOR Issr/CUR Ref/1234567.
<!-- Example 1: Structured --><RmtInf> <Strd>
<CdtrRefInf> <Tp>
<CdOrPrtry> <Cd>SCOR</Cd>
</CdOrPrtry> <Issr>CUR</Issr>
</Tp> <Ref>1234567</Ref>
</CdtrRefInf> </Strd>
</RmtInf>
<!-- Example 2: Unstructured, conveying the same information --><RmtInf> <Ustrd>Cd/SCOR Issr/CUR Ref/1234567</Ustrd>
</RmtInf>
Resources• The XSD for the PAIN.001 file format can be obtained at
http://www.iso20022.org/message_archive.page. • A direct link is
• A good, free, all-round XML validation tool for Windows is XmlValidator, available at http://sourceforge.net/projects/xmlvalidator/.
• Another good Windows tool is Notepad++, available at http://notepad-plus-plus.org/ in combination with the XML Tools plugin, available at http://sourceforge.net/projects/npp-plugins/files/XML%20Tools/.
Applicability in GRIP-Channels
Uploading PAIN.001 FilesPAIN.001 files can be uploaded in GRIP-Channels in the File Transfer tab, Upload File page. Note that the file type must be set to “SEPA Credit Transfer Initiation” in order for the file to be properly recognized and processed. The name of the uploaded file can befreely chosen, though mostly PAIN.001 files will be named .xml.
Uploaded files and their statuses are visible in the File View page:
7
Authorisation ProcedureThe standard Channels authorisation procedure applies also to uploaded PAIN.001 files. E.g., when users whose payments must be authorised (four-eye principle) upload PAIN.001 files, then the batches must be authorised by a colleague. When users whose payments do not require authorisation upload PAIN.001 files, then the batches are executed right away.
Mapping DetailsThe following table summarizes the mapping of relevant PAIN.001 fields.
PAIN.001 field GRIP-Channels data
Message ID MsgId Client reference number
Payment information ID PmtInfId Not mappedCategory Purpose CtgyPurp Not mapped
Requested Execution Date ReqdExctnDt Requested execution date, value date, and release date
End to end ID EndToEndID End to end IDRemittance information RmtInf Not visible, but used during rejects or
returns
8
Appendix: Example PAIN.001 FileThe following example shows a PAIN.001 file, holding one Payment Information block, with three credit transfers of resp. EUR 13, 17 and 19.
![SEPA Migration Checklist FINAL ppt - Chase.com IBAN Conversion of payment instructions to XML Digitisation and management ... SEPA Migration Checklist FINAL ppt [Compatibility Mode]](https://static.documents.pub/doc/80x56/5ad177d87f8b9a05208bb7f9/sepa-migration-checklist-final-ppt-chasecom-iban-conversion-of-payment-instructions.jpg)
