ISO 20022 XML pain.001 implementation guide in Handelsbanken Estonia, Latvia, Lithuania



Similar documents
Format Description XML SEPA CT

Format description XML SEPA Credit Transfer

Format description XML SEPA Credit Transfer

Format Description XML SEPA DD

XML Message for SEPA Direct Debit Initiation

Format description SEPA DD ISO20022 (for Euro Direct Debits)

Format description SEPA Direct Debit (for Euro Direct Debits) Rabo Cash Management

ISO Message Implementation Guide for Payment Initiation

SEPA Direct Debit PAIN XML File Structure

SEPA Direct Debit Initiation Danske Bank's interpretation of ISO pain (Direct Debit Initiation)

Format description pain.002, technical. Rabo Cash Management, Rabo Direct Connect & Rabo Internetbankieren (Pro)

Corporate Payments Service

Danske Bank Message Implementation Guide Common Global Implementation (CGI) Customer Credit Transfer pain

Format description XML SEPA Credit Transfer. Format Description

ISO PAYMENT GUIDE. Messages: Pain Pain

ISO Message Implementation Guide for Cash Management Reports

XML message for SEPA Credit Transfer Initiation Implementation Guidelines for the Netherlands

Impact of SEPA on CODA2.3 for SEPA credit transfer (SCT) version April ing.be/sepa

XML message for Payment Initiation Implementation Guideline. Version 1.02

XML message for SEPA Direct Debit Initiation Implementation Guidelines for the Netherlands

OUTGOING PAYMENTS ISO APPLICATION GUIDELINE

OUTGOING PAYMENTS ISO APPLICATION GUIDELINE

Danske Bank Guideline to payments in ISO XML format (pain )

Payment Status Report

XML message for SEPA Direct Debit Initiation Implementation Guidelines for the Netherlands

Appendix for BSK Implementerings Guides ISO 20022

Formats for Internet Bank

SEPA Credit Transfer. C2B Technical Specification Pain

SEPA Direct Debit Cancellation Danske Bank's interpretation of ISO camt (Payment Cancellation Request)

Danish Implementation Guideline for Common Global Implementation (CGI) Customer Payment Status Report

SEPA CORE DIRECT DEBIT SCHEME CUSTOMER-TO-BANK IMPLEMENTATION GUIDELINES

SEPA CREDIT TRANSFER SCHEME INTER-BANK IMPLEMENTATION GUIDELINES

Record description XML File Transfer ISO XML pain

SEPA CREDIT TRANSFER SCHEME INTER-BANK IMPLEMENTATION GUIDELINES

Record description XML File Transfer Balance and Transaction list camt

SEPA payment transactions. Formats

OP's C2B SERVICES Pain 03. Payment Transfer Products

SEPA Credit Transfer Customer-to-Bank Implementation Guidelines for the Netherlands

Nordea Account structure. Corporate egateway

Format Description. SWIFT MT103 Single Customer Credit Transfer

Deutsche Bank Global Transaction Banking. Internet Bankieren. Entering Payments and Collections.

How To Create A Credit Card From A Creditcard In A Microsoft Web Server On A Microsql Web Server

en (pf.ch/dok.pf) PF. EPO manual Electronic payment order via file transfer

SEPA CORE DIRECT DEBIT SCHEME INTER-BANK IMPLEMENTATION GUIDELINES

SEPA Direct Debit Initiation Customer-to-Bank Implementation Guidelines for the Netherlands

Nordea Bank AB Lithuania branch Price List for corporate customers Valid from 1 st of September, Contents

SEPA. Changes in the Payment System Implementation of the European SEPA Regulations for Kuna and Euro Payments

RECOMMENDATION ON CUSTOMER REPORTING OF SEPA CREDIT TRANSFERS AND SEPA DIRECT DEBITS

XML ACCOUNT STATEMENT. Service Description

Functional specification for Payments Corporate egateway

Danske Bank Message Implementation Guide Common Global Implementation (CGI) Customer Credit Transfer pain

Date: 8 January 2009 (Message Versions: pain , pain , pain , pain and pain )

Spanish legacy branch code 4 numbers. Spanish legacy bank code 4 numbers

ISO ACCOUNT STATEMENT GUIDE. v 1.3

SEPA DIRECT DEBIT SCHEME IMPLEMENTATION GUIDELINES

Oracle FLEXCUBE Direct Banking Release Retail Transfer and Payments User Manual. Part No. E

Corporate Payments Service. Payments from Latvia, Lithuania and Estonia, example appendix pain

SEPA formats - an introduction to XML. version September

Guide. 1 Dec Introduction of the global Structured Creditor Reference in Finnish companies. 1 December 2010

TARIFF & CUT-OFF TIMES - IRELAND

Standards MX Message Implementation Guide and Rule Book

Payments Standards - Clearing and Settlement

Occasions leading to mandate amendments

SEPA Customer File Formats-Definition Proposals

SEPA Direct Debit Acknowledgement Danske Bank's interpretation of ISO pain (Payment Status Report)

