SEPA Payment Initiation Format (PAIN.001)

SEPA Payment Initiation Format
(PAIN.001)
Description of the PAIN.001 format and its applicability
ABN AMRO Clearing Bank, March 2014
Table of Contents
Introduction.......................................................................................................... 2
PAIN.001 Structure................................................................................................ 2
XML Details..........................................................................................................................................................2
Unique Message ID ...............................................................................................................................................2
Payment Information Blocks ...........................................................................................................................3
Payment Information: ID...................................................................................................................................3
Payment Information: Category Purpose ..................................................................................................3
Payment Information: Requested Execution Date.................................................................................3
Payments...................................................................................................................................................................4
Remittance Information.....................................................................................................................................4
Resources .............................................................................................................................................................6
Applicability in GRIP-Channels............................................................................... 6
Uploading PAIN.001 Files..............................................................................................................................6
Authorization Procedure ...............................................................................................................................7
Mapping Details .................................................................................................................................................7
Appendix: Example PAIN.001 File .......................................................................... 8
1
Introduction
Part 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 Structure
SEPA 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 Details
This section describes some of the details of PAIN.001 requirements.
Unique Message ID
The 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 of
message ID’s may not exceed 35 characters.
The message ID is mapped to the Client Reference Number.
2
Example: The message ID in the below snippet is 2014-02-11-MsgId.
<?xml version="1.0" encoding="utf-8"?>

<Document
xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<CstmrCdtTrfInitn>
<GrpHdr>
<MsgId>2014-02-11-MsgId</MsgId>
. . .
</GrpHdr>
. . .
</CstmrCdtTrfInitn>
</Document>
Payment Information Blocks

A 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: ID
The 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 Purpose

PAIN.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 Date

Each 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.
This is illustrated in the below snippet.

<Document
<CstmrCdtTrfInitn>
<GrpHdr>
3
. . .
</GrpHdr>
<PmtInf>
<PmtInfId>2014-02-19_0001a</PmtInfId>
. . .
<ReqdExctnDt>2014-02-24</ReqdExctnDt>
. . .
</PmtInf>
<PmtInf>
<PmtInfId>2014-02-19_0001b</PmtInfId>
. . .
. . .
</PmtInf>
</CstmrCdtTrfInitn>
</Document>
Payments
Separate 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.
Example:

<Document
<CstmrCdtTrfInitn>
<GrpHdr>
. . .
</GrpHdr>
<PmtInf>
. . .
<CdtTrfTxInf>
<PmtId>
<EndToEndId>2014-02-19_0001_000001a</EndToEndId>
</PmtId>
. . .
</CdtTrfTxInf>
</PmtInf>
</CstmrCdtTrfInitn>
</Document>
Remittance Information
Each 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.
4
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.

<Document
<CstmrCdtTrfInitn>
<GrpHdr>
. . .
</GrpHdr>
<PmtInf>
. . .
<CdtTrfTxInf>
. . .
<RmtInf>
<Ustrd>RemittanceInformation</Ustrd>
</RmtInf>
. . .
</CdtTrfTxInf>
</PmtInf>
</CstmrCdtTrfInitn>
</Document>
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.

<Document
<CstmrCdtTrfInitn>
<GrpHdr>
. . .
</GrpHdr>
<PmtInf>
. . .
<CdtTrfTxInf>
. . .
<RmtInf>
<Strd>
<RfrdDocInf>
<Tp>
<CdOrPrtry>
<Cd>CINV</Cd>
</CdOrPrtry>
</Tp>
<Nb>ABC-13679</Nb>
<RltdDt>2014-01-12</RltdDt>
</RfrdDocInf>
</Strd>
</RmtInf> . . .
</CdtTrfTxInf>
</PmtInf>
</CstmrCdtTrfInitn>
</Document>
When structured remittance information is encountered, GRIP-Channels converts it to

an internal representation of tag/value pairs, separated by spaces. This internal
5
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.


<RmtInf>
<Strd>
<CdtrRefInf>
<Tp>
<CdOrPrtry>
<Cd>SCOR</Cd>
</CdOrPrtry>
<Issr>CUR</Issr>
</Tp>
<Ref>1234567</Ref>
</CdtrRefInf>
</Strd>
</RmtInf>


