ISO 20022 Message Implementation Guide for Payment Initiation

ISO 20022 Message Implementation Guide

for Payment Initiation

Pain001

Pain002

Version: 1.7

Issue date: 12 January 2017

Author: Swedbank

Table of Contents

1. Introduction

2. Customer Credit Transfer Initiation V3 pain.001.001.03

3. Customer Payment Status Report pain.002.001.03

3.1 Statuses in Pain002

4. Examples

4.1 Domestic Payment Estonia, 2 payments

4.2 International Payment example (express payment in USD, via correspondent bank)

4.3 European Payment example (Sepa Credit Transfer)

4.4 Consolidated Payment example

4.5 International payment in Russian roubles example (via correspondent bank)

4.6 Payment status report pain.002.001.03 example (accepted)

4.7 Payment status report pain.002.001.03 example (rejected)

Revision history

Version Changes Date

1.0 First version of the MIG, main focus on EE local Banking Association MIG 9.12.2013

1.1 Revision history addedAllowed characters and file encoding described in more detail.InstructionIdentification will become optional starting from 10.04.2014, limitation on length removed from International Payment. Lithuania will still have local clearing related limitations applied to interbank Domestic Payment.ClearingSystemMemberIdentification not supported.PaymentTypeInformation logic and rules explained for payment type determination. RegulatoryReporting updated, not used in Estonia starting from 01.02.2014.Pain.002 GroupStatus, PaymentInformationStatus and TransactionStatus updated

27.02.2014

1.2 Express payment currencies list updatedInstructionIdentification remains mandatory for Consolidated Payment

2.04.2014

1.3 Payment type definition page added to IntroductionPayment type detection rules explained in detail

19.06.2014


1.4 € added to whitelisted characters set.Specified characters restriction for domestic payments referencies, identifications and identifiersUpdated description of payment types and payment types detectionpain001:PrivateIdentification is accepted for InitiatingParty and Debtor.DebtorAgent Name is acepted. BIC changed to optionalIdentification SchemeName Codes for Domestic payments are updatedIdentification SchemeName Proprietary is accepted for SEPA cross-border paymentsCreditor CountryOfResidence rule in Latvia is updatedUltimateCreditor Name is optional fieldInformation about UltimateDebtor and UltimateCreditor PostalAddress is overpopulated and tags are removed from Swedbank MIGCustomer rules of RegulatoryReporting in Latvia updatedRemittanceInformation rules for Lithuania are updatedpain002:StatusReasonInformation added in following blocks: OriginalGroupInformationAndStatus, OriginalPaymentInformationAndStatusOriginator Identification and AccountServicerReference added to TransactionInformationAndStatus block

9.07.2015

1.5 Complemented explanations for: ChargeBearer type CRED xml escape characters: < > Consolidated payments execution priorityAligned terms: Payer changed to Creditor, field replaced with tagAdded reference to External code set at ISO 20022 sitePossibility to provide structured details for consolidated payments will appear in December, 2015.Complemented list of countries where SEPA payments can be made

16.11.2015


1.6 Originator added to pain002 in transaction level when payment is rejected Instruction ID is excluded from character validation

11.04.2016

1.7 Link replacement for regulatory reporting codes in LatviaReplaced example 4.3 with Latvian SCT example (regulatory reporting tags)General wording corrections

12.01.2017

1. Introduction The purpose with this document is to provide guidance about how the Payment ISO messages shall shall be structured when exchanging information between Customer and Swedbank for the following messages:-Pain.001.001.03 - used to initiate a credit transfer-Pain.002.001.03 - used to report on the status of a credit transfer initiation

This document should be read together with the ISO 20022 Message Definition Report since not all information have been repeated. Message elements that are not represented in this document will be viewed as overpopulated and will be ignored. External code set specification could be found at http://www.iso20022.org/external_code_list.page

This Message Implementation Guide complies with the international definitions for content and use of ISO20022, Common Global Implementation (CGI) recommendations and country MIG guidelines. In case of differences in documents please consult with bank about correct Swedbank ISO MIG usage.

Character set

In UNIFI messages the UTF8 encoding must be used. Encoding must be declared in the XML header.The Latin character set, which is commonly used for international communication, must be used.It contains the following characters: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 zA B C D E F G H I J K L M N O P Q R S T U V W X Y Z0 1 2 3 4 5 6 7 8 9/ - ? : ( ) . , ' + space

Local characters

In interbank Domestic Payments additionally local characters are allowed:In Estonia: Šš, Žž, Õõ, Ää, Öö, Üü In Latvia: Āā, Čč, Ēē, Ģģ, Īī, Ķķ, Ļļ, Ņņ, Šš, Ūū, ŽžIn Lithuania: Ąą, Čč, Ęę, Ėė, Įį, Šš, Ųų, Ūū, Žž

Whitelisted characters

Commonly used characters, which will be accepted, but replaced in domestic bank-to-bank message with ?, are:& % # | _ " ; = ! €

XML escape characters

Symbols not allowed in XML must be replaced in message according to escaping rules:& replaced with & < replaced with <" replaced with " > replaced with >' replaced with '

Characters for domestic payments references, identifications and identifiers

End-to-End ID, Transaction ID, Message ID, Payment Information ID, Creditor and Debtor ID, Ultimate Debtor/Creditor ID, Remittance ID, Proprietary codes must respect the following:• Content is restricted to the Latin character set • Content must not start or end with a ‘/’ • Content must not contain ‘//’s

Description on the columns:ISO Index NO – Number that refers to the corresponding description in the ISO 20022 XML Message Definition Report. This report can be found at www.iso20022.org under “Catalogue of ISO 20022 messages”Or – indicates that only one of several elements may be presentedMessage Item - Element name used in ISO 20022 XML Message Definition Report.Tag Name - Name that identifies an element within an XML message. Is based on the ISO 20022 XML Message Definition Report.ISO Type - Indicates the ISO typeMult - indicates whether an element is mandatory or optional and how many repetitions are allowed for the element. For example: [1..1] – shows that element is mandatory and can be presented only once [1..n] - shows that element is mandatory and can be presented 1 to n times [0..1] – shows that element is optional and can be presented only once [0..n] – shows that element is optional and can be presented 0 to n timesRules - Provides information of usage in Swedbank messages.

Description of payment types

Intrabank payment

- payment in any currency to other account in Swedbank

Domestic payment

- payment in euros to other local bank- Consolidated payment

Sub-type of Domestic payment, which combines Intrabank and Domestic of the same currency. It's defined with value SALA in tag CategoryPurpose/Code. Payments initiated with code SALA are presented on account statement as single entry for the users who are not permitted to view individual salary payments one by one.

European payment

- payment in euros to bank located in SEPA*It is mandatory to indicate Creditor's IBAN and Creditor Agent's BIC till 2016.02.01. ChargeBearer has to be set as SHAR or SLEV

International non-European payment

- payment in euros to bank located outside of European Economic Area- payment in any other currency to - other local bank - bank located in SEPA - bank located outside of SEPA

Swedbank group payment

- payment to a Creditor in Swedbank Sweden, Norway, Denmark, Finland, Estonia, Latvia or Lithuania. Approved currencies are SEK, NOK, DKK, EUR, USD. --------------------*SEPA:Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, French Guyana, Gibraltar, Guadeloupe, Hungary, Iceland, Ireland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Monaco, San Marino, Switzerland, The Netherlands, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, United Kingdom.Payments within one Baltic country are considered as domestic payments.

Order pain001 code

Intrabank, Swedbank group, Consolidated payment

Domestic*, European payment

International non-European (express currency)

International non-European (other currency)

STEP1 Local Instrument/Proprietary=NORM NORMAL NORMAL NORMAL NORMALSTEP2 Local Instrument/Proprietary=HIGH NORMAL URGENT URGENT URGENT