PAIN.002. Format description Functional

Service description. Corporate Access Payables

SEPA Reason Codes. Direct Debit Customer to Bank Implementation Guidelines

SEPA CBI XML generator Documentation

SEPA - Frequently Asked Questions

SEPA Direct Debit Unpaid Report File Format

SEPA Country-Specific Information Austria

Implementation of ISO 20022: starter kit for software partners

Intra-day payment Frequently asked questions

Format Description SWIFT MT940 Structured

Swedish Common Interpretation of ISO Payment Messages. Appendix 1: Common Payment Types in Sweden

DESCRIPTION OF SEPA XML FORMAT FOR ING BUSINESSONLINE IMPORT AND EXPORT TEMPLATES

AX 2012 R3 SEPA (ISO XML) Credit transfer and direct debit payments Date: March 3 rd, 2015

SEPA Payment Status Report ISO Technical Specification

Swedbank Business Internet Banking User Manual

Entering payment order abroad and payment order in a foreign currency in the Czech Republic via electronic banking service ČSOB InternetBanking 24

Frequently Asked Questions

Online Banking Record Descriptions

Implementing SEPA in Belgiu m

Format Description MT940. Rabo Cash Management

BEST client format supported by KB (valid from 28th November 2015)

More information on completing payment details

Electronic foreign currency payments, LUM2

XML PAYMENT LIST. Service description. February February Copyright OY SAMLINK AB

Credit transfer to Customer account with AS "Meridian Trade Bank" EUR, USD free of charge * Other countries currency information in the Bank

Terms and Conditions for Banks Bank Handlowy w Warszawie S.A. SWIFT code CITIPLPX

Single Euro Payments Area

Format Validation Tool ING Commercial Banking

SEPA Direct Debit Implementation Guide. Version 1.7

ICEPAY & SEPA Direct Debit

State Bank of Pakistan. Guidelines: IBAN Implementation in Pakistan

SEPA. Frequently Asked Questions

USER MANUAL FOR INTERNET BANKING (IB) SERVICE

Creating international money transfers

SEPA Country Guide Italy. Introduction

Transcription:

ISO 20022 XML pain.001 implementation guide in Handelsbanken Estonia, Latvia, Lithuania Version: 1.0 Date: 12.10.2015 1

1 Introduction This document describes the Implementation Guide for CustomerCreditTransferInitiation ISO 20022 pain.001.001.03 in Handelsbanken. The purpose of this Implementation Guide is to provide guidance for how information is structured in the exchange between the customer and Handelsbanken. Payment file can be imported and sent to the bank via SHB Net bank. Handelsbanken s message set-up complies with the international definitions for content and use of an ISO 20022 CustomerCreditTransferInitiation Message and Common Global Implementation (CGI). Related documents: The documents below contain information to facilitate the implementation to execute payments in the ISO 20022 CustomerCreditTransferInitiation (pain.001) format: - The ISO 20022 Message Definition Report (MDR), Message Usage Guideline (MUG) and XML schema pain.001.001.03.xsd can be downloaded from: http://www.iso20022.org/message_archive.page#paymentsinitiation3 - The Payments External Code List, which provides the standard values for payment message code elements, www.iso20022.org/external_code_list.page Payment types One message consists of one or several payment instruction(s) and is used for singular and consolidated payments import. There can be one or several different type of payments in the same message. The following payment types are supported: Domestic SEPA payment in EUR (Beneficiary IBAN in the same country); Intra-bank payment in any currency (Beneficiary IBAN in the same SHB branch); Cross-border SEPA payment in EUR (Beneficiary IBAN in another country); Cross-border non-sepa payments (payments in other currencies or payments in EUR to non-sepa countries); Consolidated (consolidated) payments defined with value SALA in tag CategoryPurpose. Consolidated payment can only be SEPA payment (crossborder, domestic or intra-bank). 2

Restrictions Payments with invalid data are rejected during file import, they are not imported. When the number of invalid payments exceeds the maximum number of invalid payments allowed per import file then import is aborted: In Estonia and Lithuania: max 5 invalid payments are allowed per import file In Latvia: not limited The maximum size of the import file is limited. When the import file size exceeds the maximum allowed size limit then import is aborted. Validation object Validation scenario Error message/notification Import file The import file is selected, but it does not match the allowed file format(s). Unknown input file format Invalid payments count The maximum number of invalid payments (allowed by NB configuration) is exceeded. Count of defective payment orders in file exceeds allowed limit Import file The size of the import file exceeds the maximum allowed import file size configured in SHB. The file is too large and cannot be imported. element 1.6 NumberOfTransaction There is mismatch in actual number of payment orders compared to element 1.6 Payments count in file NumberOfTransaction. The maximum number of payments within one import file (allowed by configuration) is exceeded. Mismatch in number of transactions. Import file contains too many payment orders. element 1.7 ControlSum There is mismatch in actual sum of payment orders amounts compared to element 1.7 ControlSum. Mismatch in control sum of transactions. In case import of one or more payment order failed and at least one payment order successfully passed the requirements validations then Net Bank displays Import payments result form with the following information: Error message(s) for the invalid payments and following summary results: Number of imported payment orders Number of not imported payment orders Sum of payments <CCY> Note: The Sum of payments is shown separately for every payment currency. The following action buttons are enabled on the form: [Save], [Send], [Delete]. 3

