xml Sepa Ct In Kb - Mojebanka · XML SEPA CT client format in KB (Credit Transfer) Komerční banka, a. s., registered office: Praha 1, Na Příkopě 33, 969, Postcode 114 07, IČ

XML SEPA CT client format in KB (Credit Transfer)

Komerční banka, a. s., registered office:

Praha 1, Na Příkopě 33, 969, Postcode 114 07, IČ (Company ID): 45317054 REGISTERED IN THE COMPANIES REGISTER KEPT BY PRAGUE MUNICIPAL COURT, B SECTION, RECORD 1360

1/20

XML SEPA CT IN KB

(valid from 28th November 2015)




2/20

Content: 1. Scope ......................................................................................................................................................................... 3 2. Application .................................................................................................................................................................. 3 3. Message structure (items used by KB) ....................................................................................................................... 4

3.1 Group leader .......................................................................................................................................................... 5 3.2 N Payment information ........................................................................................................................................... 5

4. Rules according to ISO 20022 for selected tags used in KB ...................................................................................... 6 5. Details for address structure in KB ........................................................................................................................... 11 6. Details of structure of organization or private person identification in KB ................................................................. 12 7. Examples of identification definition for Payer and Beneficiary in XML and on DCS Mojebanka channel screens .. 14 8. Example of XML with two payments ......................................................................................................................... 15 9. Example of SEPA urgent payment version 03 .......................................................................................................... 19




3/20

1. Scope

Electronic transfer of KB client requests for sending cross-border payments in EUR within the SEPA. KB arranges debiting of the required account according to SEPA terms (scheme Rulebooks), and sending the payment to the defined bank and account including non-accounting data handed over to the partner. The XML format can be used for executing/initiating a SEPA payment to a SEPA Reachable Bank as well as to a SEPA Non-Reachable Bank (including EUR payments to KBSK). A note concerning the handing over to the counterpart of non-accounting information: If a EUR payment is used within the SEPA Area but the relevant bank is not a SEPA Reachable Bank, the only non-accounting information the beneficiary receives will be additional information (remittance information).

2. Application

Standard pain.001.001.02 (version 02) defines 3 types of modes (i.e. three options of constructing XML):

Single (single orders - each payment has its own Payment Information Block)

Group (multiple orders - a common Payment Information Block and several occurrences of payment blocks)

Mixed (both types within a single message) Standard pain.001.001.03 (version 03) and standard pain.001.001.04 (version 04) do not specify any mode any more and are implicitly considered as the Mixed mode. KB converts MIXED and GROUP modes to single payments.

A character set of all SEPA payments’ text fields is limited to valid characters of the SWIFT character set; the SWIFT character set – currently valid characters – must always be adhered to see Table of allowed characters available at http://www.mojebanka.cz/file/cs/povolene_znaky.pdf

http://www.mojebanka.cz/file/cs/povolene_znaky.pdf




4/20

3. Message structure (items used by KB)

Note: KB accepts SEPA payments according to ISO

standard namespace urn:iso:std:iso:20022:tech:xsd:pain.001.001.02“, tag <Grpg> or a preceding code „GRPD“ or „MIXD“, converted to „SNGL“ – SINGLE by KB.

standard namespace urn:iso:std:iso:20022:tech:xsd:pain.001.001.03, expected preceding code „MIXD“, converted to „SNGL“ – SINGLE by KB.

standard namespace urn:iso:std:iso:20022:tech:xsd:pain.001.001.04, expected preceding code „MIXD“, converted to „SNGL“ – SINGLE by KB.




5/20

This document contains tags, from which values are accepted for further processing in KB and are only valid for standard pain.001.001.02. There are minor differences in the element structure and names under the versions pain.001.001.03 and pain.001.001.04. It is therefore desirable to follow the following descriptions:

http://www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id=437 for pain.001.001.03,

http://www.europeanpaymentscouncil.eu/ for pain.001.001.04 XML without namespace or with different namespace will be considered as an invalid format. Tags of required (mandatory) fields are put in grey background in the tables below

3.1 Group leader

Index OR Message item <XML Tag> Mult. Presentation Used in KB

1.0 Group Header <GrpHdr> [1..1]

1.1 Message Identification <MsgId> [1..1] Text

1.2 Creation Date Time <CreDtTm> [1..1] DateTime Used for duplication detection.

1.5 Number Of Transactions <NbOfTxs> [1..1] Text Validations only with notification

1.6 Control Sum <CtrlSum> [0..1] Quantity Validations only with notification