STEP3 Local Instrument/Proprietary=EXPR NORMAL URGENT EXPRESS URGENTSTEP4 Service Level/Code=SEPA NORMAL NORMAL NORMAL NORMAL

STEP5Service Level/Code=SEPA& Local Instrument/Code=ONCL NORMAL NORMAL NORMAL NORMAL

STEP6Service Level/Code=SEPA& Local Instrument/Code=SDCL NORMAL URGENT NORMAL NORMAL

STEP7 Service Level/Code=NURG NORMAL NORMAL NORMAL NORMALSTEP8 Service Level/Code=URGP NORMAL URGENT URGENT URGENTSTEP9 Service Level/Code=SDVA NORMAL URGENT EXPRESS URGENT

If customer indicates any other value in 2.8 <SvcLvl>/ <Cd>, in 2.11 <LclInstrm>/ <Cd>, in 2.33 <SvcLvl>/ <Cd> or

Payment type detection

Column Order indicates in which order system should check if there exists a specific combination, as stated in column pain.001 code

in 2.37 <LclInstrm>/ <Cd> then Bank accepts it and sets payment priority to NORMAL.

Payment type indentifying data is required at either PaymentInformation (PmtInf) or CreditTransferTransactionInformation (CdtTrfTxInf) level. Recommended usage is at PaymentInformation level. If present on both PmtInf level and CdtTrfTxInf level, then values given on CdtTrfxinf level are used.In case of conflicting values for ServiceLevel and LocalInstrument, the LocalInstrument values are used for payment type determination.

* Lithuania: Urgent Domestic payments are available starting from 2016.01.01. There should be taken Intrabank payment rules in 2015.

2. Customer Credit Transfer Initiation V3 pain.001.001.03

ISO

Index

No.

Or Message Item Tag Name Structural

Sequence

ISO Type Mult. Customer RULES

Customer Credit Transfer Initiation <CstmrCdtTrfInitn -

1.0 GroupHeader <GrpHdr> + [1..1]

1.1 MessageIdentification <MsgId> ++ Text [1..1] This Id will be stored for 90 days and will be used for duplicate control. Will be returned in

status report

1.2 CreationDateTime <CreDtTm> ++ DateTime [1..1]

1.6 NumberOfTransactions <NbOfTxs> ++ Text [1..1] Swedbank checks the given value with the total number of transactions in the entire

message.

1.7 ControlSum <CtrlSum> ++ Quantity [0..1] If given, Swedbank checks the given value with the total amount of all individual transactions

in the entire message.

1.8 InitiatingParty <InitgPty> ++ [1..1]

9.1.0 Name <Nm> +++ Text [0..1] Limited to 70 characters in length.

Ignored if it's the same as Debtor

9.1.12 Identification <Id> +++ [0..1] Accepted but not used at the moment.

9.1.13 {Or OrganisationIdentification <OrgId> ++++ [1..1]

9.1.15 Other <Othr> +++++ [1..1] Only one occurence is allowed, rest will be ignored

9.1.16 Identification <Id> ++++++ Text [1..1]

9.1.17 SchemeName <SchmeNm> ++++++ [0..1]

9.1.18 Code <Cd> +++++++ Code [1..1] Accepted code:

BANK

Other code values will be set to 'Bank'

9.1.21 Or} PrivateIdentification <PrvtId> ++++ [1..1] Either DateAndPlaceOfBirth or one occurence of Other is allowed

9.1.22 {{Or DateAndPlaceOfBirth <DtAndPlcOfBirth> +++++ [1..1]

9.1.23 BirthDate <BirthDt> ++++++ DateTime [1..1]

9.1.25 CityOfBirth <CityOfBirth> ++++++ Text [1..1]

9.1.26 CountryOfBirth <CtryOfBirth> ++++++ Code [1..1]

9.1.27 Or}} Other <Othr> +++++ [1..1] Only one occurence is allowed, rest will be ignored



9.1.30 Code <Cd> +++++++ Code [1..1]

2.0 PaymentInformation <PmtInf> + [1..n]

2.1 PaymentInformationIdentification <PmtInfId> ++ Text [1..1] Recommended to be unique. Will be returned in status report.

2.2 PaymentMethod <PmtMtd> ++ Code [1..1] Accepted code:

TRF

Other code values will be set to 'TRF'

Swedbank

of 45

ISO

Index

No.


Sequence


2.6 PaymentTypeInformation <PmtTpInf> ++ [0..1] Required at either PaymentInformation (PmtInf) or CreditTransferTransactionInformation

(CdtTrfTxInf) level. Recommended usage is at PaymentInformation level.

If present on both PmtInf level and CdtTrfTxInf level, then values given on CdtTrfxinf level

are used.

In case of conflicting values for ServiceLevel and LocalInstrument, the LocalInstrument values

are used for payment type determination.

2.8 ServiceLevel <SvcLvl> +++ [0..1]

2.9 Code <Cd> ++++ Code [1..1] Accepted codes:

NURG

SEPA

- if a payment fulfills the SEPA conditions the payment will automatically be an European or

Domestic payment depending on the payment instructions

URGP

- payment type is set to urgent for Domestic, European(SEPA Credit Transfer) and

International non-European payments

SDVA

- payment type is treated as urgent for Domestic, European and International non-European

payments (please look exeception below)

- payment type is set to express for International non-European payments in EUR, USD

(Estonia) and EUR, USD, SEK, GBP (Latvia)

Value dates and cut-off times of different payment types are available in Price List.

Empty or other values will be set to NURG or SEPA depending on payment instructions

2.11 LocalInstrument <LclInstrm> +++ [0..1]

2.12 {Or Code <Cd> ++++ Code [1..1] Accepted codes:

SDCL

If code is set to SDCL and 2.9 <Cd> is set to SEPA then payment type is set to urgent for

domestic and European payment

ONCL is not supported by Swedbank.

of 45

ISO

Index

No.


Sequence


2.13 Or} Proprietary <Prtry> ++++ Text [1..1] Accepted codes for Estonia and Latvia:

NORM

HIGH

- payment type is set to urgent for Domestic, European and International non-European

payments

EXPR


payments (please look execption below)




Other values will be set to NORM

2.14 CategoryPurpose <CtgyPurp> +++ [0..1]

2.15 Code <Cd> ++++ Code [1..1] Accepted codes:

SALA -Will be used for Consolidated Payment functionality. Indicator for consolidated

functionality can only be set at Payment Information level.

Other values will be ignored by Swedbank but forwarded to Beneficiary bank.

Requirements for Consolidated payment:

- file containing Consolidated payment(s) should not contain other payment types

- all underlying sub-payments in a Consolidated payment must be valid in order to be

accepted for processing.

- <InstrId> and <RmtInf> are mandatory for Consolidated payment. Only unstructured

details are acceptable. Possibility to provide structured details for consolidated payments

started in December, 2015.

- On camt messages Consolidated payment indicator is <BkTxCd><Prtry><Cd>MP

2,17 RequestedExecutionDate <ReqdExctnDt> ++ DateTime [1..1] Cannot be more than 365 days in future. Yesterday's date is converted to Current Date, older

dates are not accepted.

2.19 Debtor <Dbtr> ++ [1..1]

9.1.0 Name <Nm> +++ Text [0..1] Accepted but not used. The Debtor's name will be taken from Swedbank's customer database

and this value will be sent to the Beneficiary Bank.

9.1.1 PostalAddress <PstlAdr> +++ [0..1] Accepted but not used. The Debtor's postal address will be taken from Swedbank's customer

database.

9.1.10 Country <Ctry> ++++ Code [0..1] Accepted but not used.