2 Customer Credit Transfer Initiation message pain.001.001.03 The UTF8 character encoding standard is used in message: a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9 / -? : ( )., + Additionally: In Estonia, the Estonian specific characters (Õ, Ä, Ö, Ü, Ž, Š, õ, ä, ö, ü, ž, š) are allowed. In Latvia, the Latvian specific characters (Ā, Ē, Ī, Ū, Ķ, Ļ, Ņ, Ŗ, Ģ, Š, Č, Ž, ā, ē, ī, ū, ō, ķ, ļ, ņ, ŗ, ģ, š, č, ž) are allowed. In Lithuania, the Lithuanian specific characters (ą, Ą, č, Č, ę, Ę, ė, Ė, į, Į, š, Š, ų, Ų, ū, Ū, ž, Ž) are allowed Note: The transliteration of Estonian, Latvian and Lithuanian characters to Latin characters shall be done for SEPA cross-border and Other cross-border payments when outgoing payments are sent out. The table below contains the definitions of the NB pain.001.001.03 message elements and the SHB usage rules. Explanations of the columns: 1) Index column - indicates the message element index number in the ISO 20022 XML Message Definition Report. This report can be found at www.iso20022.org under Catalogue of ISO 20022 messages with pain.001.001.03 as reference. 2) Mult. column - indicates whether an element is mandatory or optional and how many repetitions are allowed for the element. For example: [1..1] - element is mandatory and can be presented only once [1..n] - element is mandatory and can be presented 1 to n times [0..1] - element is optional and can be presented only once [0..n] - element is optional and can be presented 0 to n times {Or Or} - only one of several elements may be presented 3) Message Element column - element name used in ISO 20022 XML Message Definition Report. When an element contains sub-elements these are indented to the right and noted with a plus sign (+) per level. 4) XML tag column - specifies a respective element in NB pain.001 message. 5) Rules column - specifies the rules for the message/payment validation and payment order creation. If element is mandatory, conditional or optional and it is validated/processed by the Bank then there is a rule to describe it. When the rule is blank then content of the message element is ignored. When rule is shadowed then it is not allowed to contain any data in message element. 4

[1..1] +Message Root <CstmrCdtTrfInitn> Index Mult. Message Element XML Tag Rules 1.0 [1..1] +GroupHeader <GrpHdr> Set of characteristics common to all individual transactions included in the file. 1.1 [1..1] ++MessageIdentification <MsgId> Mandatory. Message ID is used to specify the File ID. Max length 35 characters. 1.2 [1..1] ++CreationDateTime <CreDtTm> Recommended to be unique for the customer; otherwise the notification message is shown. 1.6 [1..1] ++NumberOfTransaction <NbOfTxs> Mandatory. Number of payments in the message is used to verify the completeness of the file. Must match the actual number of the payments in the message that is counted during import; otherwise the message is rejected. 1.7 [0..1] ++ControlSum <CtrlSum> Optional. Sum of payments in the message is used to verify the completeness of the file. 1.8 [1..1] ++InitiatingParty <InitgPty> In case element is present in the file, then value must match the sum of the payments in the message that is counted during import; otherwise the message is rejected. Note: The payment amounts are summed altogether irrespective of the payment currency. [0..1] +++Name <Nm> Accepted but ignored. [0..1] +++Identification <Id> {Or ++++OrganisationIdentification <OrgId> {{Or +++++BICorBEI <BICOrBEI> Or}} +++++Other <Othr> [1..1] ++++++Identification <Id> [0..1] ++++++SchemeName <SchmeNm> {Or [1..1] +++++++Code <Cd> [1..1] Or} +++++++Proprietary <Prtry> Or} ++++PrivateIdentification <PrvtId> {Or +++++DateAndPlaceOfBirth <DtAndPlcOfBirth> [1..1] ++++++BirthDate <BirthDt> [1..1] ++++++CityOfBirth <CityOfBirth> [1..1] ++++++CountryOfBirth <CtryOfBirth> Or} +++++Other <Othr> 5