1.7 Grouping <Grpg> [1..1] Code SNGL, GRPD or MIXD required for pain.001.001.02 v02, this tag is not applicable for any other pain standards

1.8 Initiating Party <InitgPty> [1..1] +- Not taken over in KB

3.2 N Payment information


2.0 Payment Information <PmtInf> [1..n]

2.2 Payment Method <PmtMtd> [1..1] Code „TRF“

2.13 Requested Execution Date <ReqdExctnDt> [1..1] Date Debit due date

2.15 Debtor <Dbtr> [1..1] + Name, address, identification. KB takes over only identification; it does not take over the name and address, but uses it according to its own administration.

2.16 Debtor Account <DbtrAcct> [1..1] + IBAN (currency need not be specified; if it is specified, it must correspond to administration, otherwise it will be rejected).

2.17 Debtor Agent <DbtrAgt> [1..1] + Not taken over and validated by KB; KB checks the bank using IBAN.

2.19 Ultimate Debtor <UltmtDbtr> [0..1] + Will be transferred by KB when Rulebook 3.2. is officially approved; clients will be informed on KB website.

2.20 Charge Bearer <ChrgBr> [0..1] Code If not specified, KB will use SLEV; if to be specified, only SLEV can be used.

2.21 Charges Account <ChrgsAcct> [0..1] + To be specified only if you require different KB account to be charge (currency need not be specified; if to be specified, it must correspond to administration, otherwise it will be rejected).

2.23 Credit Transfer Transaction Information

<CdtTrfTxInf> [1..n]

2.24 Payment Identification <PmtId> [1..1]

2.25 Instruction Identification <InstrId> [0..1] Text Unique identification for KB (duplicate detection); if not specified, information of the

http://www.europeanpaymentscouncil.eu/knowledge_bank_detail.cfm?documents_id=437

http://www.europeanpaymentscouncil.eu/




6/20

EndToEnd field will be used.

2.26 End To End Identification <EndToEndId> [1..1] Text Handed over to the partner; if InstrId is not specified, this value is used for KB purpose: InstrId = End To End Id.

2.27 Payment Type Information <PmtTpInf> [0..1]

2.28 Instruction Priority <InstrPrty> [0..1] Code If it is stated "HIGH" = urgent payment. If it is stated "NORM" or is blank = express payment.

2.29 Service Level <SvcLvl> [0..1]

2.30 Code <Cd> [1..1] Code All transferred via XML will be “SEPA” only in KB. Specification is not necessary; if different value is used, it will be rejected.

2.36 Category Purpose [0..1] Code For the version pain.001.001.02 (only in this level and only as Code)

2.37 Amount <Amt> [1..1]

2.38 Instructed Amount <InstdAmt> [1..1] Amount Amount in EUR Currencies other than EUR will be rejected in KB.

2.46 Charge Bearer <ChrgBr> [0..1] Code Only “SLEV” can be used for SEPA payments. Not compulsory; KB uses it by default.

2.55 Creditor Agent <CdtrAgt> [0..1] + BIC - the bank must be SEPA-compliant.

2.57 Creditor <Cdtr> [0..1] + Name, address - required; identification (optional)

2.58 Creditor Account <CdtrAcct> [1..1] + IBAN

2.59 Ultimate Creditor <UltmtCdtr> [0..1] + Will be transferred by KB when Rulebook 3.2. is officially approved; clients will be informed on KB website.

2.64 Purpose <Purp> [0..1] See the Chapter 2.64 Purpose <Purp>

2.84 Remittance Information <RmtInf> [0..1]

2.85 Unstructured <Ustrd> [0..n] Text Details of payment

4. Rules according to ISO 20022 for selected tags used in KB

FOR Header: 1.1 Message Identification <MsgId> Presence: [1..1] Definition: Point to point reference assigned by the instructing party and sent to the next party in the chain to unambiguously identify the message. Usage: The instructing party has to make sure that 'MessageIdentification' is unique per instructed party for a pre-agreed period. Data Type: Max 35 Text Format: max Length: 35 minLength: 1 1.2 Creation Date Time <CreDtTm> Presence: [1..1] Definition: Date and time at which a (group of) payment instruction(s) was created by the instructing party. Data Type: ISO Date Time 1.5 Number Of Transactions <NbOfTxs> Presence: [1..1] Definition: Number of individual transactions contained in the message. Data Type: Max 15 Numeric Text Format: [0-9]{1,15}




7/20