9.1.11 AddressLine <AdrLine> ++++ Text [0..2] Accepted but not used. Only 2 occurences allowed, the rest will be ignored.

9.1.12 Identification <Id> +++ [0..1]

9.1.13 {Or OrganisationIdentification <OrgId> ++++ [1..1] Accepted but not used. The Debtor's ID will be taken from Swedbank's customer database

and this value will be sent to the CreditorAgent. 9.1.14 {{Or BICOrBEI <BICOrBEI> +++++ Identifier [1..1] Either BIC or BEI or one occurence of "Other" is allowed.




of 45

ISO

Index

No.


Sequence


9.1.18 Code <Cd> +++++++ Code [1..1]


Estonia, Latvia: Accepted but not used. The Debtor's ID will be taken from Swedbank's

customer database and this value will be sent to the CreditorAgent.

Lithuania: Provided ID will be frowarded to CreditorAgent.








9.1.30 Code <Cd> +++++++ Code [1..1]

2.20 DebtorAccount <DbtrAcct> ++ [1..1] Only IBAN is allowed


1.1.1 IBAN <IBAN> ++++ Identifier [1..1]

1.1.11 Currency <Ccy> +++ Code [0..1] Accepted but not used.

For European and International non-European payments cover currency will be taken from

the main account currency on the agreement in case there is not enough 2.43 Instructed

Amount currency on the account.

2.21 DebtorAgent <DbtrAgt> ++ [1..1]

6.1.0 FinancialInstitutionIdentification <FinInstnId> +++ [1..1]

6.1.1 BIC <BIC> ++++ Identifier [0..1]

6.1.7 Name <Nm> ++++ Text [0..1]

2.23 UltimateDebtor <UltmtDbtr> ++ [0..1] Accepted but not used. Forward to Beneficiary Bank when it's possible.

9.1.0 Name <Nm> +++ Text [0..1] Limited to 70 characters in length


9.1.13 {Or OrganisationIdentification <OrgId> ++++ [1..1] Either "BIC" or "BEI" or one occurence of "other" is allowed.

9.1.14 {{Or BICOrBEI <BICOrBEI> +++++ Identifier [1..1]

9.1.15 Or}} Other <Othr> +++++ [1..1]


9.1.17 SchemeName <SchmeNm> ++++++ [0..1] Either Code or Proprietary must be filled

9.1.18 {{Or Code <Cd> +++++++ Code [1..1] Code according ISO20022 external code set.

Recomended codes for Domestic Payments

Estonia: COID, CUST, TXID

Latvia: TXID

Lithuania: COID. Code according ISO20022 external code set.

of 45

ISO

Index

No.


Sequence


9.1.19 Or}} Proprietary <Prtry> +++++++ Text [1..1] Might be used for European cross-border payments.

It is ignored in case of domestic payments.






9.1.27 Or}} Other <Othr> +++++ [1..1]


9.1.29 SchemeName <SchmeNm> ++++++ [0..1] Either Code or Proprietary must be filled

9.1.30 {{Or Code <Cd> +++++++ Code [1..1] Code according ISO20022 external code set.


Estonia: NIDN, CUST, TXID

Latvia: NIDN

Lithuania: NIDN. Code according ISO20022 external code set.

9.1.31 Or}} Proprietary <Prtry> +++++++ Text [1..1] Might be used for European cross-border payments.


2.24 ChargeBearer <ChrgBr> ++ Code [0..1] Strongly recommended to use at this PaymentInformation (PmtInf) level.

If present on CdtTrfTxInf level and PmtInf level, then value given on CdtTrfTxInf level is

used.

Accepted codes:

DEBT- Not valid for SEPA

SHAR

SLEV

CRED - Not valid in Swedbank

If missing or not valid code, will be treated as SHAR

2.27 CreditTransferTransactionInformation <CdtTrfTxInf> ++ [1..n]

2.28 PaymentIdentification <PmtId> +++ [1..1]

2.29 InstructionIdentification <InstrId> ++++ Text [0..1] Optional starting from mid April 2014, except for Consolidated Payment.

Recommended to be unique in payment message. The value is not passed on to the

beneficiary. Returned in pain.002 message and in camt message of the payment initiator.

2.30 EndToEndIdentification <EndToEndId> ++++ Text [1..1] The value is forwarded to the beneficiary in case of European and Intrabank payments.

Recommended to be unique for better identification of transaction. Returned in pain.002 and

camt messages.

2.31 PaymentTypeInformation <PmtTpInf> +++ [0..1] Required at either PaymentInformation (PmtInf) or CreditTransferTransactionInformation

(CdtTrfTxInf) level. Recommended usage is at PaymentInformation level.

If present on both PmtInf level and CdtTrfTxInf level, then values given on CdtTrfxinf level

are used.

In case of conflicting values for ServiceLevel and LocalInstrument, the LocalInstrument values

are used for payment type determination.

of 45

ISO

Index

No.


Sequence


2.33 ServiceLevel <SvcLvl> ++++ [0..1]

2.34 Code <Cd> +++++ Code [1..1] Accepted codes:

NURG

SEPA

- if a payment fulfills the SEPA conditions the payment will automatically be an European or

Domestic payment depending on the payment instructions

URGP

- payment type is set to urgent for Domestic, European (SEPA Credit Transfer) and

International non-European payments

SDVA

- payment type is treated as urgent for Domestic, European and International non-European

payments (please look exeception below)




Empty or other values will be set to NURG or SEPA depending on payment instructions

2.36 LocalInstrument <LclInstrm> ++++ [0..1]

2.37 {Or Code <Cd> +++++ Code [1..1] Accepted codes:

SDCL

If code is set to SDCL and 2.9 <Cd> is set to SEPA then payment type is set to urgent for

domestic and European payment

ONCL is not supported by Swedbank.

2.38 Or} Proprietary <Prtry> +++++ Text [1..1] Accepted codes:

NORM

HIGH


payments

EXPR


payments (please look execption below)

- payment type is set to express for international non-European payments in EUR, USD

(Estonia, Lithuania) and EUR, USD, SEK, GBP, RUB (Latvia)


Other values will be set to NORM

2.39 CategoryPurpose <CtgyPurp> ++++ [0..1]

2.40 Code <Cd> +++++ Code [1..1] Indicator for Consolidated payment functionality should only be set at Payment information

level, see 2.14<CategoryPurpose><Cd>

2.42 Amount <Amt> +++ [1..1]

of 45

ISO

Index

No.


Sequence


2.43 InstructedAmount <InstdAmt

Ccy="AAA">

++++ Amount [1..1] Needs to be positive. Limited to 14 digits in total and 2 fraction digits. If Instructed Amount

Currency does not exist on the Debtor account in required amount, cover currency will be

set to the account main currency.

2.51 ChargeBearer <ChrgBr> +++ Code [0..1] Strongly recommended to use at PmtInf level.

If present on CdtTrfTxInf level and PmtInf level, then value given on CdtTrfTxInf level is

used.

Accepted codes:

DEBT- Not valid for SEPA

SHAR

SLEV

CRED - Not valid in Swedbank

If missing or not valid code, will be treated as SHAR

2.70 UltimateDebtor <UltmtDbtr> +++ [0..1] Only used at PmtInf level.

9.1.0 Name <Nm> ++++ Text [0..1] Limited to 70 characters in length

9.1.12 Identification <Id> ++++ [0..1]

9.1.13 {Or OrganisationIdentification <OrgId> +++++ [1..1] Either "BIC" or "BEI" or one occurence of "other" is allowed.

9.1.14 {{Or BICOrBEI <BICOrBEI> ++++++ Identifier [1..1]

9.1.15 Or}} Other <Othr> ++++++ [1..1]

9.1.16 Identification <Id> +++++++ Text [1..1]

9.1.17 SchemeName <SchmeNm> +++++++ [0..1] Either Code or Proprietary must be filled

9.1.18 {{Or Code <Cd> ++++++++ Code [1..1] Code according ISO20022 external code set.



Latvia: TXID

Lithuania: COID. Code according ISO20022 external code set acceptable after local Clearing

switch starting from 2016.01.01

9.1.19 Or}} Proprietary <Prtry> ++++++++ Text [1..1] Might be used for European cross-border payments.


9.1.21 Or} PrivateIdentification <PrvtId> +++++ [1..1] Either "DateAndPlaceOfBirth" or one occurence of "Other is allowed".

9.1.22 {{Or DateAndPlaceOfBirth <DtAndPlcOfBirth> ++++++ [1..1]

9.1.23 BirthDate <BirthDt> +++++++ DateTime [1..1]

9.1.25 CityOfBirth <CityOfBirth> +++++++ Text [1..1]

9.1.26 CountryOfBirth <CtryOfBirth> +++++++ Code [1..1]

9.1.27 Or}} Other <Othr> ++++++ [1..1]



of 45

ISO

Index

No.


Sequence





Latvia: NIDN

Lithuania: NIDN. Code according ISO20022 external code set acceptable after local Clearing



It is ignored in case of domestic payments. 2.71 IntermediaryAgent1 <IntrmyAgt1> +++ [0..1] Only valid for for International non-European Payments, when applicable. Used to indicate

correspondent bank of Creditor Agent

6.1.0 FinancialInstitutionIdentification <FinInstnId> ++++ [1..1]

6.1.1 BIC <BIC> +++++ Identifier [0..1]

6.1.7 Name <Nm> +++++ Text [0..1] Only 70 characters

RUB payments: the data of the parent bank - full name + city + BIK of the parent bank (9

digits) + correspondent account of the parent bank in the Central Bank of the Russian

Federation (20 digits, starts with 301) 6.1.8 PostalAddress <PstlAdr> +++++ [0..1]

6.1.17 Country <Ctry> ++++++ Code [0..1]

6.1.18 AddressLine <AdrLine> ++++++ Text [0..2] Only two occurences accepted

2.72 IntermediaryAgent1Account <IntrmyAgt1Acct> +++ [0..1]


1.1.1 {Or IBAN <IBAN> +++++ Identifier [1..1]

1.1.2 Or} Other <Othr> +++++ [1..1]


2.73 IntermediaryAgent2 <IntrmyAgt2> +++ [0..1] Only valid for for International non-European payments, when applicable.


6.1.1 BIC <BIC> +++++ Identifier [0..1]


6.1.8 PostalAddress <PstlAdr> +++++ [0..1]



2.74 IntermediaryAgent2Account <IntrmyAgt2Acct> +++ [0..1] 1.1.0 Identification <Id> ++++ [1..1]


1.1.2 Or} Other <Othr> +++++ [1..1]


2.77 CreditorAgent <CdtrAgt> +++ [0..1] In case of Domestic Payment – whole block of Creditor Agent is ignored (e.g. if BIC belongs

to SEB EE but Creditor Account IBAN belongs to Nordea EE

then payment order is not rejected but processed according to IBAN)

International non-European payment - either CreditorAgent/BIC or CreditorAgent/Name (or

both) must be filled.

European Payment (SEPA Credit Transfer) - if currency=EUR and CreditorAgent IBAN starts

with country code of EU/EEA then CreditorAgent/BIC tag was mandatory untill 2016.02.01.

of 45

ISO

Index

No.


Sequence



6.1.1 BIC <BIC> +++++ Identifier [0..1] In case of European payments BIC was mandatory until 2016.02.01.

6.1.2 ClearingSystemMemberIdentification <ClrSysMmbId> +++++ [0..1] Accepted but not used. Currently not supported in Swedbank

6.1.3 ClearingSystemIdentification <ClrSysId> ++++++ [0..1]

6.1.4 Code <Cd> +++++++ Code [1..1]

6.1.6 MemberIdentification <MmbId> ++++++ Text [1..1]


RUB payment - full name of the Creditor's Agent + city + BIC of the Creditor Agent (9 digits)

+ correspondent account of the Creditor's Agent in the Central Bank of the Russian

Federation (20 digits, starts with 301). The last three digits of the BIC and the correspondent

account must coincide.

In case Creditor's Agent is a branch of the bank: the name of the branch and the account are

inserted in the tag CreditorAgent/Name

6.1.8 PostalAddress <PstlAdr> +++++ [0..1]



2.78 CreditorAgentAccount <CdtrAgtAcct> +++ [0..1] 1.1.0 Identification <Id> ++++ [1..1]


1.1.2 Or} Other <Othr> +++++ [1..1]