[1..1] ++++++Identification <Id> [0..1] ++++++SchemeName <SchmeNm> {Or [1..1] +++++++Code <Cd> [1..1] +++++++Proprietary <Prtry> Or} Index Mult. Message Element XML Tag SHB usage rules 2.0 [1..n] +PaymentInformation <PmtInf> Set of debit account characteristics common to all individual transactions (CTTI) included in the PI. PI - Payment Information block, single or multiple occurrences per message. 2.1 [1..1] ++PaymentInformationIdentification <PmtInfId> Mandatory. Payment Information identification. Max length 35 characters. ID is displayed in notification/error message as reference to all payments in PI block. 2.2 [1..1] ++PaymentMethod <PmtMtd> Mandatory. Payment method must be TRF (i.e. credit transfers); otherwise all payments in this PI block are rejected. 2.3 [0..1] ++BatchBooking <BtchBookg> Content is not checked. Batch-booking done only for consolidated 151006114146583-1846 payments, see rules described in element 2.40. 2.4 [0..1] ++NumberofTransactions <NbOfTxs> 2.5 [0..1] ++ControlSum <CtrlSum> 2.6 [0..1] ++PaymentTypeInformation <PmtTpInf> 2.7 [0..1] +++InstructionPriority <InstrPrty> 2.8 [0..1] +++ServiceLevel <SvcLvl> 2.9 {Or ++++Code <Cd> Optional. Used to specify the Payment type in payment order. See rules described in element 2.38. [1..1] 2.10 [1...1] ++++Proprietary <Prtry> Ignored. Or} 2.11 [0..1] +++DomesticInstrument <LclInstrm> 2.12 {Or ++++Code <Cd> Ignored. [1..1] 2.13 [1..1] Or} ++++Proprietary <Prtry> Optional. Used to specify the Payment type in payment order. See rules described in element 2.38. 2.14 [0..1] +++CategoryPurpose <CtgyPurp> 2.15 [1..1] ++++Code <Cd> Optional. Used to specify the Credit transfer category purpose in payment order. See rules described in element 2.40. 2.17 [1..1] ++RequestedExecutionDate <ReqdExctnDt> Mandatory. Used to specify the requested value date date of payment order. The date can be max up to 30 days in the future; in case date exceeds max allowed future date then all 6

payments in this PI block are rejected The date can be max up to 14 days in the past ; in case date exceeds max allowed past date then all payments in this PI block are rejected. See also next requirement. The date must be banking day for the respective payment type considering weekends/ holidays and cut-off times. In case the requested payment date is not possible then date is changed to next possible value date and notification message is displayed. 2.19 [1..1] ++Debtor <Dbtr> Used to specify the Debtor name and/or Identification in payment order (mandatory). [1..1] +++Name <Nm> Mandatory but ignored. Debtor name is taken from SHB customer database. [0..1] +++PostalAddress <PstlAdr> [0..1] ++++Country <Ctry> Ignored. Debtor s address is taken from SHB customer database. [0..2] ++++AddressLine <AdrLine> Ignored. Debtor s address is taken from SHB customer database. [0..1] +++Identification <Id> Optional. {Or ++++OrganisationIdentification <OrgId> SEPA payments: Either element BICorBEI or one occurrence of element Other is allowed; otherwise all payments in this PI block are rejected. Other payments: In case element is present in the message then content is ignored. {{Or +++++BICorBEI <BICOrBEI> In case element is present in the message, then content must confirm BIC format; otherwise all payments in this PI block are rejected. Or}} +++++Other <Othr> [1..1] ++++++Identification <Id> Identification value [0..1] ++++++SchemeName <SchmeNm> {Or [1..1] +++++++Code <Cd> Identification type If present then must be one of the ISO type codes If not present but element Identification is present, then it will be provided as Other ID. [1..1] Or} ++++Proprietary <Prtry> Or} ++++PrivateIdentification <PrvtId> SEPA payments: Either element DateAndPlaceOfBirth or one occurrence of element Other is allowed; otherwise all payments in this PI block are rejected. Other payments: In case element is present in the message then content is ignored. {Or +++++DateAndPlaceOfBirth <DtAndPlcOfBirth> Accepted but ignored, taken from SHB customer database. [1..1] ++++++BirthDate <BirthDt> [1..1] ++++++CityOfBirth <CityOfBirth> 7

[1..1] ++++++CountryOfBirth <CtryOfBirth> Or} +++++Other <Othr> [1..1] ++++++Identification <Id> Identification value [0..1] ++++++SchemeName <SchmeNm> [1..1] +++++++Code <Cd> Identification type If present then must be one of the ISO type codes If not present but element Identification is present, then it will be provided as Other ID. 2.20 [1..1] ++DebtorAccount <DbtrAcct> Mandatory. Used to specify the Payer s Account no in payment order. [1..1] +++Identification <Id> [1..1] ++++IBAN <IBAN> Only IBAN belonging to debtor is allowed. Net bank user must have respective operating rights in account. Account must be open in SHB database; otherwise all payments in this PI block are rejected. [0..1] +++Currency <Ccy> Optional. Used to specify the Cover currency in payment order. In case element is present in the message then Payer s account (2.20 IBAN ) must have respective currency account, otherwise all payments in this PI block are rejected. In case element is not present in the message and Payer s account (2.20 IBAN ) is single-currency account, then Cover currency is by default Payer s account main currency in SHB. In case element is not present in the message and Payer s account (2.20 IBAN ) is multi-currency account, then Cover currency is by default same as payment currency in element 2.43 InstructedAmount. In case of consolidated payment if Cover currency is different from payment currency then consolidated payment is rejected. 2.21 [1..1] ++DebtorAgent <DbtrAgt> Mandatory but ignored. [1..1] +++FinancialInstitutionIdentification <FinInstnId> [1..1] ++++BIC <BIC> 2.23 [0..1] ++UltimateDebtor <UltmtDbtr> Optional. Used to specify the Ultimate debtor s name and/or Identification in payment order. [0..1] +++Name <Nm> See rules described in element 2.70 Name. [0..1] +++Identification <Id> See rules described in element 2.70 Identification and its sub-elements. 2.24 [0..1] ++ChargesBearer <ChrgBr> Optional. Used to specify the Bank fees are paid by in payment order. See rules described in element 2.51. 2.25 [0..1] ++ChargesAccount <ChrgsAcct> Accepted but ignored. Charges are always debited from account specified in element 2.20 IBAN. [1..1] +++Identification <Id> [1..1] ++++IBAN <IBAN> Index Mult. MessageElement XML Tag SHB usage rules 2.27 [1..n] ++CreditTransferTransactionInformat <CdtTrfTxInf> CTTI - Credit Transfer Transaction Information (single or multiple occurrences per one PI block). 8