1.6 ControlSum <CtrlSum> Presence: [0..1] Definition: Total of all individual amounts included in the message, irrespective of currencies. Data Type: Decimal Number Format: fraction Digits: 17 totalDigits: 18 1.7 Grouping <Grpg> Presence: [1..1] Definition: Indicates whether common accounting information in the transaction is included once for all transactions or repeated for each single transaction. In KB only one possibility: single – „SNGL“ 1.8 Initiating Party <InitgPty> Presence: [1..1] Definition: Party initiating the payment. In the payment context, this can either be the debtor (in a credit transfer), the creditor (in a direct debit), or the party that initiates the payment on behalf of the debtor or creditor. Type: This message item is composed of the following Party Identification 8 element(s):

Or Message Item <XML Tag> Mult. Represent./Type

Name <Nm> [0..1] Text

Postal Address <PstlAdr> [0..1] Not taken over or validated in KB. The address administered in DB DCS is used. If to be sent, see the structure description in chapter 4 - Address in KB.

FOR Payments 2.0 Payment Information <PmtInf> Presence: [1..n] Definition: Set of characteristics that applies to the debit side of the payment transactions included in the credit transfer initiation. Type: The Payment Information block is composed of the following Payment Instruction Information 1 element(s):


2.1 Payment Information Identification <PmtInfId> [0..1] Text

2.2 Payment Method <PmtMtd> [1..1] Code TRF


2.13 Requested Execution Date <ReqdExctnDt> [1..1] DateTime DATE

2.15 Debtor <Dbtr> [1..1] + Address and name is not taken over, only identification is, if specified.

2.16 Debtor Account <DbtrAcct> [1..1] + IBAN currency need not be specified. If specified, it will be validated against the status in DB.

2.17 Debtor Agent <DbtrAgt> [1..1] + Not taken over and validated. The bank will be validated via IBAN.

2.19 Ultimate Debtor <UltmtDbtr> [0..1] + Currently not transferred by KB.

2.20 Charge Bearer <ChrgBr> [0..1] Code KB will use SLEV; however, if you specify a value, which is different from SLEV, it will be rejected.

2.21 Charges Account <ChrgsAcct> [0..1] + The account number is to be specified only if it is different from the account number for the actual payment (always only in KB).

2.23 Credit Transfer Transaction Information <CdtTrfTxInf> [1..n] Creditor description block




8/20

2.2 Payment Method <PmtMtd> Presence: [1..1] Definition: Specifies the means of payment that will be used to move the amount of money. Data Type: Code – „TRF“ 2.13 Requested Execution Date <ReqdExctnDt> Presence: [1..1] Definition: Date at which the initiating party requests the clearing agent to process the payment. If payment by cheque, the date when the cheque must be generated by the bank. Usage: This is the date on which the debtor's account(s) is (are) to be debited. Data Type: ISO Date 2.15 Debtor <Dbtr> Presence: [1..1] Definition: Party that owes an amount of money to the (ultimate) creditor. Type: This message item is composed of the following Party Identification 8 element(s):



Postal Address <PstlAdr> [0..1] Chapter 5

Identification <Id> [0..1] Chapter 6

Country Of Residence <CtryOfRes> [0..1] Code

2.16 Debtor Account <DbtrAcct> Presence: [1..1] Definition: Unambiguous identification of the account of the debtor to which a debit entry will be made as a result of the transaction. Type: This message item is composed of the following Cash Account 7 element(s):


Identification <Id> [1..1] <IBAN>

Currency <Ccy> [0..1] Code

2.17 Debtor Agent <DbtrAgt> Presence: [1..1] Definition: Financial institution servicing an account for the debtor. Type: This message item is composed of the following Branch And Financial Institution Identification3 element(s):


Financial Institution Identification <FinInstnId> [1..1] <BIC> not validated by KB

2.19 Ultimate Debtor <UltmtDbtr> Presence: [0..1] Definition: Ultimate party that owes an amount of money to the (ultimate) creditor. Type: This message item is composed of the following Party Identification 8 element(s):






2.20 Charge Bearer <ChrgBr> Presence: [0..1] Definition: Specifies which party/parties will bear the charges associated with the processing of the payment transaction. Data Type: Code When this message item is present, one of the following Charge Bearer Type 1 Code values must be used: Code Name Definition (for KB SEPA is acceptable only SLEV) CRED Borne By Creditor All transaction charges are to be borne by the creditor. DEBT Borne By Debtor All transaction charges are to be borne by the debtor.