2.79 Creditor <Cdtr> +++ [1..1]

9.1.0 Name <Nm> ++++ Text [1..1] Only 70 characters

RUB payment - the taxpayer identification number or INN (and KPP) is inserted in the tag

Creditor/Name before the name. If the Creditor's name is too long, the remainder of the

name must be written in the PstlAdr/AdrLine tag without any spaces (without a hyphen).

9.1.1 PostalAddress <PstlAdr> ++++ [0..1] Forward if possible

9.1.10 Country <Ctry> +++++ Code [0..1]

9.1.11 AddressLine <AdrLine> +++++ Text [0..2] Only two occurences accepted, total length max 70 characters


9.1.13 {Or OrganisationIdentification <OrgId> +++++ [1..1]

9.1.14 {{Or BICOrBEI <BICOrBEI> ++++++ Identifier [1..1] Either BIC or BEI or one occurence of "Other" is allowed.

9.1.15 Or}} Other <Othr> ++++++ [1..1]



of 45

ISO

Index

No.


Sequence





Latvia: TXID

Lithuania: COID, CUST. Code according ISO20022 external code set acceptable after local

Clearing switch starting from 2016.01.01



9.1.21 Or} PrivateIdentification <PrvtId> +++++ [1..1] Either DateAndPlaceOfBirth or one occurence of "Other" is allowed.





9.1.27 Or}} Other <Othr> ++++++ [1..1]






Latvia: NIDN

Lithuania: NIDN, CUST. Code according ISO20022 external code set acceptable after local

Clearing switch starting from 2016.01.01



9.1.33 CountryOfResidence <CtryOfRes> ++++ Code [0..1] Latvia: User shall provide Country Of Recidence if Creditor is non-resident, exluding when

both Debtor and Creditor are non-residents and the amount ≥ 10000EUR

2.80 CreditorAccount <CdtrAcct> +++ [1..1]


1.1.1 {Or IBAN <IBAN> +++++ Identifier [1..1] In case of Domestic and European payment IBAN is mandatory

1.1.2 Or} Other <Othr> +++++ [1..1]

1.1.3 Identification <Id> ++++++ Text [1..1] RUB payment - a 20-digit number, the digits 6-8 of which are 810

2.81 UltimateCreditor <UltmtCdtr> +++ [0..1] Only forwarded with Domestic and European payment (except payment with type urgent)

9.1.0 Name <Nm> ++++ Text [0..1] Only 70 character


9.1.13 {Or OrganisationIdentification <OrgId> +++++ [1..1] Either "BIC" or "BEI" or one occurence of "other" is allowed.

9.1.14 {{Or BICOrBEI <BICOrBEI> ++++++ Identifier [1..1]

9.1.15 Or}} Other <Othr> ++++++ [1..1] Only one occurence is allowed, rest will be ignored



of 45

ISO

Index

No.


Sequence





Latvia: TXID

Lithuania: COID. Code according ISO20022 external code set.



9.1.21 Or} PrivateIdentification <PrvtId> +++++ [1..1] Either "DateAndPlaceOfBirth" or one occurence of "Other is allowed".