ion 2.28 [1..1] +++PaymentIdentification <PmtId> 2.29 [0..1] ++++InstructionIdentification <InstrId> Optional, not delivered to the Beneficiary, returned in camt.053 to Debtor. Used to specify Doc No in payment order. In case the element is present then first 10 characters are used for Doc No (and the rest is ignored). In case the element is not present, then Doc No is assigned automatically by SHB as next sequential number. 2.30 [1..1] ++++EndToEndIdentification <EndToEndId> SEPA payments: Mandatory, delivered to the Beneficiary, returned in camt.053 to Debtor. Used to specify the Originator's reference no/e2e in payment order. Other payments: In case element is present in the message then content is ignored. Max length 35 characters. 2.31 [0..1] +++PaymentTypeInformation <PmtTpInf> 2.33 [0..1] ++++ServiceLevel <SvcLvl> 2.34 [1..1] +++++Code <Cd> Optional. Used to specify the Payment type in payment order. See rules described in element 2.38. 2.36 [0..1] ++++DomesticInstrument <LclInstrm> 2.37 {Or +++++Code <Cd> 2.38 Or} +++++Proprietary <Prtry> Optional. Used to specify the Payment type in payment order. The Payment type is defined based on the first matching element in the following order: 1) element 2.38 Proprietary if it s present or 2) element 2.13 Proprietary if it s present or 3) element 2.34 Code if it s present or 4) element 2.9 Code if it s present or 5) if abovementioned elements are not present in the message, then by default Payment type is Standard ( T ). In case of element Code is used for defining Payment type then the possible values are as follows: Code in message Payment type SDVA Express ( E ) URGP Urgent ( K ) NURG Standard ( T ) SEPA or any other value In case element Proprietary is used for defining Payment type then the possible values are as follows: Proprietary in message Payment type EXPR Express ( E ) 9

HIGH Urgent ( K ) NORM Standard ( T ) any other value 2.39 [0..1] ++++CategoryPurpose <CtgyPurp> SEPA payments 2.40 [1..1] +++++Code <Cd> Optional. Used to specify the Credit transfer category purpose AT-45 in payment order. The Credit transfer category purpose is defined based on the first matching element in the following order: 1) element 2.40 Code if it s present or 2) element 2.15 Code if it s present In case code is present it must be one of the allowed ISO values. In case element 2.40 Code is present and/or element 2.15 Code is present and value is SALA then payment is identified as Consolidated payment. In case element 2.40 Code is present and element 2.15 Code is present and values are different then element 2.40 value is considered as true and element 2.15 is ignored. NB! Code SALA is allowed only for SEPA payments and domestic payments. If present for other payment types then payment is rejected. 2.42 [1..1] +++Amount <Amt> 2.43 {Or ++++InstructedAmount <InstdAmt> Mandatory. Used to specify the Amount and currency in payment order. Amount must be more than zero; otherwise payment is rejected. Currency must be one of the accepted currencies in SHB; otherwise payment is rejected. 2.44 Or} ++++EquivalentAmount <EqvtAmt> 2.45 [1..1] +++++Amount <Amt> 2.46 [1..1] +++++CurrencyOfTransfer <CcyOfTrf> 2.51 [0..1] +++ChargeBearer <ChrgBr> Otional. Used to specify the Bank fees are paid by in payment order. The Bank fees are paid by is defined based on the first matching element in the following order: 1) element 2.51 ChargeBearer if it s present or 2) element 2.24 ChargeBearer if it s present or 3) if abovementioned elements are not present in the message, then by default Bank fees are paid by are Shared ( SHA ). The possible values are mapped in SHB as follows: Charge bearer in message Bank fees are paid by DEBT Payer ( OUR ) 10