9/20

SHAR Shared In a credit transfer context, means that transaction charges on the sender side are to be borne by the debtor, transaction charges on the receiver side are to be borne by the creditor. In a direct debit context, means that transaction charges on the sender side are to be borne by the creditor, transaction charges on the receiver side are to be borne by the debtor. SLEV Following Service Level Charges are to be applied following the rules agreed in the service level and/or scheme. 2.21 Charges Account <ChrgsAcct> Presence: [0..1] Definition: Account used to process charges associated with a transaction. Usage: charges account should be used when charges have to be booked to an account different from the account identified in debtor's account. Type: This message item is composed of the following Cash Account 7 element(s):


Identification <Id> [1..1] <IBAN>

Currency <Ccy> [0..1] Code

2.23 CreditTransferTransactionInformation <CdtTrfTxInf> Presence: [1..n] Definition: Set of elements providing information specific to the individual transaction(s) included in the message. Type: This message item is composed of the following Credit Transfer Transaction Information 1 element(s):


2.24 Payment Identification <PmtId> [1..1]


2.37 Amount <Amt> [1..1]

2.55 Creditor Agent <CdtrAgt> [0..1] +

2.57 Creditor <Cdtr> [0..1] +

2.58 Creditor Account <CdtrAcct> [0..1] +

2.59 Ultimate Creditor <UltmtCdtr> [0..1] +

2.84 Remittance Information <RmtInf> [0..1]

2.36 Category Purpose <CtgyPurp> Presence: [1..n] Definition: Category Purpose standardised code – optional field. Type: More information about the ISO codes can be found at www.ISO20022.org.


2.36 Purpose <Purp> [0..1]

{Or Code <Cd> [1..1] Code by ISO ISO Code for pain.001.001.03 and pain.001.001.04

Or} Proprietary <Prtry> [1..1] Text Purpose for pain.001.001.03 and pain.001.001.04

2.37 Amount <Amt> Presence: [1..1] Definition: Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in the currency as ordered by the initiating party. Type: This message item is composed of one of the following Amount Type 2 Choice element(s):


2.38 Instructed Amount <InstdAmt> [1..1] Amount Only EUR permitted in KB

2.38 Instructed Amount <InstdAmt> Presence: [1..1] This message item is part of choice 2.37 Amount. Definition: Amount of money to be moved between the debtor and creditor, before deduction of charges, expressed in The currency as ordered by the initiating party. Data Type: CurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by Currency Code. Format: Currency And Amount Fraction Digits: 5 Min Inclusive: 0 Total Digits: 18 Currency Code

http://www.iso20022.org/




10/20

[A-Z]{3,3} Rule(s): Currency Code Validation By Table 2.55 Creditor Agent <CdtrAgt> Presence: [0..1] Definition: Financial institution servicing an account for the creditor. Type: This message item is composed of the following Branch And Financial Institution Identification 3 element(s):


Financial Institution Identification <FinInstnId> [1..1] <BIC> - the bank can be, but does not have to be SEPA-complying. A format can be either 8 or 11 character. If the BIC consists of 8 valid characters, 3 blank spaces should be added to the right.

2.57 Creditor <Cdtr> Presence: [0..1] Definition: Party to which an amount of money is due. Type: This message item is composed of the following Party Identification 8 element(s):






2.58 Creditor Account <CdtrAcct> Presence: [0..1] Definition: Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result of the payment transaction. Type: This message item is composed of the following Cash Account 7 element(s):


Identification <Id> [1..1]

2.59 Ultimate Creditor <UltmtCdtr> Presence: [0..1] Definition: Ultimate party to which an amount of money is due. Type: This message item is composed of the following Party Identification 8 element(s):






2.64 Purpose <Purp> Presence: [0..1] Definition: Purpose of Payment standardised code – optional field. Type: More information about the ISO codes can be found at www.ISO20022.org.


2.64 Purpose <Purp> [0..1]

2.65 {Or Code <Cd> [1..1] Code by ISO ISO Code

2.66 Or} Proprietary <Prtry> [1..1] Text Purpose of Payment

In case of the Purpose <Purp> tag, both embedded tags can be used, i.e. Proprietary <Prtry> and Code <Cd>. However, only one of them can be filled in an instruction, NOT both at the same time. When submitting an instruction, the client can choose whether the purpose of the payment, as specified by the client, will be inserted into the <Prtry> tag or <Cd> tag. Proprietary is an arbitrary text consisting of 35 characters of a standard character set (SWIFT) at a maximum. Purpose Code: The code should be in line with the ISO external code list (e.g. “COLL” or “AREN”). The field is validated against the code list in case of pain.001.001.02, as the ISO code list is part of the XSD definition. The validation against the ISO code list is not