9.1.27 Or}} Other <Othr> ++++++ [1..1]






Latvia: NIDN

Lithuania: NIDN. Code according ISO20022 external code set acceptable after local Clearing




2.86 Purpose <Purp> +++ [0..1]

2.87 Code <Cd> ++++ Code [1..1] Code according to ISO20022 external code set.

2.89 RegulatoryReporting <RgltryRptg> +++

[0..1]

[0..0]

Information about declaration of payments.

Only one occurence allowed, rest is ignored

Latvia:

Regulatory reporting is mandatory if one of the parties is resident and another party is not

resident(i.e. exluding when both Debtor and Creditor are residents or both Debtor and

Creditor are non-residents) and the amount >= 10000EUR

Estonia, Lithuania:

Is not used, information will be ignored

11.1.4 Details <Dtls> ++++ [0..2] Latvia:

Only two occurences are valid the rest are ignored.

11.1.5 Type <Tp> +++++ Text [0..1] Latvia:

Should contain EKK when budget income code is transferred in <Cd> (11.1.8)

Should contain AMK when external payment code is transferred in <Cd> (11.1.8)

11.1.7 Country <Ctry> +++++ Code [0..1] Country ISO code (ISO 3166, Alpha-2 code), see

http://www.iso.org/iso/country_codes/iso_3166_code_lists/country_names_and_code_eleme

nts.htm

of 45

ISO

Index

No.


Sequence


11.1.8 Code <Cd> +++++ Text [1..1] Latvia:

Code of the balance of payment. For appropriate code see:

ttp://likumi.lv/doc.php?id=258772#piel3

If tag <Tp> (11.1.5) contains code EKK then the code value should contain budget income

code

11.1.10 Information <Inf> +++++ Text [0..1]

2.98 RemittanceInformation <RmtInf> +++ [0..1] Domestic Payments:

Estonia: unstructured or structured remittance information or both needs to be present. When

the client fills both, the structured and unstructured information tags, only 130 characters of

combined length is accepted. When bank cannot forward both tags, then creditor reference

under the structured information will be lifted to the unstructured information tag in

accordance with EACT standard for unstructured remittance information formatting rules. If

the remittance information as a result will be longer than 140 characters, then the bank will

deliver only 140 characters of the remittance information. For example

/RFB/XXXXXX/TXT/ZZZZZZ, where RFB stands for the code of creditor reference, XXXXXX

stands for the creditor reference, TXT stands for the code of unstructured information and

ZZZZZZ stands for the unstructured information.

Latvia: Either unstructured or structured remittance information must be present but not

both. Creditor reference under the structured information will be copied to the unstructured

information tag in accordance with EACT standard for unstructured remittance information

formatting rules - to assure compatibility with legacy statement formats.

Lithuania: Either unstructured or structured remittance information must be present but not

both.

European Payment: Either unstructured or structured remittance information must be present

but not both.

International non-European payments: Only unstructured remittance information is accepted.

of 45

ISO

Index

No.


Sequence


2.99 Unstructured <Ustrd> ++++ Text [0..1] Only 1 occurence allowed with maximum 140 Characters.

Estonia:

If unstructured and structured references are both used the maximum accepted combined

length is 130.

If in Domestic payment information is filled in accordance of EACT standard for Unstructured

remittance information formatting rules, RFB value will be validated by same rules as

Structured Reference. In case of successful validation, the information is stored to separate

values for payment initiator's account statement => Payment details and Creditor Reference.

International non-European payment in RUB - currency transaction code (VO) + verbal

clarification of the payment (detailed information about goods/service, if payment is executed

before goods are delivered then should be written predoplata za...., if payment is executed

after goods are delivered then oplata za....) + commercial invoice and/or contract number,

date + VAT amount (NDS). If no tax is imposed on the goods or services, “BEZ NDS” must be

added.

2.100 Structured <Strd> ++++ [0..1] Only 1 occurence of "Structured" is allowed.

2.120 CreditorReferenceInformation <CdtrRefInf> +++++ [1..1]

2.121 Type <Tp> ++++++ [1..1]

2.122 CodeOrProprietary <CdOrPrtry> +++++++ [1..1]

2.123 Code <Cd> ++++++++ Code [1..1] Accepted values is SCOR.

All other values will be set to SCOR .

2.125 Issuer <Issr> +++++++ Text [0..1] ISO in case of ISO11649 reference number

2.126 Reference <Ref> ++++++ Text [1..1] If Creditor Reference Information is used, Reference must be included.

Estonia:

When reference number is filled in Domestic Payment, the correctness of reference number is

checked against Estonian reference number standard. For information about Estonian

reference number standard see http://www.pangaliit.ee/en/settlements-and-

standards/reference-number-of-the-invoice. ISO11649 reference number is accepted and the

correctness validated

Latvia, Lithuania:

No validations are performed on the value currently

of 45

3. Customer Payment Status Report pain.002.001.03

ISO

Index

No.


Sequence

Type Mult. RULES

0.0 Customer Payment Status Report <CstmrPmtStsRpt> - [1..1]

1.0 GroupHeader <GrpHdr> + [1..1]

1.1 MessageIdentification <MsgId> ++ Text [1..1]

1.2 CreationDateTime <CreDtTm> ++ DateTime [1..1]

1.3 InitiatingParty <InitgPty> ++ [1..1]


9.1.13 OrganisationIdentification <OrgId> ++++ [1..1]

9.1.14 BICOrBEI <BICOrBEI> +++++ Identifier [1..1]

2.0 OriginalGroupInformationAndStatus <OrgnlGrpInfAndSts> + [1..1]

2.1 OriginalMessageIdentification <OrgnlMsgId> ++ Text [1..1] <GrpHdr>

+<MsgId> value from corresponding C2B pain.001 file

2.2 OriginalMessageNameIdentification <OrgnlMsgNmId> ++ Text [1..1] Specifies the original message name identifier to which the message refers, e.g.

pain.001.001.03

2.4 OriginalNumberOfTransactions <OrgnlNbOfTxs> ++ Text [1..1] NumberOfTransactions from the Credit Transfer file

(pain.001.001.03)

2.5 OriginalControlSum <OrgnlCtrlSum> ++ Quantity [0..1] ControlSum from the Credit Transfer file

(pain.001.001.03)

2.6 GroupStatus <GrpSts> ++ Code [0..1] Status codes used by Swedbank:

RJCT - in case the whole file was rejected.

PART - Partially accepted, at least one payment in response is in ACSP status

ACSP - All preceding checks such as technical validation and customer profile were

successful within the whole file.

ACSC - Settlement on the debtor’s account has been completed for all payments in the

file.

GroupStatus is not sent with the final processing messages of Consolidated Payment,

International payment and European payment. 2.7 StatusReasonInformation <StsRsnInf> ++ [0..n] 2.8 Originator <Orgtr> +++ [0..1]


9.1.13 OrganisationIdentification <OrgId> +++++ [1..1]

9.1.14 BICOrBEI <BICOrBEI> ++++++ Identifier [0..1]

2.9 Reason <Rsn> +++ [1..1] Specifies the reason for the status report 2.10 Code <Cd> ++++ Code [1..1]

2.12 AdditionalInformation <AddtlInf> +++ Text [0..n] Swedbank Gateway error description.

3.0 OriginalPaymentInformationAndStatus <OrgnlPmtInfAndSts> + [0..n]

3.1 OriginalPaymentInformationIdentification <OrgnlPmtInfId> ++ Text [1..1] <PmtInfId> value from corresponding C2B pain.001 file

3.4 PaymentInformationStatus <PmtInfSts> ++ Code [0..1] Status codes used by Swedbank:

RJCT - in case the whole payment initiation block was rejected.

PART - Partially accepted


successful within the payment information block.