SLEV Shared ( SHA ) SHAR CRED any other value 2.70 [0..1] +++UltimateDebtor <UltmtDbtr> SEPA payments: Used to specify the Ultimate debtor s name and/or Identification in payment order (optional). Other cases the content is ignored. [0..1] ++++Name <Nm> Max length 70 characters. The Ultimate debtor s name is defined based on the first matching element in the following order: 1) element 2.70 Name if it s present or 2) element 2.23 Name if it s present [0..1] ++++Identification <Id> The Ultimate debtor s ID is defined based on the first matching element in the following order: 1) element 2.70 Identification (and its sub-elements) if present or 2) element 2.23 Identification (and its sub-elements) if present {Or +++++OrganisationIdentification <OrgId> Either element BICorBEI or one occurrence of element Other is allowed; otherwise all payments in this PI block are rejected. {{Or ++++++BICorBEI <BICOrBEI> In case element is present in the message, then content must confirm BIC format; otherwise all payments in this PI block are rejected. Or}} ++++++Other <Othr> [1..1] +++++++Identification <Id> Identification value [0..1] +++++++SchemeName <SchmeNm> [1..1] ++++++++Code <Cd> Identification type code If present then must be one of the ISO type codes If not present but element Identification is present, then it will be provided as Other ID. Or} +++++PrivateIdentification <PrvtId> Either element DateAndPlaceOfBirth or one occurrence of element Other is allowed; otherwise all payments in this PI block are rejected. {Or ++++++DateAndPlaceOfBirth <DtAndPlcOfBirth> Note! The type of Ultimate debtor s ID in payment order is blank. The content of element is shown in payment order but not passed to beneficiary bank. [1..1] +++++++BirthDate <BirthDt> [1..1] +++++++CityOfBirth <CityOfBirth> [1..1] +++++++CountryOfBirth <CtryOfBirth> Or} ++++++Other <Othr> 11

[1..1] +++++++Identification <Id> Identification value [0..1] +++++++SchemeName <SchmeNm> [1..1] ++++++++Code <Cd> Identification type code 2.71 [0..1] +++IntermediaryAgent1 <IntrmyAgt1> [1..1] ++++FinancialInstitutionIdentification <FinInstnId> [0..1] +++++BIC <BIC> [0..1] +++++ClearingSystemMember Identification <ClrSysMmbId> [0..1] ++++++ClearingSystemIdentification <ClrSysId> [1..1] +++++++Code <Cd> [1..1] ++++++MemberIdentification <MmbId> If present then must be one of the ISO type codes. If not present but element Identification is present, then it will be provided as Other ID. Optional. Used to specify the Correspondent Bank in payment order. Valid for cross border non-eu payments. In other cases the content is ignored. In case of Other cross-border payment: If present in the message, then must be correct; otherwise payment is rejected. [0..1] +++++Name <Nm> Optional. Used to specify the Correspondent Bank name in payment order. In other cases the content is ignored. [0..1] +++++PostalAddress <PstlAdr> In case of Other cross-border payment: In case element is present in the message, then also element 2.71 AddressLine must be present; otherwise payment is rejected. In case element is not present in the message, then Correspondent Bank is filled in by bank. [0..1] ++++++Country <Ctry> See rules described in element 2.71 AddressLine. [0..2] ++++++AddressLine <AdrLine> Used to specify the Correspondent Bank s Address in payment order (optional). 2.72 [0..1] +++IntermediaryAgent1Account <IntrmyAgt1Acct> In case of Other cross-border payment: In case element is present in the message, then also element 2.71 Name must be present; otherwise payment is rejected. In other cases the content is ignored. [1..1] ++++Identification <Id> Optional. Used to specify the Correspondent Bank s Account no in cross-border payment order. In other cases: In case element is present in the message then content is ignored. 12

