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

Transcription

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

2 1 Introduction This document describes the Implementation Guide for CustomerCreditTransferInitiation ISO pain 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 CustomerCreditTransferInitiation Message and Common Global Implementation (CGI). Related documents: The documents below contain information to facilitate the implementation to execute payments in the ISO CustomerCreditTransferInitiation (pain.001) format: - The ISO Message Definition Report (MDR), Message Usage Guideline (MUG) and XML schema pain xsd can be downloaded from: - The Payments External Code List, which provides the standard values for payment message code elements, 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

3 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

4 2 Customer Credit Transfer Initiation message pain 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 / -? : ( )., + 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 message elements and the SHB usage rules. Explanations of the columns: 1) Index column - indicates the message element index number in the ISO XML Message Definition Report. This report can be found at under Catalogue of ISO messages with pain 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 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

5 [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

6 [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 payments, see rules described in element [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 [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 [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 [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

7 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 [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

8 [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 [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 [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 [0..1] ++ChargesBearer <ChrgBr> Optional. Used to specify the Bank fees are paid by in payment order. See rules described in element [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

9 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 [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 [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 [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

10 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 [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 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

11 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

12 [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) [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

13 Or} +++++Other <Othr> [1..1] Identification <Id> Account number IBAN. Account number in other format than IBAN [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 [0..1] +++CreditorAgentAccount <CdtrAgtAcct> Used to specify the Correspondent Bank s Account no in payment order. [1..1] ++++Identification <Id> {Or +++++IBAN <IBAN> 13

14 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

15 [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 [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

16 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 [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 [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 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

17 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 Reference for requirements for the reference number validation. 2) In case both element 2.99 Unstructured and 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 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 Reference is more than 140 characters then the end of 2.99 Unstructured is ignored [0..1] ++++Structured <Strd> [0..1] +++++CreditorReferenceInformation <CdtrRefInf> [0..1] Type <Tp> [1..1] CodeorProprietary <CdOrPrtry> [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 [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 [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 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

18 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> </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> </Id> </Othr> </OrgId> </Id> See Comment 1. Example 3: PrivateIdentification element with element with Other 18

19 In pain.001 message: In payment order: <Id> <PrvtId> <Othr> <Id> </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