ACSC - Settlement on the debtor’s account has been completed for all payments in

payment information block.

Swedbank

of 45

ISO

Index

No.


Sequence

Type Mult. RULES

3.5 StatusReasonInformation <StsRsnInf> ++ [0..n]

3.6 Originator <Orgtr> +++ [0..1]


9.1.13 OrganisationIdentification <OrgId> +++++ [1..1]

9.1.14 BICOrBEI <BICOrBEI> ++++++ Identifier [0..1]

3.7 Reason <Rsn> +++ [1..1] Specifies the reason for the status report

3.8 Code <Cd> ++++ Code [1..1]

3.10 AdditionalInformation <AddtlInf> +++ Text [0..n] Swedbank Gateway error description.

3.15 TransactionInformationAndStatus <TxInfAndSts> ++ [0..n]

3.17 OriginalInstructionIdentification <OrgnlInstrId> +++ Text [1..1]

3.18 OriginalEndToEndIdentification <OrgnlEndToEndId> +++ Text [1..1]

3.19 TransactionStatus <TxSts> +++ Code [1..1] Status codes used by Swedbank:

RJCT - in case the transaction was rejected.


successfull.

ACSC – Settlement on the debtor’s account has been completed.

In case of Swedbank Payments (intrabank) successful checks such as technical

validation, customer profile and sufficient available balance produce ACSC status

immediately, ACSP will be skipped.

3.20 StatusReasonInformation <StsRsnInf> +++ [1..1]

3.21 Originator <Orgtr> ++++ [0..1] Identification of the Type of Party that initiated the reject. Limited to BIC to identify the

bank or CSM originating the status or ‘Name’ to indicate a CSM when it has no BIC.

‘Name’ is limited to 70 characters in length. Party that issues the status.

9.1.12 Identification <Id> +++++ [0..1]

9.1.13 OrganisationIdentification <OrgId> ++++++ [1..1]

9.1.14 BICOrBEI <BICOrBEI> +++++++ Identifier [0..1]

3.22 Reason <Rsn> ++++ [1..1] Specifies the reason for the status report

3.23 Code <Cd> +++++ Code [1..1]

3.25 AdditionalInformation <AddtlInf> ++++ Text [1..1] Swedbank Gateway error description.

3.30 AccountServicerReference <AcctSvcrRef> +++ Text [0..1]

3.32 OriginalTransactionReference <OrgnlTxRef> +++ [0..1]

3.34 Amount <Amt> ++++ [0..1] Not reported for Consolidated payments

3.35 InstructedAmount <InstdAmt Ccy="AAA"> +++++ Amount [1..1]

3.41 RequestedExecutionDate <ReqdExctnDt> ++++ DateTime [1..1]

3.121 Debtor <Dbtr> ++++ [1..1]

9.1.0 Name <Nm> +++++ Text [1..1]

3.122 DebtorAccount <DbtrAcct> ++++ [1..1]


1.1.1 IBAN <IBAN> ++++++ Identifier [1..1]

1.1.11 Currency <Ccy> +++++ Code [1..1]

3.123 DebtorAgent <DbtrAgt> ++++ [1..1]

6.1.0 FinancialInstitutionIdentification <FinInstnId> +++++ [1..1]

6.1.1 BIC <BIC> ++++++ Identifier [1..1]

3.125 CreditorAgent <CdtrAgt> ++++ [0..1]

6.1.0 FinancialInstitutionIdentification <FinInstnId> +++++ [1..1]

6.1.1 {Or BIC <BIC> ++++++ Identifier [1..1]

of 45

ISO

Index

No.


Sequence

Type Mult. RULES

6.1.2 Or} ClearingSystemMemberIdentification <ClrSysMmbId> ++++++ [1..1]

6.1.3 ClearingSystemIdentification <ClrSysId> +++++++ [0..1]

6.1.4 Code <Cd> ++++++++ Code [1..1]

6.1.6 MemberIdentification <MmbId> +++++++ Text [1..1]

3.127 Creditor <Cdtr> ++++ [1..1]

9.1.0 Name <Nm> +++++ Text [1..1]

3.128 CreditorAccount <CdtrAcct> ++++ [1..1]


1.1.1 {Or IBAN <IBAN> ++++++ Identifier [1..1]

1.1.2 Or} Other <Othr> ++++++ [1..1]


of 45

3.1 Statuses in Pain002

4. Examples

4.1 Domestic Payment Estonia, 2 payments:

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

<Document xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03">

<CstmrCdtTrfInitn>

<GrpHdr>

<MsgId>201111251</MsgId>

<CreDtTm>2013-08-30T11:16:58.696</CreDtTm>

<NbOfTxs>2</NbOfTxs>

<CtrlSum>1</CtrlSum>

<InitgPty>

<Nm>ETTEVÕTE AS</Nm>

</InitgPty>

</GrpHdr>

<PmtInf>

<PmtInfId>PMTID005</PmtInfId>

<PmtMtd>TRF</PmtMtd>


<PmtTpInf>

<SvcLvl>

<Cd>SEPA</Cd>

</SvcLvl>

</PmtTpInf>

<ReqdExctnDt>2013-09-26</ReqdExctnDt>

<Dbtr>


<PstlAdr>

<Ctry>EE</Ctry>

<AdrLine>Metsa 8, Tallinn</AdrLine>

</PstlAdr>

<Id>

<OrgId>

<Othr>

<Id>123456789</Id>

</Othr>

</OrgId>

</Id>

</Dbtr>

<DbtrAcct>

<Id>

<IBAN>EE942200221017496868</IBAN>

</Id>

<Ccy>EUR</Ccy>

</DbtrAcct>

<DbtrAgt>

<FinInstnId>

<BIC>HABAEE2X</BIC>

</FinInstnId>

</DbtrAgt>

<ChrgBr>SLEV</ChrgBr>

<CdtTrfTxInf>

<PmtId>

<InstrId>115</InstrId>

<EndToEndId>327</EndToEndId>

</PmtId>

<Amt>

<InstdAmt Ccy="EUR">0.15</InstdAmt>

</Amt>

<Cdtr>

<Nm>FIRMA AS</Nm>

<PstlAdr>

<Ctry>EE</Ctry>

<AdrLine>Leevikese 5,Tallinn</AdrLine>

</PstlAdr>

<Id>

<OrgId>

<Othr>

<Id>100000009</Id>

</Othr>

</OrgId>

</Id>

</Cdtr>

<CdtrAcct>

<Id>

<IBAN>EE572200221017496855</IBAN>

</Id>

</CdtrAcct>

<RmtInf>

<Strd>

<CdtrRefInf>

<Tp>

<CdOrPrtry>

<Cd>SCOR</Cd>

</CdOrPrtry>

</Tp>

<Ref>8806947</Ref>

</CdtrRefInf>

</Strd>

</RmtInf>

</CdtTrfTxInf>

<CdtTrfTxInf>

<PmtId>



</PmtId>

<Amt>


</Amt>

<Cdtr>

<Nm>Mari Ööbik</Nm>

<PstlAdr>

<Ctry>EE</Ctry>

<AdrLine>Pronksi 12, Tallinn</AdrLine>

</PstlAdr>

<Id>

<PrvtId>

<Othr>

<Id>48606112009</Id>

</Othr>

</PrvtId>

</Id>

</Cdtr>

<CdtrAcct>

<Id>

<IBAN>EE142200221000127063</IBAN>

</Id>

</CdtrAcct>

<RmtInf>

<Ustrd>Here enter payment details</Ustrd>

<Strd>

<CdtrRefInf>

<Tp>

<CdOrPrtry>

<Cd>SCOR</Cd>

</CdOrPrtry>

</Tp>

<Ref>88069474660</Ref>

</CdtrRefInf>