Or} +++++Other <Othr> [1..1] ++++++Identification <Id> Account number IBAN. Account number in other format than IBAN. 2.77 [0..1] +++CreditorAgent <CdtrAgt> Optional. Used to specify the Beneficiary Bank in payment order. [1..1] ++++FinancialInstitutionIdentification <FinInstnId> [0..1] +++++BIC <BIC> If BIC is present then must be correct; otherwise payment is rejected. [0..1] +++++ClearingSystemMember Identification <ClrSysMmbId> [0..1] ++++++ClearingSystemIdentification <ClrSysId> [1..1] +++++++Code <Cd> [1..1] ++++++MemberIdentification <MmbId> If BIC is not present then it will be derived from element 2.80 IBAN. If IBAN is not present then elements 2.77 Name and 2.77 AddressLine must be present; otherwise payment is rejected. In case of SEPA and domestic payments the BIC is always derived from element 2.80 IBAN. [0..1] +++++Name <Nm> Optional. Used to specify the Beneficiary Bank name in payment order. [0..1] +++++PostalAddress <PstlAdr> In case of SEPA and domestic payments the content is ignored. In case of Other cross-border payment: In case BIC (i.e. Beneficiary s bank Swift ) is not present then elements 2.77 Name and 2.77 AddressLine must be present; otherwise payment is rejected. [0..1] ++++++Country <Ctry> See rules described in element 2.77 AddressLine. [0..2] ++++++AddressLine <AdrLine> Optional. Used to specify the Beneficiary Bank s Address in payment order for. In case of SEPA and domestic payments the content is ignored. In case of Other cross-border payment: In case BIC (i.e. Beneficiary s bank Swift ) is not present, then elements 2.77 Name and 2.77 AddressLine must be present; otherwise payment is rejected. 2.78 [0..1] +++CreditorAgentAccount <CdtrAgtAcct> Used to specify the Correspondent Bank s Account no in payment order. [1..1] ++++Identification <Id> {Or +++++IBAN <IBAN> 13

Or} +++++Other <Othr> [1..1] ++++++Identification <Id> 2.79 [1..1] +++Creditor <Cdtr> Mandatory. Used to specify the Beneficiary s Name and/or Identification in payment order. [1..1] ++++Name <Nm> Mandatory; otherwise payment is rejected. Max length is 70 characters. In case of intra-bank payment the name must match in important extent to beneficiary s account holder name defined in SHB; otherwise payment is rejected. [0..1] ++++PostalAddress <PstlAdr> [0..1] +++++Country <Ctry> Optional. Used to specify Beneficiary s Country in payment order. [0..2] +++++AddressLine <AdrLine> Optional. Used to specify Beneficiary s Address in payment order. Max length is 140 characters. [0..1] ++++Identification <Id> {Or +++++OrganisationIdentification <OrgId> SEPA payments: Either element BICorBEI or one occurrence of element Other is allowed; otherwise all payments in this PI block are rejected. For other payments the content is ignored. {{Or ++++++BICOrBEI <BICOrBEI> Or}} ++++++Other <Othr> [1..1] +++++++Identification <Id> Identification value [0..1] +++++++SchemeName <SchmeNm> {{Or ++++++++Code <Cd> Identification type If present then must be one of the ISO type codes If not present but element Identification is present, then it will be provided as Other ID. Or}} ++++++++Proprietary Or} +++++PrivateIdentification <PrvtId> SEPA payments and domestic EUR payments: Either element DateAndPlaceOfBirth or one occurrence of element Other is allowed; otherwise all payments in this PI block are rejected. For Other payments the content is ignored. {Or ++++++DateAndPlaceOfBirth <DtAndPlcOfBirth> [1..1] +++++++BirthDate <BirthDt> [1..1] +++++++CityOfBirth <CityOfBirth> [1..1] +++++++CountryOfBirth <CtryOfBirth> Or} ++++++Other <Othr> 14

[1..1] +++++++Identification <Id> Identification value [0..1] +++++++SchemeName <SchmeNm> [1..1] ++++++++Code <Cd> Identification type If present then must be one of the ISO type codes If not present but element Identification is present, then it will be provided as Other ID. 2.80 [1..1] +++CreditorAccount <CdtrAcct> Used to specify the Beneficiary s Account no in payment order [1..1] ++++Identification <Id> Either element 2.80 Identification or element 2.80 IBAN must be present; otherwise payment is rejected {Or +++++IBAN <IBAN> Only IBAN is allowed. In case of SEPA domestic payment, SEPA cross-border payment: Mandatory; otherwise payment is rejected. In case of intra-bank payment: Mandatory and must exist in SHB; otherwise the payment is rejected. Or} +++++Other <Othr> Either element 2.80 Identification or element 2.80 IBAN must be present; otherwise payment is rejected [1..1] ++++++Identification <Id> Used to specify the Beneficiary s Account no other than IBAN 2.81 [0..1] +++UltimateCreditor <UltmtCdtr> SEPA payments and intra-bank EUR payments: Used to specify the Ultimate creditor s name and/or Identification in payment order (optional). Other cases the message then content is ignored. [0..1] ++++Name <Nm> Name, max length 70 characters. [0..1] ++++Identification <Id> {Or +++++OrganisationIdentification <OrgId> Either element BICorBEI or one occurrence of element Other is allowed; otherwise all payments in this PI block are rejected. {{Or ++++++BICorBEI <BICOrBEI> In case element is present in the message, then content must confirm BIC format; otherwise payment is rejected. Or}} ++++++Other <Othr> [1..1] +++++++Identification <Id> Identification value [0..1] +++++++SchemeName <SchmeNm> [1..1] ++++++++Code <Cd> Identification type code If present then must be one of the ISO type codes If not present but element Identification is present, then it will be provided as Other ID. Or} +++++PrivateIdentification <PrvtId> Either element DateAndPlaceOfBirth or one occurrence of element Other is allowed; otherwise all payments in this PI block are rejected. {Or ++++++DateAndPlaceOfBirth <DtAndPlcOfBirth> Note! The type of Ultimate creditor s ID in payment order is blank. The content of element is shown in payment 15

order but not passed to beneficiary bank. [1..1] +++++++BirthDate <BirthDt> [1..1] +++++++CityOfBirth <CityOfBirth> [1..1] +++++++CountryOfBirth <CtryOfBirth> Or} ++++++Other <Othr> [1..1] +++++++Identification <Id> Identification value [0..1] +++++++SchemeName <SchmeNm> [1..1] ++++++++Code <Cd> Identification type code If present then must be one of the ISO type codes. If not present but element Identification is present, then it will be provided as Other ID. 2.86 [0..1] +++Purpose <Purp> Optional. Used to specify Credit transfer purpose (AT44) in payment order. [1..1] ++++Code <Cd> SEPA payments only. For other payments content is ignored. 2.89 [0..10] +++RegulatoryReporting <RgltryRptg> [0..1] ++++Authority <Authrty> [0..1] +++++Country <Ctry> In Estonia, Lithuania: Ignored. In Latvia: In case element is present and content is LV then see element 2.89 Type ; otherwise ignored. [0..n] ++++Details <Dtls> [0..1] +++++Type <Tp> In Estonia, Lithuania: Ignored In Latvia: In case element is present and content is AMK and element 2.89 Authority Country is LV then see element Code. [0..1] +++++Country <Ctry> Ignored [0..1] +++++Code <Cd> Conditionally mandatory. Used to specify Payment balance code in payment order. Mandatory in case of payment between resident and non-resident when payment amount is above 10000 EUR; otherwise payment is rejected. [0..1] +++++Amount <Amt> [0..1] +++++Information <Inf> 2.98 [0..1] +++RemittanceInformation <RmtInf> Used to specify the Explanation or/and Reference number in payment order. In Estonia both Reference number and Explanation may be present at the same time. In Latvia and Lithuania either Reference number or Explanation may be present at the same time. 16