http://www.iso20022.org/




11/20

performed under the most recent versions. The client will be liable for possible faults (e.g. if an instruction is rejected by the debtor’s bank because the Code is inconsistent with a ISO code list).

2.84 Remittance Information <RmtInf> Presence: [0..1] Definition: Information that enables the matching, ie, reconciliation, of a payment with the items that the payment is intended to settle, eg, commercial invoices in an account receivable system. Type: This message item is composed of the following Remittance Information 1 element(s):


2.85 Unstructured <Ustrd> [0..n] Text Only non-structured information used.

2.85 Unstructured <Ustrd> Presence: [0..n] Definition: Information supplied to enable the matching of an entry with the items that the transfer is intended to settle, eg, commercial invoices in an accounts' receivable system in an unstructured form. Data Type: Max140Text Format: max Length: 140 minLength:

5. Details for address structure in KB

In KB, the structured approach will be required for the structure of the address, as well as using of appropriate tags for name, town, street, number, postcode and country. Address validation will be applied according to effective rules for foreign payments transferred via DCS (same as for BEST and EDI_BEST formats). 5.1.1 Postal Address <PstlAdr> Presence: [0..1] Definition: Information that locates and identifies a specific address, as defined by postal services. Type: This message item is composed of the following PostalAddress1 element(s):


5.1.4 Street Name <StrtNm> [0..1] Text

5.1.5 Building Number <BldgNb> [0..1] Text

5.1.6 Post Code <PstCd> [0..1] Text

5.1.7 Town Name <TwnNm> [0..1] Text

5.1.9 Country <Ctry> [1..1] Code

5.1.4 Street Name <StrtNm> Presence: [0..1] UNIFI (ISO 20022) - Payments Standards - Initiation October 2006 Message Item Types Page 343 Definition: Name of a street or thoroughfare. Data Type: Max 70 Text Format: max Length: 70 Min Length: 1 5.1.5 Building Number <BldgNb> Presence: [0..1] Definition: Number that identifies the position of a building on a street. Data Type: Max 16 Text Format: max Length: 16 Min Length: 1 5.1.6 Post Code <PstCd> Presence: [0..1] Definition: Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting of mail.




12/20

Data Type: Max16Text Format: max Length: 16 Min Length: 1 5.1.7 Town Name <TwnNm> Presence: [0..1] Definition: Name of a built-up area, with defined boundaries, and a local government. Data Type: Max35Text Format: max Length: 35 Min Length: 1 5.1.9 Country <Ctry> Presence: [1..1] Definition: Nation with its own government. Data Type: Country Code Format: [A-Z]{2,2} Rule(s): Country The code is checked against the list of country names obtained from the United Nations (ISO 3166, Alpha-2 code).

6. Details of structure of organization or private person identification in KB

The client can transfer identification of payer, beneficiary, original payer and final beneficiary according to whether the identification refers to an organization or a private person. This chapter specifies tags defined in XML, which are taken over in KB. The following is standard usage:

Selecting the identification type - whether it is an organization of a private person

Using for Organization (<OrgId>) - the <PrtryID> tag with nested <Id> tags for identification data and the <Issr> tag for document issuer.

Using for Private (<PrvtId>) - the <OthrID> tag with nested <Id> tags for identification data, <IdTp> for Document type and the <Issr> tag for document issuer.

5.1.10 Identification <Id> Presence: [0..1] Definition: Unique and unambiguous way of identifying an organisation or an individual person. Type: This message item is composed of one of the following Party 2 Choice element(s):


5.1.11 {Or Organisation Identification <OrgId> [1..1]

5.1.23 Or} Private Identification <PrvtId> [1..4]

5.1.11 Organisation Identification <OrgId> Presence: [1..1] This message item is part of choice 5.1.10 Identification. Definition: Unique and unambiguous way of identifying an organisation. Type: This message item is composed of the following Organisation Identification 2 element(s):


5.1.20 ProprietaryIdentification <PrtryId> [0..1] KB allows only this tag

5.1.20 ProprietaryIdentification <PrtryId> Presence: [0..1] Definition: Unique and unambiguous identifier for an organisation that is allocated by an institution. Type: This message item is composed of the following Generic Identification 3 element(s):