</Strd>

</RmtInf>

</CdtTrfTxInf>

</PmtInf>

</CstmrCdtTrfInitn>

</Document>

4.2 International Payment example (express payment in USD, via correspondent bank):



<CstmrCdtTrfInitn>

<GrpHdr>





<InitgPty>


</InitgPty>

</GrpHdr>

<PmtInf>




<PmtTpInf>

<SvcLvl>

<Cd>SDVA</Cd>

</SvcLvl>

</PmtTpInf>


<Dbtr>


<PstlAdr>

<Ctry>EE</Ctry>


</PstlAdr>

</Dbtr>

<DbtrAcct>

<Id>

<IBAN>EE942200221017496868</IBAN>

</Id>

<Ccy>USD</Ccy>

</DbtrAcct>

<DbtrAgt>

<FinInstnId>

<BIC>HABAEE2X</BIC>

</FinInstnId>

</DbtrAgt>

<ChrgBr>DEBT</ChrgBr>

<CdtTrfTxInf>

<PmtId>



</PmtId>

<Amt>

<InstdAmt Ccy="USD">5</InstdAmt>

</Amt>

<IntrmyAgt1>

<FinInstnId>

<BIC>BKTRUS33</BIC>

<Nm>Deutche Bank Trust</Nm>

<PstlAdr>

<AdrLine>New York 60 Wall Street</AdrLine>

</PstlAdr>

</FinInstnId>

</IntrmyAgt1>

<IntrmyAgt1Acct>

<Id>

<Othr>

<Id>1234567890</Id>

</Othr>

</Id>

</IntrmyAgt1Acct>

<CdtrAgt>

<FinInstnId>

<BIC>SWEDSESS</BIC>

<Nm>Swedbank AB Sweden</Nm>

<PstlAdr>

<AdrLine>Stockholm Brunkebergstorg 8</AdrLine>

</PstlAdr>

</FinInstnId>

</CdtrAgt>

<CdtrAgtAcct>

<Id>

<Othr>

<Id>987654321</Id>

</Othr>

</Id>

</CdtrAgtAcct>

<Cdtr>

<Nm>Beneficiary Test1</Nm>

<PstlAdr>

<Ctry>SE</Ctry>

<AdrLine>Stockholm Ridmansgatan 3F</AdrLine>

</PstlAdr>

</Cdtr>

<CdtrAcct>

<Id>

<Othr>

<Id>56949203947</Id>

</Othr>

</Id>

</CdtrAcct>

<RgltryRptg>

<Dtls>

<Ctry>SE</Ctry>

<Cd>310</Cd>

</Dtls>

</RgltryRptg>

<RmtInf>

<Ustrd>Test payment in USD dollars with express payment type</Ustrd>

</RmtInf>

</CdtTrfTxInf>

</PmtInf>

</CstmrCdtTrfInitn>

</Document>

4.3 European Payment example (Sepa Credit Transfer, LAT example with regulatory reporting)

<?xml version="1.0" encoding="utf-8"?><Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03">

<CstmrCdtTrfInitn><GrpHdr>

<MsgId>201111251</MsgId><CreDtTm>2016-12-21T12:00:32</CreDtTm><NbOfTxs>1</NbOfTxs><CtrlSum>10000</CtrlSum><InitgPty>

<Nm>FIRMALV AS</Nm><Id>

<OrgId><Othr>

<Id>40000000001</Id><SchmeNm>

<Cd>TXID</Cd></SchmeNm>

</Othr></OrgId>

</Id></InitgPty>

</GrpHdr><PmtInf>

<PmtInfId>PMTID123456789</PmtInfId><PmtMtd>TRF</PmtMtd><BtchBookg>false</BtchBookg><NbOfTxs>1</NbOfTxs><PmtTpInf>

<SvcLvl><Cd>SEPA</Cd>

</SvcLvl><LclInstrm>

<Prtry>NORM</Prtry></LclInstrm>

</PmtTpInf><ReqdExctnDt>2016-12-21</ReqdExctnDt><Dbtr>

<Nm>FIRMALV AS</Nm><PstlAdr>

<Ctry>LV</Ctry><AdrLine>Adrese, Rīga, Latvija, LV-1000</AdrLine>

</PstlAdr><Id>

<OrgId><Othr>

<Id>40000000001</Id><SchmeNm>

<Cd>TXID</Cd></SchmeNm>

</Othr></OrgId>

</Id></Dbtr><DbtrAcct>

<Id><IBAN>LV45HABA0000000000000</IBAN>

</Id><Ccy>EUR</Ccy>

</DbtrAcct><DbtrAgt>

<FinInstnId><BIC>HABALV22</BIC>

</FinInstnId></DbtrAgt><ChrgBr>SHAR</ChrgBr><CdtTrfTxInf>

<PmtId>

<InstrId>123456</InstrId><EndToEndId>123456</EndToEndId>

</PmtId><Amt>

<InstdAmt Ccy="EUR">10000.00</InstdAmt></Amt><CdtrAgt>

<FinInstnId><BIC>HABAEE2X</BIC>

</FinInstnId></CdtrAgt><Cdtr>

<Nm>FIRMA AS</Nm><PstlAdr>

<Ctry>EE</Ctry><AdrLine>Leevikese 5,Tallinn</AdrLine>

</PstlAdr>

<Id><OrgId>

<Othr>

<Id>100000009</Id>

<SchmeNm><Cd>TXID</Cd>

</SchmeNm></Othr>

</OrgId></Id><CtryOfRes>EE</CtryOfRes>

</Cdtr>

<CdtrAcct>

<Id><IBAN>EE000000000000000000</IBAN>

</Id></CdtrAcct>

<RgltryRptg>

<Authrty>

<Ctry>LV</Ctry>

</Authrty>

<Dtls><Tp>AMK</Tp><Cd>111</Cd>

</Dtls></RgltryRptg><RmtInf>

<Ustrd>123456</Ustrd>

</RmtInf></CdtTrfTxInf>

</PmtInf></CstmrCdtTrfInitn>

</Document>

4.4 Consolidated Payment example



<CstmrCdtTrfInitn>

<GrpHdr>




<CtrlSum>0.6</CtrlSum>

<InitgPty>

<Nm>AS MKONTSERN</Nm>

</InitgPty>

</GrpHdr>

<PmtInf>




<PmtTpInf>

<SvcLvl>

<Cd>SEPA</Cd>

</SvcLvl>

<CtgyPurp>

<Cd>SALA</Cd>

</CtgyPurp>

</PmtTpInf>


<Dbtr>

<Nm>AS MKONTSERN</Nm>

<PstlAdr>

<Ctry>EE</Ctry>

<AdrLine>Liivalaia, Tallinn</AdrLine>

</PstlAdr>

</Dbtr>

<DbtrAcct>

<Id>

<IBAN>EE892200221000214468</IBAN>

</Id>

<Ccy>EUR</Ccy>

</DbtrAcct>

<DbtrAgt>

<FinInstnId>

<BIC>HABAEE2X</BIC>

</FinInstnId>

</DbtrAgt>

<ChrgBr>SLEV</ChrgBr>

<CdtTrfTxInf>

<PmtId>



</PmtId>

<Amt>


</Amt>

<Cdtr>

<Nm>MARI METS</Nm>

<PstlAdr>

<Ctry>EE</Ctry>


</PstlAdr>

</Cdtr>

<CdtrAcct>

<Id>

<IBAN>EE142200221000127063</IBAN>

</Id>

</CdtrAcct>

<RmtInf>

<Ustrd>september salary</Ustrd>

</RmtInf>

</CdtTrfTxInf>

<CdtTrfTxInf>

<PmtId>



</PmtId>

<Amt>


</Amt>

<Cdtr>

