Implementation guide
ISO 20022
CustomerPaymentStatusReport
pain.002 version 3
Version 1.0.1
Publishing date 19 January 2017
Implementation guide
Table of contents
1
INTRODUCTION ...................................................................................................................................... 3
1.1
1.2
2
GENERAL RULES ................................................................................................................................... 5
2.1
2.2
2.3
2.4
2.5
3
Related documents ..........................................................................................................................................3
History ..............................................................................................................................................................3
Validation of the file upon receipt of the file ......................................................................................................5
Validation of transactions upon receipt of the file .............................................................................................5
Validation of transactions on execution day .....................................................................................................6
General Restrictions .........................................................................................................................................6
Restrictions to GlobalOn-Line ..........................................................................................................................6
TERMS AND CONCEPTS ....................................................................................................................... 7
3.1
3.2
3.3
Abbreviations ...................................................................................................................................................7
Parties ..............................................................................................................................................................7
References .......................................................................................................................................................8
4
SCENARIO............................................................................................................................................... 9
5
FORMAT SPECIFICATION ................................................................................................................... 11
5.1
5.2
Message structure .......................................................................................................................................... 11
Implementation guidelines.............................................................................................................................. 11
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
Page 2
Publishing date 19 January 2017
Implementation guide
1 Introduction
This document describes the Implementation Guide ISO 20022 CustomerPaymentStatusReport
pain.002.001.03 in Handelsbanken.
The purpose of this Message Implementation Guide is to provide guidance for how information is
structured in the exchange between the Handelsbanken and the customer.
Handelsbanken´s message set-up complies with the international definitions for content and use of
an ISO 20022 “CustomerPaymentStatusReport” message and Common Global Implementation
Message Practice (CGI MP).
1.1 Related documents
The documents below contain information to facilitate the implementation of the status report in
the ISO 20022 CustomerPaymentStatusReport (pain.002) format;
•
The ISO 20022 Message Definition Report (MDR), Message Usage Guideline (MUG) and
XML Schema can be downloaded from:
www.iso20022.org/message_archive.page#Payments_Init
•
The Payments External Code List, which provides the standard values for payment message
code elements, www.iso20022.org/external_code_list.page
1.2 History
New releases of the Implementation Guides are published on a regular basis, based on new
versions of the underlying standards or to provide clarification or changes. At Handelsbanken,
changes to version numbers are made according to the following guidelines. The original version is
1.0.0.
•
The last digit is changed when the format descriptions are changed, for example text
clarifications and examples.
•
The second digit is changed if minor changes are made to the format such as new countries or
changes in the payment type.
•
The first digit is changed (thus becoming a completely new version) if the format changes
mean that the customer will have to make adaptations in order to continue using the service. In
this case, all customers affected are informed of the new version and what the changes involve.
Version
Date
Description
1.0.1
2017-01-19
Minor changes and updates
1.0.0
2016-08-30
Merger of the two pain.002-reports in Handelsbanken:
- Confirmation of receipt, Publishing date Dec 21, 2012
- Status report rejected payments, Publishing date Dec
21, 2012
OriginalNumberOfTransactions and OriginalControlSum
will be echoed back if stated in pain.001 (ISO Index 2.4
and 2.5)
GroupStatus, new codes: PART (Partially Accepted) and
ACCP (Accepted Customer Profile), (Earlier reported
with the code ACTC) (ISO Index 2.5)
TransactionStatus can include the code ACCP
(Accepted Customer Profile), if agreed upon with the
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
Page 3
Publishing date 19 January 2017
Implementation guide
Version
Date
Description
1.0.1
2017-01-19
Minor changes and updates
bank. If not agreed, TransactionStatus are shown for
rejected transactions only (ISO Index 3.19)
1.0.1
2012-12-21
Pain.002 Confirmation of receipt
1.0.1
2012-12-21
Pain.002 Status report rejected payments
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
Page 4
Publishing date 19 January 2017
Implementation guide
2 General rules
Handelsbanken’s Status report “CustomerPaymentStatusReport ISO 20022 pain.002 reports the
status of payment files (for example pain.001) sent to Handelsbanken Global Gateway. The report
also notifies the status of each payment transaction in the file. The report is sent via the
communication method agreed with the Bank.
In order to facilitate the matching of the payments in the ERP system, Handelsbanken recommends
our customers to use the “EndToEnd Identification” as a unique reference to identify each
payment transaction. This reference will always be reported back on Transaction level in any ISO
20022 report.
Only one cause for rejection per payment transaction is reported, even though a payment could be
rejected for several reasons. The reason for rejection is stated in a coded and, if available, narrative
form in English. The status report is delivered as described below.
The status of the file and the payments is always displayed in the online corporate banking service
or GlobalOn-Line.
2.1 Validation of the file upon receipt of the file
Upon receipt of the payment file Handelsbanken instantly checks if the file is valid against the
schema for pain.001 (or other corresponding file format validation if other file format). If the file
is not valid, the whole file is rejected (Group status = Reject/RJCT).
The status of the file is always displayed in Handelsbanken online corporate banking service or
GlobalOn-Line under File management.
2.2 Validation of transactions upon receipt of the file
Immediately after schema validation/format validation, each payment transaction in the file is
validated against the information needed for each payment system to correctly process the
payment.
When the payment file and all including transactions are validated and accepted by the bank, a
positive status is sent in the status report (GroupStatus = ACCP Accepted customer profile –
Preceding check of technical validation was successful. Customer profile check was also
successful.)
If any mandatory data for a single payment transaction is missing or incorrect, the single payment
transaction is rejected and a negative status is sent in the status report (GroupStatus = Partially
accepted/PART, TransactionStatus = Reject/RJCT).
If agreed upon with the bank, the status report can also include accepted payment transactions. In
this case the code ACCP (Accepted customer profile – Preceding check of technical validation was
successful. Customer profile check was also successful) is reported for each accepted transaction
when group status = ACCP and PART.
If, for some reason, all payment transactions are rejected a negative status is sent in the status
report (GroupStatus = Reject/RJCT, TransactionStatus = Reject/RJCT).
The status of all payments is always displayed in Handelsbanken online corporate banking service
or GlobalOn-Line under Search payment.
The relevant cut-off times and authorisations are checked after the above validations and reporting,
and if the cut-off time has been passed or authorisation is incorrect a status report will be sent
(GroupStatus = Not used, TransactionStatus = Reject/RJCT).
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
Page 5
Publishing date 19 January 2017
Implementation guide
2.3 Validation of transactions on execution day
If a payment is rejected in connection with the execution date, for example if a beneficiary account
is closed or if there is insufficient funds on the debtor account, Handelsbanken creates a Status
report with rejected payments transactions only, (GroupStatus = Not Used, TransactionStatus =
Reject/RJCT).
The status of all payments is always displayed in Handelsbanken online corporate banking service
or GlobalOn-Line, Search payment.
Some payment types cannot be reported as rejected in connection with the execution date, see
below under the heading “Restrictions to GlobalOn-Line” for more information.
2.4 General Restrictions
Only payment files sent in via Handelsbanken Global Gateway are reported in this Status Report.
Manually registered payments via the Bank’s online corporate banking services or GlobalOn-Line
are not included in the report. The status of manually registered payments are always displayed in
the Bank’s online corporate banking services or GlobalOn-Line under Search Payment.
Pain.002 can be sent for almost all different file formats. However Handelsbanken recommends
the combination pain.001 – pain.002 for a standardized status reporting.
2.5 Restrictions to GlobalOn-Line
There are some restrictions in regards to status reporting that applies to some payment types in
certain countries. For the payment types described below, a status report might not be sent in
connection with the execution date as the status of the payment in some cases is informed
manually:
•
Local financial payments
•
Local urgent payments (incl CHAPS payments in the UK and Fedwire payments in the US)
•
Local payments in Hong Kong and Singapore
•
Plusgiro payments in Sweden
•
Intra group transfers/Intra company payments
•
Cross border payments from accounts in other countries than SE and NO
•
Payments with debtor account in other bank than Handelsbanken
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
Page 6
Publishing date 19 January 2017
Implementation guide
3 Terms and concepts
3.1 Abbreviations
These abbreviations are frequently used and are important for the understanding of the message.
Term
Description
BBAN
Basic Bank Account Number – identifier used nationally by financial
institutions, i.e.in individual countries, generally as part of a National Account.
IBAN
International Bank Account Number – identifier used nationally and
internationally by financial institutions. An IBAN consists of a country code, a
control digit, a bank identifier and a national account number. A Swedish
IBAN is made up of 24 characters in total and a foreign IBAN can be up to 34
characters.
SWIFT
SWIFT is the abbreviation of Society for Worldwide Interbank Financial
Telecommunication and is a communications network used by most of the
banks in the world for sending each other payment instructions and
messages.
BIC
Business Identifier Code is made up of 8 or 11 characters. A unique address
linked to SWIFT.
3.2 Parties
The ISO concepts of different parties are described in the table below.
Party ISO 20022
Synonym
Description
Debtor
Originator
Ordering Party
The Party whose account is debited with
the payment.
Ultimate Debtor
Originator Reference Party
The Party that originally ordered goods or
services and to whom the seller has sent
the invoice. Ultimate Debtor is used when
the receiver of the invoice is different than
the account owner.
Initiating Party
Instructing Party
The Party on the initiative of which the
payment data is established. This can
either be the debtor or the party that
initiates the credit transfer on behalf of the
debtor e.g. an agent, Service Bureau or a
company’s service centre.
Creditor
Beneficiary
The Party whose account is credited with
the payment.
Ultimate Creditor
Ultimate Beneficiary
Beneficiary Reference Party
Debtor agent
Originator’s, Bank Payer’s Bank
The Party which is the ultimate beneficiary
of the payment. For example the payment
is credited to an account of a financing
company, but the ultimate beneficiary is the
customer of the financing company.
The Bank where the Debtor has its account.
Creditor agent
Beneficiary’s Bank, Seller’s Bank
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
The Bank where the Creditor has its
account.
Page 7
Publishing date 19 January 2017
Implementation guide
3.3 References
The CustomerPaymentStatusReport/Rejected Payments has the following possible references on
the different levels in the message.
ISO
Index No
Reference type
Message position and tag
name
Description
1.0
<GrpHdr>
1.1
Message Id
<GrpHdr><MsgId>
Unique identification of the
message.
2.0
<OrgnlGrpInfAndSts>
2.3
Original Message
Identification
<OrgnlGrpInfAndSts>
<OrgnlMsgId>
Point to point reference, as
assigned by the original
instructing party, to
unambiguously identify the
original message.
3.0
<TransactionInformation
AndStatus>
3.2
Original Payment
Information Identification
<TxInfAndSts>
<OrgnlPmtInfId>
Unique identification, as
assigned by the original
sending party, to
unambiguously identify the
original payment information
group.
3.3
Original Instruction
Identification
<TxInfAndSts>
<OrgnlInstrId>
Unique identification, as
assigned by the original
instructing party to
unambiguously identify the
original instruction.
3.4
Original EndToEnd
Identification
<TxInfAndSts>
<OrgnlEndToEndId>
Unique identification, as
assigned by the original
initiating party, to
unambiguously identify the
original transaction.
3.17
<OrgnlTxRef>
3.92
Creditor’s Structured
Reference Id
<OrgnlTxRef><RmtInf>
<Strd><CdtrRefInf>
< CdtrRef >
Unique and unambiguous
structured identification, as
assigned by the creditor, to
unambiguously refer to the
payment, e.g. KID, OCR or
RF-reference.
3.79
Creditor´s Referred
Document Number
<OrgnlTxRef><RmtInf>
<Strd><RfrdDocInf>
<RfrdDocNb>
Unique and unambiguous
identification of the referred
document, e.g. Invoice Id or
Credit Note Id. Assigned by
the creditor,
3.72
Unstructured free text
<OrgnlTxRef ><RmtInf>
<Ustrd>
Free text that can be used to
help the creditor to identify the
transaction if no structured
identification is used.
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
Page 8
Publishing date 19 January 2017
Implementation guide
4 Scenario
The purpose of this section is to basically describe an example of the entire chain of electronic
information exchange between the Debtor, the Debtor’s Agent, the Creditor’s Agent and the
Creditor.
Debtor’s
Creditor’s
pain.001
Account Reporting
Customer Payment
Status Report
camt.052
camt.053
pain.002camt.054
Customer Direct
Debit
Account Reporting
Customer Payment
Status Report
Customer Credit
Transfer
camt.052
camt.053
pain.002camt.054
pain.008
Cred
D b
1) The Debtor sends a CreditTransferInitiation (pain.001) to the Debtor Agent.
2) The Debtor Agent validates the file (xml schema validation) and sends a
PaymentStatusReport (pain.002) reporting if the whole file is rejected.
o GroupStatus = RJCT (Rejected), TransactionStatus = Not used
3) If the file is valid according to the schema, the information included in every single
payment transaction is validated against each payment system and the Debtor Agent sends
a PaymentStatusReport (pain.002) reporting the status of the file and the transactions:
o All transactions in the file are validated as OK:
GroupStatus = ACCP (AcceptedCustomerProfile), TransactionStatus = ACCP
(AcceptedCustomerProfile) if agreed upon with the bank, otherwise
TransactionStatus is Not used.
o Some of the transactions in the file are validated as rejected:
GroupStatus = PART (PartiallyAccepted), TransactionStatus = RJCT (Rejected) for
rejected payment transactions, TransactionStatus = ACCP
(AcceptedCustomerProfile) if agreed upon with the bank, otherwise
TransactionStatus is Not used for Accepted payment transactions.
o All transactions in the file are validated as rejected:
GroupStatus = RJCT (Rejected), TransactionStatus = RJCT (Rejected)
4) Manual authorization of the file is done if agreed upon.
5) The relevant cut-off times and authorisations are checked, if the cut-off time has been
passed or authorisation is incorrect the Debtor Agent sends a PaymentStatusReport
(pain.002) reporting rejected payments to the Debtor.
o GroupStatus = Not used, TransactionStatus = RJCT(Rejected).
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
Page 9
Publishing date 19 January 2017
Implementation guide
6) The payments are processed between Debtor Agent and Creditor Agent on the agreed
execution date. If any of the payments are rejected on the execution day, for example due
to insufficient funds or closed creditor account, the Debtor Agent sends a
PaymentStatusReport (pain.002) reporting rejected payments to the Debtor
o GroupStatus = Not used, TransactionStatus = RJCT (Rejected)
7) Debtor Agent sends a Debit Notification report (camt.054) to the Debtor reporting executed
payments.
8) Creditor Agent sends a Credit Notification report (camt.054) to the Creditor reporting
incoming payments.
9) Debtor Agent and/or Creditor Agent sends an Interim AccountReport (camt.052) to the
Debtor and/or Creditor.
10) Debtor Agent and/or Creditor Agent sends an Account Statement (camt053) to the Debtor
and/or Creditor.
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
Page 10
Publishing date 19 January 2017
Implementation guide
5 Format specification
This section consists of a technical description of the message type
CustomerPaymentStatusReport/Rejected Payments ISO 20022 pain.002.001.02.
5.1 Message structure
The Payment initiation message is composed of three parts: GroupHeader,
OriginalGroupInformationAndStatus and TransactionInformationAndStatus.
GroupHeader
OriginalGroup
InformationAndStatus
TransactionInformation
AndStatus
TransactionInformation
AndStatus
TransactionInformation
AndStatus
GroupHeader
This building block is mandatory and present only once. It contains general elements that apply to
the whole message.
OriginalGroupInformationAndStatus
This building block is mandatory and present once. It contains elements related to the original
CustomerCreditTransferInitiation message and can contain an overall status.
TransactionInformationAndStatus
This building block is mandatory and repetitive. It contains elements referencing the original
instructions contained in the original message and can contain an individual status for the original
instructions.
5.2 Implementation guidelines
The order of the elements in the table follows the order of the elements in the schema. White rows
are used for Message Items that can hold data and yellow rows are Message Items which are XML
tags used for the data’s structural position in the XML message.
The headings used in the format description are described in the table below.
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
Page 11
Publishing date 19 January 2017
Implementation guide
Heading
Description
ISO Index no
Reference number that points to the related field description in the ISO 20022 Message
Definition Report (MDR).
Structural
Sequence
Indication of the Message Items structural level in the message tree structure by the
number of +-signs. Group Header <GrpHdr> and Payment Information <PmtInf> has one
+ as the two starting points in the message.
Message Item
A Message Item is a composing part of a Message. It can be a Message Element (which
can be compared to the ‘fields’ of a traditional message) or a Message Component
(which can be compared to a block of information, consisting of different message
elements).
Tag Name
A specific name assigned to a Message Item and that will appear in the XML Schema
and in XML instances that use this Message Item.
Multiplicity
Indicates whether a Message Item is optional, mandatory and/or repetitive due to ISO
20022 XML schema. Multiplicity is represented by a notation between square brackets
as described below;
[0..1] this element and all underlying elements in the tree (in the XML-schema) is
optional and must be presented exactly once
[0..n] this element this element is optional with unlimited repetition
[1..1] this element is mandatory and must be present exactly once
[1..n] this element is mandatory with unlimited repetition
Status
Indicates the data’s status due to Handelsbanken.
Optional(O) = optional to include the data in the message
Mandatory(M) = the data will be required to ensure a correct process of the payment
Conditional(C) = the data is required for certain payments or required dependent on
other data in the message
Exclusive or(XOR) = one of many data should be used, but not multiple
Required(R)= the data is mandatory if an optional or conditional data is used
Type
A Type Representation is used to group similar Types, such as Codes, Dates, Text,
Numeric etc. If Handelsbanken has restrictions in the number of characters that differs
from the schema, it will be stated in this column.
ISO 20022 CustomerPaymentStatusReport pain 002.001.03
Version 1.0.1
Page 12
Publishing date 19 January 2017
ISO
Index
No.
0.0
1.0
Struct.
Seq.
+
1.1
++
MessageIdentification
1.2
++
1.3
9.1.12
++
+++
9.1.13
9.1.14
2.0
++++
+++++
+
2.1
++
OriginalMessageIdentification
2.2
++
OriginalMessageNameIdentification
Message Item
CustomerPaymentStatusReport
GroupHeader
Mult.
[1..1]
[1..1]
Status
M
M
Type
<MsgId>
[1..1]
M
Text
CreationDateTime
<CreDtTm>
[1..1]
M
DateTime
InitiatingParty
Identification
<InitgPty>
<Id>
[0..1]
[0..1]
M
M
[1..1]
[0..1]
[1..1]
M
M
M
Identifier
<OrgnlMsgId>
[1..1]
M
Text
<OrgnlMsgNmId>
[1..1]
M
Text
OrganisationIdentification
BICOrBEI
OriginalGroupInformationAndStatus
Tag Name
<CstmrPmtStsRpt>
<GrpHdr>
<OrgId>
<BICOrBEI>
<OrgnlGrpInfAndSts>
Definition
pain.002.001.03
Set of characteristics shared by all individual
transactions included in the message.
Point to point reference, as assigned by the
instructing party, and sent to the next party in the
chain to unambigouously identify the message.
Date and time at which the message was created.
Handelsbanken special Comments
A unique reference stated by Handelsbanken
YYYY-MM-DDThh-;mm:ss:ss
Party that initiates the status message.
Unique and unambiguous way of identifying an
organisation or an individual person.
Business Identifier Code.
Always "HANDSESS"
Original group information concerning the group of
transactions, to which the status report message
refers.
Point to point reference, as assigned by the original From original message.
instructing party, to unambiguously identify the
original message.
"Not provided" if not included in original
message.
Specifies the original message name identifier to
which the message refers.
From original message.
"Not provided" if not included in original
message.
2.3
++
OriginalCreationDateTime
<OrgnlCreDtTm>
[0..1]
C
DateTime
Date and time at which the original message was
created.
Taken from original ISO 20022-message if
provided but not if whole message is rejected in
the schema/format validation.
2.4
++
OriginalNumberOfTransactions
<OrgnlNbOfTxs>
[0..1]
C
Text
Number of individual transactions contained in the
original message
Taken from original ISO 20022-message if
provided but not if whole message is rejected in
the schema/format validation.
2.5
++
OriginalControlSum
<OrgnlCtrlSum>
[0..1]
C
Quantity
Total of all individual amounts included in the
original message, irrespective of currencies.
Taken from original ISO 20022-message if
provided but not if whole message is rejected in
the schema/format validation.
2.6
++
GroupStatus
<GrpSts>
[0..1]
C
Code
Specifies the status of a group of transactions.
Used on file level
Allowed codes:
ACCP - AcceptedCustomerProfile, preceding
check of technical validation was successful.
Customer profile check was also successful.
RJCT - Rejected
PART - PartiallyAccepted
2.7
++
2.8
9.1.12
9.1.13
9.1.14
2.9
+++
++++
+++++
++++++
+++
StatusReasonInformation
Originator
Identification
OrganisationIdentification
BICOrBEI
Reason
<StsRsnInf>
<Orgtr>
<Id>
<OrgId>
<BICOrBEI>
<Rsn>
[0..n]
C
[0..1]
[0..1]
[1..1]
[0..1]
[0..1]
R
R
R
R
R
Identifier
Set of elements used to provide detailed
information on the status reason.
Party that issues the status.
Only used when the file is rejected in the
schema validation/format validation.
Business Identifier Code.
Specifies the reason for the status report.
Always "HANDSESS"
ISO
Index
No.
2.10
Struct.
Seq.
++++
2.12
+++
2.13
++
2.14
+++
2.15
+++
3.0
+
3.1
++
3.15
++
3.17
+++
OriginalInstructionIdentification
3.18
+++
3.19
Message Item
Code
Mult.
[1..1]
Status
R
Type
Code
Definition
Reason for the status, as published in ISO 20022
External Code List (16-Status reason).
[0..n]
C
Text
Further details on the status reason.
<NbOfTxsPerSts>
[0..n]
C
DetailedNumberOfTransactions
<DtldNbOfTxs>
[1..1]
R
Text
DetailedStatus
<DtldSts>
[1..1]
R
Code
<OrgnlPmtInfAndSts>
[0..n]
C
OriginalPaymentInformationIdentification
<OrgnlPmtInfId>
[1..1]
R
TransactionInformationAndStatus
<TxInfAndSts>
[0..n]
R
<OrgnlInstrId>
[0..1]
C
Text
OriginalEndToEndIdentification
<OrgnlEndToEndId>
[0..1]
C
Text
Unique identification, as assigned by the original
initiating party, to unambiguously identify the
original transaction.
Taken from original message if provided.
+++
TransactionStatus
<TxSts>
[0..1]
R
Code
Specifies the status of a transaction, in a coded
form.
Allowed codes:
ACCP - Accepted
RJCT - Rejected
3.20
+++
StatusReasonInformation
<StsRsnInf>
[0..n]
C
Set of elements used to provide detailed
information on the status reason.
Only provided when TransactionStatus <TxSts>
= RJCT
3.21
9.1.12
9.1.13
9.1.14
3.22
3.23
++++
+++++
++++++
+++++++
+++++
++++++
[0..1]
[0..1]
[1..1]
[0..1]
[0..1]
[1..1]
R
R
R
R
R
R
Party that issues the status.
3.25
+++++
[0..n]
R
3.32
+++
[0..1]
R
3.34
3.35
++++
+++++
Amount
InstructedAmount
<Amt>
<InstdAmt Ccy="AAA">
[0..1]
[1..1]
R
R
Amount
3.41
++++
RequestedExecutionDate
<ReqdExctnDt>
[0..1]
R
DateTime
AdditionalInformation
NumberOfTransactionsPerStatus
OriginalPaymentInformationAndStatus
Originator
Identification
OrganisationIdentification
BICOrBEI
Reason
Code
AdditionalInformation
OriginalTransactionReference
Tag Name
<Cd>
<AddtlInf>
<Orgtr>
<Id>
<OrgId>
<BICOrBEI>
<Rsn>
<Cd>
<AddtlInf>
<OrgnlTxRef>
Text
Identifier
Code
Text
Handelsbanken special Comments
For example:
FF01 = Invalid file format
AM05 = Duplicate
NARR = Narrative, see further details below
Detailed information on the number of transactions
for each identical transaction status.
Number of individual transactions contained in the
message, detailed per status.
Common transaction status for all individual
Allowed codes:
transactions reported.
ACCP - Technical validation are successful
RJCT - Rejected
Information concerning the original payment
Only used if the status report includes status on
transaction level.
information, to which the status report message
refers.
Unique identification, as assigned by the original
From original message.
sending party, to unambiguously identify the original
"Not provided" if not included in original
message.
Set of elements used to provide information on the
original transactions to which the status report
message refers.
Unique identification, as assigned by the original
Taken from original message if provided.
instructing party unambiguously identify the original
instruction.
Business Identifier Code.
Specifies the reason for the status report.
Reason for the status, as published in ISO 20022
External Code List (16-Status reason).
Further details on the status reason.
Always "HANDSESS"
Set of key elements used to identify the original
transaction that is being referred to.
Reported as stated in the original message
Will always be provided
Amount of money to be moved between the debtor
and creditor, before deduction of charges,
expressed in the currency as ordered by the
initiating party.
Date at which the initiating party requests the
Only Date in format YYYY-MM-DD will be
clearing agent to process the payment.
provided
ISO
Index
No.
3.88
Struct.
Seq.
++++
3.89
+++++
Unstructured
3.90
+++++
Structured
3.91
++++++
3.92
3.93
+++++++
++++++++
3.94
+++++++++
3.96
++++++++
3.97
+++++++
3.99
++++++
3.102
+++++++
CreditNoteAmount
3.109
+++++++
RemittedAmount
3.110
++++++
3.111
3.112
+++++++
++++++++
3.113
3.115
+++++++++
++++++++
3.116
+++++++
3.119
++++++
3.121
++++
9.1.0
+++++
3.122
++++
1.1.0
+++++
1.1.1
++++++
IBAN
1.1.2
++++++
Other
1.1.3
+++++++
1.1.4
+++++++
1.1.5
++++++++
Code
1.1.6
++++++++
Proprietary
3.123
++++
Message Item
RemittanceInformation
Mult.
[0..1]
Status
C
Type
<Ustrd>
[0..n]
C
Text
<Strd>
[0..n]
C
[0..n]
C
<Tp>
<CdOrPrtry>
[0..1]
[1..1]
C
R
<Cd>
[1..1]
R
Code
Document type in a coded form.
[0..1]
C
Text
Identification of the issuer of the reference
document type.
[0..1]
C
Text
[0..1]
C
<CdtNoteAmt Ccy="AAA">
[0..1]
C
Amount
<RmtdAmt Ccy="AAA">
[0..1]
C
Amount
[0..1]
C
[0..1]
[1..1]
C
R
[1..1]
[0..1]
R
C
Code
Text
Type of creditor reference, in a coded form.
Entity that assigns the credit reference type.
Only SCOR
"ISO" if RF-reference, otherwise not used
[0..1]
R
Text
Unique reference, as assigned by the creditor, to
anambiguously refer to the payment transaction.
Structured reference for example OCR-, KID- or
RF-reference .
[0..3]
C
Text
Reported if available
[0..1]
C
Additional information, in free text form, to
complement the structured remittance information.
Party that owes an amount of money to the
(ultimate) creditor.
<Nm>
[0..1]
C
<DbtrAcct>
[0..1]
R
[1..1]
R
<IBAN>
[1..1]
{XOR
<Othr>
[1..1]
XOR}
Identification
<Id>
[1..1]
R
SchemeName
<SchmeNm>
[0..1]
C
<Cd>
[1..1]
<Prtry>
ReferredDocumentInformation
Tag Name
<RmtInf>
<RfrdDocInf>
Type
CodeOrProprietary
Code
Issuer
<Issr>
Number
ReferredDocumentAmount
CreditorReferenceInformation
<Nb>
<RfrdDocAmt>
<CdtrRefInf>
Type
CodeOrProprietary
<Tp>
<CdOrPrtry>
Code
Issuer
<Cd>
<Issr>
Reference
AdditionalRemittanceInformation
Debtor
<Ref>
<AddtlRmtInf>
<Dbtr>
Name
DebtorAccount
Identification
DebtorAgent
<Id>
<DbtrAgt>
Definition
Handelsbanken special Comments
Reported as stated in the original message
Set of elements used to identify the documents
referred to in the remittance information.
Provides the type details of the referred document.
CINV= Commercial invoice
CREN = Credit note
Invoice number or credit note number
Set of elements used to provide details on the
amounts of the referred document.
Amount specified for the referred document is the
amount of a credit note.
Reported if available
Amount ot money remitted for the referred
document.
Reference information provided by the creditor to
allow the identification of the underlying documents.
Specifies the type of creditor reference.
Coded or proprietary format creditor reference type.
Text
Unambiguous identification of the account of the
debtor to which a debit entry will be made as a
result of the transaction.
Identifier
International Bank Account Number (IBAN)
IBAN account number
Text
Identification assigned by an institution.
Account number (see SchemeName below for
available accounts)
{{XOR
Code
Nature or use of the account in a coded form.
BBAN (Basic Bank Account Number)
[1..1]
XOR}}
Text
BGNR for Bankgiro Account
[0..1]
R
Name of the identification scheme, in a free text
form.
Financial institution servicing an account for the
debtor.
ISO
Index
No.
6.1.0
Struct.
Seq.
+++++
6.1.1
++++++
BIC
6.1.2
++++++
ClearingSystemMemberIdentification
6.1.3
+++++++
6.1.4
++++++++
6.1.6
+++++++
3.125
++++
6.1.0
+++++
6.1.1
6.1.2
++++++
++++++
6.1.3
+++++++
6.1.4
++++++++
6.1.6
+++++++
3.127
++++
9.1.0
+++++
3.128
++++
CreditorAccount
1.1.0
+++++
Identification
1.1.1
++++++
IBAN
1.1.2
++++++
Other
1.1.3
+++++++
1.1.4
+++++++
1.1.5
++++++++
Code
1.1.6
++++++++
Proprietary
Message Item
FinancialInstitutionIdentification
Tag Name
<FinInstnId>
Mult.
[1..1]
Status
R
Type
Definition
<BIC>
[0..1]
{XOR
Identifier
Business Identifier Code.
<ClrSysMmbId>
[0..1]
XOR}
<ClrSysId>
[0..1]
R
<Cd>
[1..1]
R
Code
Identification of a clearing system, in a coded form
as published in an external code list.
<MmbId>
[1..1]
R
Text
Identification of a member of a clearing system.
[0..1]
C
[1..1]
R
<BIC>
<ClrSysMmbId>
[0..1]
[0..1]
{XOR
XOR}
<ClrSysId>
[0..1]
R
<Cd>
[1..1]
<MmbId>
ClearingSystemIdentification
Code
MemberIdentification
CreditorAgent
FinancialInstitutionIdentification
BIC
ClearingSystemMemberIdentification
<CdtrAgt>
<FinInstnId>
Information used to identify a member within a
clearing system.
Business Identifier Code.
Information used to identify a member within a
clearing system.
R
Code
Identification of a clearing system, in a coded form
as published in an external code list.
[1..1]
R
Text
Identification of a member of a clearing system.
[0..1]
C
<Nm>
[0..1]
C
<CdtrAcct>
[0..1]
C
[1..1]
R
<IBAN>
[1..1]
{XOR
<Othr>
[1..1]
XOR}
Identification
<Id>
[1..1]
R
SchemeName
<SchmeNm>
[0..1]
R
<Cd>
[1..1]
<Prtry>
[1..1]
Code
MemberIdentification
Creditor
<Cdtr>
Name
<Id>
DEBLZ(Germany)
GBDSC(Great Britain)
SESBA(Sweden)
USABA(USA)
See external code list for more codes.
Clearing number/National Bank-Id
Financial institution servicing an account for the
creditor.
Identifier
ClearingSystemIdentification
Handelsbanken special Comments
DEBLZ(Germany)
GBDSC(Great Britain)
SESBA(Sweden)
USABA(USA)
See external code list for more codes.
Clearing number/National Bank-Id
Party to which an amount of money is due.
Text
Unambiguous identification of the account of the
creditor to which a credit entry will be posted as a
result of the payment transaction.
Identifier
International Bank Account Number (IBAN)
IBAN account number
Text
Identification assigned by an institution.
Account number (see SchemeName below for
available accounts)
{{XOR
Code
Nature or use of the account in a coded form.
BBAN (Basic Bank Account Number)
XOR}}
Text
Name of the identification scheme, in a free text
form.
SE: BGNR for Bankgiro Account
DK: OCR for GIRO or FI account number