5.1.21 Identification <Id> [1..1] Text Identification data

5.1.22 Issuer <Issr> [0..1] Text Issuer of document

5.1.21 Identification <Id> Presence: [1..1]




13/20

Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier. Data Type: Max 35 Text Format: max Length: 35 Min Length: 1 5.1.22 Issuer <Issr> Presence: [0..1] Definition: Entity that assigns the identification. Data Type: Max 35 Text Format: max Length: 35 Min Length: 1 5.1.23 Private Identification <PrvtId> Presence: [1..4] This message item is part of choice 5.1.10 Identification. Definition: Unique and unambiguous identification of a person, eg, passport. Type: This message item is composed of the following Person Identification 3 element(s):


5.1.37 OtherIdentification <OthrId> [1..1] KB allows only this tag

5.1.40 Issuer <Issr> [0..1] Text Issuer of document

5.1.37 OtherIdentification <OthrId> Presence: [1..1] This message item is part of choice 5.1.23 Private Identification. Definition: Identifier issued to a person for which no specific identifier has been defined. Type: This message item is composed of the following Generic Identification 4 element(s):


5.1.38 Identification <Id> [1..1] Text Identification data

5.1.39 IdentificationType <IdTp> [1..1] Text Document type

5.1.38 Identification <Id> Presence: [1..1] Definition: Identifier issued to a person for which no specific identifier has been defined. Data Type: Max 35 Text Format: max Length: 35 Min Length: 1 5.1.39 IdentificationType <IdTp> Presence: [1..1] Definition: Specifies the nature of the identifier. Usage: IdentificationType is used to specify what kind of identifier is used. It should be used in case the identifier is different from the identifiers listed in the pre-defined identifier list. Data Type: Max 35 Text Format: max Length: 35 Min Length: 1 5.1.40 Issuer <Issr> Presence: [0..1] Definition: Entity that assigns the identifier. Data Type: Max 35 Text Format: maxLength: 35 minLength: 1




14/20

7. Examples of identification definition for Payer and Beneficiary in XML and on DCS Mojebanka channel screens

 <Dbtr> <Id> <OrgId> <PrtryId> <Id>Identification data</Id> <Issr>Issuer of document</Issr> </PrtryId> </OrgId> </Id> </Dbtr>  <Cdtr> <Id> <PrvtId> <OthrId> <Id>Identification data</Id> <IdTp>Document type</IdTp> </OthrId> <Issr>Issuer of document</Issr> </PrvtId> </Id> </Cdtr>  <UltmtDbtr> <Nm>Original payer’s name</Nm> </UltmtDbtr>  <UltmtCdtr> <Id> <PrvtId> <OthrId> <Id>Identification data</Id> <IdTp>Document type</IdTp> </OthrId> <Issr>Issuer of document</Issr> </PrvtId> </Id> </UltmtCdtr>




15/20

8. Example of XML with two payments

Example of two payments sent in a single file:

The first payment is sent for organization, the other for a private person.

Optional identification of partner is transferred in both payments.

Optional debit account currency is specified in the first payment.

In both payments, the optional payment identification item is specified; this item is necessary for processing in KB to keep uniqueness within the framework of the client (if not specified, the EndToEnd item, which would have to proof satisfactory in validation against uniqueness, would be taken over for this purpose).

In both payments, SEPA service level is specified; this field is optional and KB is not performing any other service level for an XML of transferred payments.

Charges are not specified; the bank will use SLEV by default for SEPA.

Number of account for charges is identical as the account number for the actual payment in one of the payments; for the other payment, different account number is required.

<?xml version="1.0" encoding=" UTF-8"?> <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.02">  <pain.001.001.02> <GrpHdr>  <MsgId>20071218PAY1234</MsgId>  <CreDtTm>2008-01-17T16:36:00</CreDtTm>  <NbOfTxs>2</NbOfTxs>  <CtrlSum>300.88</CtrlSum>  <Grpg>SNGL</Grpg>  <InitgPty> <Nm>ABC Consulting s.r.o.</Nm> <PstlAdr> <StrtNm>U žluťoučkého koně</StrtNm> <BldgNb>1622/12</BldgNb> <PstCd>158 00</PstCd> <TwnNm>Praha 13</TwnNm> <Ctry>CZ</Ctry> </PstlAdr> </InitgPty> </GrpHdr>  <PmtInf>  <PmtMtd>TRF</PmtMtd>  <ReqdExctnDt>2008-03-18</ReqdExctnDt>  <Dbtr> <Nm>TKT_NTI a.s.</Nm> <PstlAdr> <StrtNm>Na Příkopě</StrtNm> <BldgNb>22</BldgNb> <PstCd>114 07</PstCd> <TwnNm>Praha 1, Staré Město</TwnNm> <Ctry>CZ</Ctry> </PstlAdr> <Id> <OrgId>