2.99 [0..1] ++++Unstructured <Ustrd> Optional, max length 140 characters. Specific in Estonia: Codes RFB and TXT are used to identify Reference and Explanation. 1) In case only Unstructured information is provided in the format /RFB/XXXXXX/TXT/ZZZZZZ, then XXXXXX is used to specify the Reference number and ZZZZZZ is used to specify the Explanation in payment order. See element 2.126 Reference for requirements for the reference number validation. 2) In case both element 2.99 Unstructured and 2.126 Reference are present in the message, then Explanation field in payment order is filled-in in format /RFB/XXXXXX/TXT/ZZZZZZ (where XXXXXX is content of element 2.126 Reference and ZZZZZZ is content of element 2.99 Unstructured ). E.g.: /RFB/FR123418/TXT/Invoice number AB/7-1 NB! In case the total number of characters in element 2.99 Unstructured + 2.126 Reference is more than 140 characters then the end of 2.99 Unstructured is ignored. 2.100 [0..1] ++++Structured <Strd> 2.120 [0..1] +++++CreditorReferenceInformation <CdtrRefInf> 2.121 [0..1] ++++++Type <Tp> 2.122 [1..1] +++++++CodeorProprietary <CdOrPrtry> 2.123 [1..1] ++++++++Code <Cd> Optional. The creditor reference type in a coded form. In case of SEPA payments: In case element is present in the message, then must be SCOR ; otherwise payment instruction is rejected. Code is forwarded to beneficiary bank within structured remittance information. In other cases the content is ignored. 2.125 [0..1] +++++++Issuer <Issr> Optional. The credit reference type. In case of SEPA payments: ISO in case of ISO11649 reference number. Value is forwarded to beneficiary bank in pacs.008 message within structured remittance information. In other cases the content is ignored. 2.126 [0..1] ++++++Reference <Ref> Used to specify the Reference number in cross-border and domestic SEPA payment order. Max length 35 characters. In case reference number starts with RF then reference number must comply with the RF Creditor reference ISO 11649 standard; otherwise the payment is rejected. Specific in Estonia: In case reference number does not start with RF then reference number must comply with EE reference 17

number standard; otherwise payment is rejected. Specific in Lithuania: The validation of Reference number is applied according to Beneficiary account IBAN. 3 Examples Example 1: OrganisationIdentification element with Other In pain.001 message: In payment order: <Id> <OrgId> <Othr> <Id>123456789</Id> <SchmeNm> <Cd>COID</Cd> </SchmeNm> </Othr> </OrgId> </Id> See Comment 1. Example 2: OrganisationIdentification element with Other In pain.001 message: In payment order: <Id> <OrgId> <Othr> <Id>123456789</Id> </Othr> </OrgId> </Id> See Comment 1. Example 3: PrivateIdentification element with element with Other 18

In pain.001 message: In payment order: <Id> <PrvtId> <Othr> <Id>12345678910</Id> <SchmeNm> <Cd>NIDN</Cd> </SchmeNm> </Othr> <PrvtId> </Id> Comment 3: If PrivateIdentification element is present for: 2.19 Debtor then the content is mapped into payment order field Originator s ID 2.23 UltimateDebtor -> Ultimate debtor s ID 2.79 Creditor -> Beneficiary code 2.81 UltimateCreditor - > Ultimate creditor s ID Example 4: Payment balance code XML message extract with example: <RgltryRptg> <Authrty> <Ctry>LV</Ctry> </Authrty> <Dtls> <Tp>AMK</Tp> <Cd>111</Cd> </Dtls> </RgltryRptg> 19