<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
http://www.iso20022.org/documents/messages/1_0_version/pain/schemas/p
ain.001.001.03.zip.
• 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 Files
PAIN.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 be
freely chosen, though mostly PAIN.001 files will be named .xml.
Uploaded files and their statuses are visible in the File View page:
6
Authorisation Procedure
The 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 Details
The 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 mapped
Category Purpose CtgyPurp Not mapped
Requested Execution Date ReqdExctnDt Requested execution date, value date, and
release date
End to end ID EndToEndID End to end ID
Remittance information RmtInf Not visible, but used during rejects or
returns
7
Appendix: Example PAIN.001 File
The following example shows a PAIN.001 file, holding one Payment Information block,
with three credit transfers of resp. EUR 13, 17 and 19.

<Document
<CstmrCdtTrfInitn>
<GrpHdr>
<MsgId>MessageId</MsgId>
<CreDtTm>2014-01-08T10:33:56</CreDtTm>
<NbOfTxs>3</NbOfTxs>
<CtrlSum>49.00</CtrlSum>
<InitgPty>
<Nm>Accountholder-Name</Nm>
</InitgPty>
</GrpHdr>
<PmtInf>
<PmtInfId>PaymentInformationId</PmtInfId>
<PmtMtd>TRF</PmtMtd>
<NbOfTxs>3</NbOfTxs>
<CtrlSum>49.00</CtrlSum>
<PmtTpInf>
<SvcLvl>
<Cd>SEPA</Cd>
</SvcLvl>
</PmtTpInf>
<Dbtr>
<Nm>Accountholder-Name</Nm>
</Dbtr>
<DbtrAcct>
<Id>
<IBAN>NL72ABNC0123456789</IBAN>
</Id>
</DbtrAcct>
<DbtrAgt>
<FinInstnId>
<BIC>ABNCNL2A</BIC>
</FinInstnId>
</DbtrAgt>
<ChrgBr>SLEV</ChrgBr>
<CdtTrfTxInf>
<PmtId>
<EndToEndId>E2E-ID-1</EndToEndId>
</PmtId>
<Amt>
<InstdAmt Ccy="EUR">13.00</InstdAmt>
</Amt>
<CdtrAgt>
<FinInstnId>
<BIC>INGBNL2A</BIC>
</FinInstnId>
</CdtrAgt>
<Cdtr>
<Nm>Beneficiary1</Nm>
</Cdtr>
<CdtrAcct>
<Id>
<IBAN>NL69INGB0123456789</IBAN>
</Id>
</CdtrAcct>
<RmtInf>
<Ustrd>RemittanceInformation1</Ustrd>
8
</RmtInf>
</CdtTrfTxInf>
<CdtTrfTxInf>
<PmtId>
</PmtId>
<Amt>
</Amt>
<CdtrAgt>
<FinInstnId>
<BIC>INGBNL2A</BIC>
</FinInstnId>
</CdtrAgt>
<Cdtr>
</Cdtr>
<CdtrAcct>
<Id>
</Id>
</CdtrAcct>
<RmtInf>
</RmtInf>
</CdtTrfTxInf>
<CdtTrfTxInf>
<PmtId>
</PmtId>
<Amt>
</Amt>
<CdtrAgt>
<FinInstnId>
<BIC>INGBNL2A</BIC>
</FinInstnId>
</CdtrAgt>
<Cdtr>
</Cdtr>
<CdtrAcct>
<Id>
</Id>
</CdtrAcct>
<RmtInf>
</RmtInf>
</CdtTrfTxInf>
</PmtInf>
</CstmrCdtTrfInitn>
</Document>

SEPA Payment Initiation Format (PAIN.001)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SEPA Payment Initiation Format (PAIN.001)

Uploaded by

Copyright:

Available Formats

SEPA Payment Initiation Format

The message ID is mapped to the Client Reference Number.

<?xml version="1.0" encoding="utf-8"?>

Payment Information Blocks

Payment Information: Category Purpose

Payment Information: Requested Execution Date

This is illustrated in the below snippet.

<?xml version="1.0" encoding="utf-8"?>

However, the end to end ID is transported throughout the SEPA chain:

<?xml version="1.0" encoding="utf-8"?>

<?xml version="1.0" encoding="utf-8"?>

Structured information allows the optional specification of referred document

<?xml version="1.0" encoding="utf-8"?>

When structured remittance information is encountered, GRIP-Channels converts it to

PAIN.001 field GRIP-Channels data

<?xml version="1.0" encoding="utf-8"?>

You might also like