16/20

<PrtryId> <Id>DIC 026-123456789</Id> <Issr>Issuer of document - payment 1</Issr> </PrtryId> </OrgId> </Id> </Dbtr>  <DbtrAcct> <Id> <IBAN>CZ0801000000353105260267</IBAN> </Id> <Ccy>USD</Ccy> </DbtrAcct>  <DbtrAgt> <FinInstnId> <BIC>KOBACZPX</BIC> </FinInstnId> </DbtrAgt> <CdtTrfTxInf> <PmtId>  <InstrId>KB00001 client ID</InstrId>  <EndToEndId>00001 ID agreed with partner</EndToEndId> </PmtId>  <PmtTpInf> <SvcLvl> <Cd>SEPA</Cd> </SvcLvl> </PmtTpInf>  <Amt> <InstdAmt Ccy="EUR">100.67</InstdAmt> </Amt>  <ChrgBr>SLEV</ChrgBr>  <CdtrAgt> <FinInstnId> <BIC>SOGEFRPP</BIC> </FinInstnId> </CdtrAgt>  <Cdtr> <Nm>COMM France Ltd.</Nm> <PstlAdr> <StrtNm>Veine Jugulaire</StrtNm> <BldgNb>58/125B</BldgNb> <PstCd>3PA00</PstCd> <TwnNm>Paris</TwnNm> <Ctry>FR</Ctry> </PstlAdr> <Id> <OrgId> <PrtryId> <Id>PCA000011789B</Id> <Issr>Paris Central Authority</Issr> </PrtryId>




17/20

</OrgId> </Id> </Cdtr>  <CdtrAcct> <Id> <IBAN>FR1420041010050500013M02606</IBAN> </Id> </CdtrAcct>  <RmtInf> <Ustrd>Goods-and-Services-Tax Pay-Off (max length 140 characters)</Ustrd> </RmtInf> </CdtTrfTxInf> </PmtInf>   <PmtInf>  <PmtMtd>TRF</PmtMtd>  <ReqdExctnDt>2008-02-26</ReqdExctnDt>  <Dbtr> <Nm>TKT_NTI a.s.</Nm> <PstlAdr> <StrtNm>Na Příkopě</StrtNm> <BldgNb>22</BldgNb> <PstCd>114 07</PstCd> <TwnNm>Praha 1, Staré Město</TwnNm> <Ctry>CZ</Ctry> </PstlAdr> <Id> <OrgId> <PrtryId> <Id>DIC 026-123456789</Id> <Issr>Issuer of document - payment 2</Issr> </PrtryId> </OrgId> </Id> </Dbtr>  <DbtrAcct> <Id> <IBAN>CZ0801000000353105260267</IBAN> </Id> <Ccy>USD</Ccy> </DbtrAcct>  <DbtrAgt> <FinInstnId> <BIC>KOBACZPX</BIC> </FinInstnId> </DbtrAgt>  <ChrgsAcct> <Id> <IBAN>CZ0801000000353105270297</IBAN> </Id> <Ccy>CZK</Ccy> </ChrgsAcct>




18/20

<CdtTrfTxInf> <PmtId>  <InstrId>KB00002 client ID</InstrId>  <EndToEndId>00002 ID agreed with partner</EndToEndId> </PmtId>  <PmtTpInf> <SvcLvl> <Cd>SEPA</Cd> </SvcLvl> </PmtTpInf>  <Amt> <InstdAmt Ccy="EUR">200.21</InstdAmt> </Amt>  <ChrgBr>SLEV</ChrgBr>  <UltmtDbtr> <Nm>NTI a.s.</Nm> </UltmtDbtr>  <CdtrAgt> <FinInstnId> <BIC>DEUTDEDB101</BIC> </FinInstnId> </CdtrAgt>  <Cdtr> <Nm>Hans Friedrich</Nm> <PstlAdr> <StrtNm>Halsschlagader Strasse</StrtNm> <BldgNb>1</BldgNb> <PstCd>14165</PstCd> <TwnNm>Berlin - Zehlendorf</TwnNm> <Ctry>DE</Ctry> </PstlAdr> <Id> <PrvtId> <OthrId> <Id>FS123456</Id> <IdTp>Fuhrerschein</IdTp> </OthrId> <Issr>Berliner Landesamt</Issr> </PrvtId> </Id> </Cdtr>  <CdtrAcct> <Id> <IBAN>DE89370400440532013000</IBAN> </Id> </CdtrAcct>  <UltmtCdtr> <Id> <PrvtId> <OthrId> <Id>DE012345678901</Id>