<Nm>MAGNUS MERI</Nm>

<PstlAdr>

<Ctry>EE</Ctry>

<AdrLine>Siinseal, Tallinn</AdrLine>

</PstlAdr>

</Cdtr>

<CdtrAcct>

<Id>

<IBAN>EE602200221000235748</IBAN>

</Id>

</CdtrAcct>

<RmtInf>


</RmtInf>

</CdtTrfTxInf>

<CdtTrfTxInf>

<PmtId>



</PmtId>

<Amt>


</Amt>

<Cdtr>

<Nm>AADU KALA</Nm>

<PstlAdr>

<Ctry>EE</Ctry>


</PstlAdr>

</Cdtr>

<CdtrAcct>

<Id>

<IBAN>EE602200221000235748</IBAN>

</Id>

</CdtrAcct>

<RmtInf>


</RmtInf>

</CdtTrfTxInf>

</PmtInf>

</CstmrCdtTrfInitn>

</Document>

4.5 International payment in Russian roubles example (via correspondent bank)



<CstmrCdtTrfInitn>

<GrpHdr>





<InitgPty>


</InitgPty>

</GrpHdr>

<PmtInf>




<PmtTpInf>

<SvcLvl>

<Cd>NURG</Cd>

</SvcLvl>

</PmtTpInf>


<Dbtr>


<PstlAdr>

<Ctry>EE</Ctry>


</PstlAdr>

</Dbtr>

<DbtrAcct>

<Id>

<IBAN>EE942200221017496868</IBAN>

</Id>

<Ccy>EUR</Ccy>

</DbtrAcct>

<DbtrAgt>

<FinInstnId>

<BIC>HABAEE2X</BIC>

</FinInstnId>

</DbtrAgt>

<ChrgBr>DEBT</ChrgBr>

<CdtTrfTxInf>

<PmtId>



</PmtId>

<Amt>

<InstdAmt Ccy="RUB">5</InstdAmt>

</Amt>

<IntrmyAgt1>

<FinInstnId>

<Nm>OAO AKB Probiznesbank, g.Moskva, 044525986.30101810600000000986</Nm>

</FinInstnId>

</IntrmyAgt1>

<CdtrAgt>

<FinInstnId>

<Nm>Vernadskoe otdelenie 9038, 303xxxxxxxxxxxxxxxxx</Nm>

</FinInstnId>

</CdtrAgt>

<Cdtr>

<Nm>INN1234567891.KPP123456001 OOO Severnyy Tr/e/vel</Nm>

</Cdtr>

<CdtrAcct>

<Id>

<Othr>

<Id>41234810487623900000</Id>

</Othr>

</Id>

</CdtrAcct>

<RgltryRptg>

<Dtls>

<Ctry>RU</Ctry>

<Cd>310</Cd>

</Dtls>

</RgltryRptg>

<RmtInf>

<Ustrd>(VO20100) predoplata za transportnye uslugi, schet no.5 ot 15.10.2013, NDS 5.00 RUB</Ustrd>

</RmtInf>

</CdtTrfTxInf>

</PmtInf>

</CstmrCdtTrfInitn>

</Document>

4.6 Payment status report pain.002.001.03 example (accepted)


<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03">

<CstmrPmtStsRpt>

<GrpHdr>

<MsgId>20131115-093012731-466-1816/2325</MsgId>

<CreDtTm>2013-11-22T15:50:34</CreDtTm>

<InitgPty>

<Id>

<OrgId>

<BICOrBEI>HABAEE2X</BICOrBEI>

</OrgId>

</Id>

</InitgPty>

</GrpHdr>

<OrgnlGrpInfAndSts>

<OrgnlMsgId>201111251</OrgnlMsgId>

<OrgnlMsgNmId>pain.001.001.03</OrgnlMsgNmId>

<OrgnlNbOfTxs>1</OrgnlNbOfTxs>

<OrgnlCtrlSum>1.6</OrgnlCtrlSum>

<GrpSts>ACSC</GrpSts>

</OrgnlGrpInfAndSts>

<OrgnlPmtInfAndSts>

<OrgnlPmtInfId>PMTID006</OrgnlPmtInfId>

<PmtInfSts>ACSC</PmtInfSts>

<TxInfAndSts>

<OrgnlInstrId>315</OrgnlInstrId>

<OrgnlEndToEndId>527</OrgnlEndToEndId>

<TxSts>ACSC</TxSts>

<OrgnlTxRef>

<Amt>


</Amt>


<Dbtr>


</Dbtr>

<DbtrAcct>

<Id>

<IBAN>EE942200221017496868</IBAN>

</Id>

</DbtrAcct>

<DbtrAgt>

<FinInstnId>

<BIC>HABAEE2X</BIC>

</FinInstnId>

</DbtrAgt>

<CdtrAgt>

<FinInstnId>

<BIC>HABAEE2X</BIC>

</FinInstnId>

</CdtrAgt>

<Cdtr>

<Nm>FIRMA AS</Nm>

</Cdtr>

<CdtrAcct>

<Id>

<IBAN>EE572200221017496855</IBAN>

</Id>

</CdtrAcct>

</OrgnlTxRef>

</TxInfAndSts>

</OrgnlPmtInfAndSts>

</CstmrPmtStsRpt>

</Document>

4.7 Payment status report pain.002.001.03 example (rejected)


<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03">

<CstmrPmtStsRpt>

<GrpHdr>

<MsgId>20131101-090903211-1701-13682/10868</MsgId>

<CreDtTm>2013-11-22T13:22:12</CreDtTm>

<InitgPty>

<Id>

<OrgId>


</OrgId>

</Id>

</InitgPty>

</GrpHdr>

<OrgnlGrpInfAndSts>

<OrgnlMsgId>201111251</OrgnlMsgId>

<OrgnlMsgNmId>pain.001.001.03</OrgnlMsgNmId>

<OrgnlNbOfTxs>1</OrgnlNbOfTxs>

<OrgnlCtrlSum>1.5</OrgnlCtrlSum>

<GrpSts>RJCT</GrpSts>

</OrgnlGrpInfAndSts>

<OrgnlPmtInfAndSts>

<OrgnlPmtInfId>PMTID109</OrgnlPmtInfId>

<PmtInfSts>RJCT</PmtInfSts>

<StsRsnInf>

<Rsn>

<Cd>BE01</Cd>

</Rsn>

<AddtlInf>The account number and the name do not coincide!</AddtlInf>

</StsRsnInf>

<TxInfAndSts>

<OrgnlInstrId>1150006</OrgnlInstrId>

<OrgnlEndToEndId>528</OrgnlEndToEndId>

<TxSts>RJCT</TxSts>

<StsRsnInf>

<Orgtr>

<Id>

<OrgId>


</OrgId>

</Id>

</Orgtr>

<Rsn>

<Cd>BE01</Cd>

</Rsn>

<AddtlInf>The account number and the name do not coincide!</AddtlInf>

</StsRsnInf>

<OrgnlTxRef>

<Amt>


</Amt>


<Dbtr>


</Dbtr>

<DbtrAcct>

<Id>

<IBAN>EE942200221017496868</IBAN>

</Id>

</DbtrAcct>

<DbtrAgt>

<FinInstnId>

<BIC>HABAEE2X</BIC>

</FinInstnId>

</DbtrAgt>

<Cdtr>

<Nm>WRONGNAME AS</Nm></Cdtr><CdtrAcct> <Id> <IBAN>EE572200221017496855</IBAN></Id></CdtrAcct></OrgnlTxRef></TxInfAndSts></OrgnlPmtInfAndSts></CstmrPmtStsRpt></Document>

ISO 20022 Message Implementation Guide for Payment Initiation

Documents

Transcript of ISO 20022 Message Implementation Guide for Payment Initiation