19/20

<IdTp>Passport No.</IdTp> </OthrId> <Issr>Münchener Landesamt</Issr> </PrvtId> </Id> </UltmtCdtr>  <RmtInf> <Ustrd>service-supply payment /VS/9876543210 /KS/10 (max length 140 characters)</Ustrd> </RmtInf> </CdtTrfTxInf> </PmtInf>  </pain.001.001.02>

9. Example of SEPA urgent payment version 03

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

- <Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03"> - <CstmrCdtTrfInitn> - <GrpHdr> <MsgId>KB</MsgId>

<CreDtTm>2014-08-04T14:34:37</CreDtTm>

<NbOfTxs>1</NbOfTxs>

<CtrlSum>1.15</CtrlSum>

- <InitgPty> - <PstlAdr>

<StrtNm>NA STROUZE 1</StrtNm>

<PstCd>110 00</PstCd>

<TwnNm>PRAHA</TwnNm>

<Ctry>CZ</Ctry>

</PstlAdr>

</InitgPty>

</GrpHdr>

- 

- <PmtInf> <PmtInfId>NOVE</PmtInfId>

<PmtMtd>TRF</PmtMtd>

- <PmtTpInf>

<InstrPrty>HIGH</InstrPrty>

</PmtTpInf>

<ReqdExctnDt>2014-08-04</ReqdExctnDt>

- <Dbtr> <Nm>KLIENT ABC</Nm>

- <PstlAdr>

<StrtNm>NA STROUZE 1</StrtNm>

<PstCd>110 00</PstCd>

<TwnNm>PRAHA</TwnNm>

<Ctry>CZ</Ctry>

</PstlAdr>

</Dbtr>

- 

- <DbtrAcct> - <Id>

<IBAN>CZ1701000000514127800257</IBAN>

</Id>

<Ccy>CZK</Ccy>

</DbtrAcct>

- <DbtrAgt> - <FinInstnId>

../../../pbarhon/AppData/Local/Microsoft/Windows/Temporary%20Internet%20Files/Content.Outlook/94NM7GGT/XML_SEPA_urgent_CZ.xml
















20/20

<BIC>KOMBCZPPXXX</BIC>

</FinInstnId>

</DbtrAgt>

- <ChrgsAcct> - <Id> <IBAN>CZ1701000000514127800257</IBAN>

</Id>

<Ccy>CZK</Ccy>

</ChrgsAcct>

- <CdtTrfTxInf> - <PmtId>

<InstrId>1</InstrId>

<EndToEndId>1 ID dohodnuté s partnerem</EndToEndId>

</PmtId>

- 

- <PmtTpInf> - <SvcLvl>

<Cd>SEPA</Cd>

</SvcLvl>

</PmtTpInf>

- <Amt>

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

</Amt>

<ChrgBr>SLEV</ChrgBr>

- <CdtrAgt> - <FinInstnId>

<BIC>SOGEFRPPXXX</BIC>

</FinInstnId>

</CdtrAgt>

- <Cdtr> <Nm>Jean Luc Creperu</Nm>

- <PstlAdr> <StrtNm>Le Pufova 1</StrtNm>

<PstCd>PARIS</PstCd>

<Ctry>FR</Ctry>

</PstlAdr>

</Cdtr>

- <CdtrAcct> - <Id>

<IBAN>FR1420041010050500013M02606</IBAN>

</Id>

</CdtrAcct>

- <RgltryRptg>

<Dtls />

</RgltryRptg>

- <RmtInf>

<Ustrd>AV1 DO EHP EUR IBAN AV2 DO EHP EUR IBAN AV3 DO EHP EUR IBAN AV4 DO EHP EUR IBAN</Ustrd>

</RmtInf>

</CdtTrfTxInf>

</PmtInf>

- 

</CstmrCdtTrfInitn>

</Document>

Documents

xml Sepa Ct In Kb - Mojebanka · XML SEPA CT client format in KB (Credit Transfer) Komerční banka, a. s., registered office: Praha 1, Na Příkopě 33, 969, Postcode 114 07, IČ