XML SEPA client format (PDF file) - Komerční banka

XML SEPA client format in KB 

XML SEPA IN KB 

(effective from 22 Nov 2014) 

s 

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/21


Content: 

1. Scope ......................................................................................................................................................................... 3 

2. Application .................................................................................................................................................................. 3 

3. Message structure (items used by KB) ....................................................................................................................... 4 

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 

s 




2/21


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. (Currently, KB is not providing cross-border/SEPA direct debits.) 

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 

s 




3/21


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

s 




4/21


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.cfmdocuments_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 

1 Group leader 

Index OR Message item Mult. Presentation Used in KB 

1.0 GroupHeader [1..1] 

1.1 MessageIdentification [1..1] Text 

1.2 CreationDateTime [1..1] DateTime Used for duplication detection. 

1.5 NumberOfTransactions [1..1] Text validations only with notification 

1.6 ControlSum [0..1] Quantity validations only with notification 

1.7 Grouping [1..1] Code SNGL, GRPD or MIXD required for v02. 

1.8 InitiatingParty [1..1] +- not taken over in KB 

N Payment information 

Index OR Message item Mult. Present Used in KB 

ation 

2.0 PaymentInformation [1..n] 

2.2 PaymentMethod [1..1] Code „TRF“ - required 

2.13 RequestedExecutionDate [1..1] Date Debit due date - 

required 

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

required. 

2.16 DebtorAccount [1..1] + IBAN (currency need 

not be specified; if it is 

specified, it must 

correspond to 

administration, 

otherwise it will be 

rejected) - required. 

2.17 DebtorAgent [1..1] + Not taken over and 

validated by KB; KB 

checks the bank using 

IBAN. 

2.19 UltimateDebtor [0..1] + Will be transferred by 

KB when Rulebook 

3.2. is officially 

approved; clients will 

be informed on KB 

website. 

2.20 ChargeBearer [0..1] Code if not specified, KB will 

use SLEV; if to be 

specified, only SLEV 

can be used. 

2.21 ChargesAccount [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, 

s 




5/21


otherwise it will be 

rejected). 

2.23 CreditTransferTransactionInfo [1..n] compulsory 

rmation 

2.24 PaymentIdentification [1..1] compulsory 

2.25 InstructionIdentification [0..1] Text Unique identification 

for KB (duplicate 

detection); if not 

specified, information 

of the EndToEnd field 

will be used. 

2.26 EndToEndIdentification [1..1] Text compulsory 

Handed over to the 

partner; if InstrId is not 

specified, this value is 

used for KB purpose: 

InstrId = EndToEndId. 

2.27 PaymentTypeInformation [0..1] 

2.28 InstructionPriority [0..1] Code If it is stated "HIGH" = 

urgent payment. If it is 

stated "NORM" or is 

blank = express 

payment. 

2.29 ServiceLevel [0..1] 

2.30 Code [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.37 Amount [1..1] compulsory 

2.38 InstructedAmount [1..1] Amount Amount in EUR 

(required) 

Currencies other than 

EUR will be rejected in 

KB; required. 

2.46 ChargeBearer [0..1] Code Only “SLEV” can be 

used for SEPA 

payments. Not 

compulsory; KB uses 

it by default. 

2.55 CreditorAgent [0..1] + BIC - the bank must 

be SEPA-compliant; 

required. 

2.57 Creditor [0..1] + Name, address - 

required; 

identification (optional) 

2.58 CreditorAccount [0..1] + IBAN - required 

2.59 UltimateCreditor [0..1] + Will be transferred by 

KB when Rulebook 

3.2. is officially 

approved; clients will 

be informed on KB 

website. 

2.84 RemittanceInformation [0..1] 

2.85 Unstructured [0..n] Text Details of payment 

(optional) 

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

FOR Header: 

1.1 MessageIdentification 

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. 

s 




6/21


Usage: The instructing party has to make sure that 'MessageIdentification' is unique per instructed party for 

a pre-agreed period. 

Data Type: Max35Text 

Format: maxLength: 35 

minLength: 1 

1.2 CreationDateTime 


Definition: Date and time at which a (group of) payment instruction(s) was created by the instructing party. 

Data Type: ISODateTime 

1.5 NumberOfTransactions 


Definition: Number of individual transactions contained in the message. 

Data Type: Max15NumericText 

Format: [0-9]{1,15} 

1.6 ControlSum 


Definition: Total of all individual amounts included in the message, irrespective of currencies. 

Data Type: DecimalNumber 

Format: fractionDigits: 17 

totalDigits: 18 

1.7 Grouping 


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 InitiatingParty 


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 PartyIdentification8 element(s): 

FOR Payments 

Or Message Item Mult. Represent./Type 

Name [0..1] Text 

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

- Address in KB. 

2.0 PaymentInformation 

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 PaymentInformation block is composed of the following PaymentInstructionInformation1 element(s): 


2.1 PaymentInformationIdentification [0..1] Text 

2.2 PaymentMethod [1..1] Code TRF 


2.13 RequestedExecutionDate [1..1] DateTime DATE 

2.15 Debtor [1..1] + Address and name 

is not taken over, 

only identification is, 

if specified. 

2.16 DebtorAccount [1..1] + IBAN currency need 

s 




7/21


not be specified. If 

specified, it will be 

validated against the 

status in DB. 

2.17 DebtorAgent [1..1] + Not taken over and 

validated. The bank 

will be validated via 

IBAN. 

2.19 UltimateDebtor [0..1] + Currently not 

transferred by KB. 

2.20 ChargeBearer [0..1] Code KB will use SLEV; 

however, if you 

specify a value, 

which is different 

from SLEV, it will be 

rejected. 

2.21 ChargesAccount [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 CreditTransferTransactionInformation [1..n] Creditor description 

block 

2.2 PaymentMethod 


Definition: Specifies the means of payment that will be used to move the amount of money. 

Data Type: Code – „TRF“ 

2.13 RequestedExecutionDate 


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: ISODate 

2.15 Debtor 


Definition: Party that owes an amount of money to the (ultimate) creditor. 




PostalAddress [0..1] Chapter 5 

Identification [0..1] Chapter 6 

CountryOfResidence [0..1] Code 

2.16 DebtorAccount 


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 CashAccount7 element(s): 


Identification [1..1] 

Currency [0..1] Code 

2.17 DebtorAgent 


Definition: Financial institution servicing an account for the debtor. 

Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification3 element(s): 

s 




8/21



FinancialInstitutionIdentification [1..1] not validated by 

KB 

2.19 UltimateDebtor 


Definition: Ultimate party that owes an amount of money to the (ultimate) creditor. 







2.20 ChargeBearer 


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 ChargeBearerType1Code values must be used: 

Code Name Definition (for KB SEPA is acceptable only SLEV) 

CRED BorneByCreditor All transaction charges are to be borne by the creditor. 

DEBT BorneByDebtor All transaction charges are to be borne by the debtor. 

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 FollowingServiceLevel Charges are to be applied following the rules agreed in the service level and/or scheme. 

2.21 ChargesAccount 


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. 




Currency [0..1] Code 

2.23 CreditTransferTransactionInformation 


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 CreditTransferTransactionInformation1 element(s): 

Index OR Message item Mult. Presentation Used in 

KB 

2.24 PaymentIdentification [1..1] 


2.37 Amount [1..1] 

2.55 CreditorAgent [0..1] + 

2.57 Creditor [0..1] + 

2.58 CreditorAccount [0..1] + 

2.59 UltimateCreditor [0..1] + 

2.84 RemittanceInformation [0..1] 

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. 

Type: This message item is composed of one of the following AmountType2Choice element(s): 

s 




9/21



2.38 InstructedAmount [1..1] Amount Only EUR 

permitted in KB. 

2.38 InstructedAmount 


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 CurrencyCode. 

Format: CurrencyAndAmount 

fractionDigits: 5 

minInclusive: 0 

totalDigits: 18 

CurrencyCode 

[A-Z]{3,3} 

Rule(s): CurrencyCode 

ValidationByTable 

2.55 CreditorAgent 


Definition: Financial institution servicing an account for the creditor. 

Type: This message item is composed of the following BranchAndFinancialInstitutionIdentification3 element(s): 


FinancialInstitutionIdentification [1..1] - the bank must 

be SEPA-complying. 

2.57 Creditor 


Definition: Party to which an amount of money is due. 




PostalAddress [0..1] See chapter 5 

Identification [0..1] See chapter 6 


2.58 CreditorAccount 


Definition: Unambiguous identification of the account of the creditor to which a credit entry will be posted as a result 

of the payment transaction. 


Or Message Item Mult. Represent KB 

./Type 


2.59 UltimateCreditor 


Definition: Ultimate party to which an amount of money is due. 


Or Message Item Mult. Represent KB 

./Type 





s 




10/21


2.84 RemittanceInformation 


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 RemittanceInformation1 element(s): 


2.85 Unstructured [0..n] Text Only nonstructured 

information 

used. 

2.85 Unstructured 


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. 


Format: maxLength: 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 PostalAddress 


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): 

REF OR Message item Mult. Presentation Used in KB 

5.1.4 StreetName [0..1] Text 

5.1.5 BuildingNumber [0..1] Text 

5.1.6 PostCode [0..1] Text 

5.1.7 TownName [0..1] Text 

5.1.9 Country [1..1] Code 

5.1.4 StreetName 


UNIFI (ISO 20022) - Payments Standards - Initiation October 2006 

Message Item Types 

Page 343 

Definition: Name of a street or thoroughfare. 



minLength: 1 

5.1.5 BuildingNumber 


Definition: Number that identifies the position of a building on a street. 



minLength: 1 

5.1.6 PostCode 


Definition: Identifier consisting of a group of letters and/or numbers that is added to a postal address to assist the sorting 

of mail. 


s 




11/21



minLength: 1 

5.1.7 TownName 


Definition: Name of a built-up area, with defined boundaries, and a local government. 



minLength: 1 

5.1.9 Country 


Definition: Nation with its own government. 

Data Type: CountryCode 

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 () - the tag with nested tags for identification data and the tag for 

document issuer. 

• Using for Private () - the tag with nested tags for identification data, for Document type and 

the tag for document issuer. 

5.1.10 Identification 


Definition: Unique and unambiguous way of identifying an organisation or an individual person. 

Type: This message item is composed of one of the following Party2Choice element(s): 


5.1.11 {Or OrganisationIdentification [1..1] 

5.1.23 Or} PrivateIdentification [1..4] 

5.1.11 OrganisationIdentification 


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 OrganisationIdentification2 element(s): 


5.1.20 ProprietaryIdentification [0..1] KB allows only 

this tag 

5.1.20 ProprietaryIdentification 


Definition: Unique and unambiguous identifier for an organisation that is allocated by an institution. 

Type: This message item is composed of the following GenericIdentification3 element(s): 


5.1.21 Identification [1..1] Text Identification 

data 

5.1.22 Issuer [0..1] Text Issuer of 

document 


s 




12/21



Definition: Name or number assigned by an entity to enable recognition of that entity, eg, account identifier. 



minLength: 1 

5.1.22 Issuer 


Definition: Entity that assigns the identification. 



minLength: 1 

5.1.23 PrivateIdentification 


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 PersonIdentification3 element(s): 


5.1.37 OtherIdentification [1..1] KB allows only 

this tag 

5.1.40 Issuer [0..1] Text Issuer of 

document 

5.1.37 OtherIdentification 


This message item is part of choice 5.1.23 PrivateIdentification. 

Definition: Identifier issued to a person for which no specific identifier has been defined. 

Type: This message item is composed of the following GenericIdentification4 element(s): 


5.1.38 Identification [1..1] Text Identification 

data 

5.1.39 IdentificationType [1..1] Text Document type 



Definition: Identifier issued to a person for which no specific identifier has been defined. 



minLength: 1 

5.1.39 IdentificationType 


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. 



minLength: 1 

5.1.40 Issuer 


Definition: Entity that assigns the identifier. 



minLength: 1 

s 




13/21


7. Examples of identification definition for Payer and Beneficiary in XML and on 

DCS Mojebanka channel screens 

 

 

 

 

 

Identification data 

Issuer of document 

 

 

 

 

 

 

 

 

 


Document type 

 


 

 

 

 

 

Original payer’s name 

 

 

 

 

 

 


Document type 

 


 

 

 

s 




14/21


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. 

 

 

 

 

 

 

20071218PAY1234 

 

2008-01-17T16:36:00 

 

2 

 

300.88 

 

SNGL 

s 




15/21


 

 

ABC Consulting s.r.o. 

 

U žluťoučkého koně 

1622/12 

158 00 

Praha 13 

CZ 

 

 

 

 

 

 

TRF 

 

2008-03-18 

 

 

TKT_NTI a.s. 

 

Na Příkopě 

22 

114 07 

Praha 1, Staré Město 

CZ 

 

 

 

 

DIC 026-123456789 

Issuer of document - payment 1 

 

 

 

 

 

 

 

CZ0801000000353105260267 

 

USD 

 

 

 

 

KOBACZPX 

 

 

 

 

 

KB00001 client ID 

 

00001 ID agreed with partner 

 

 

 

s 




16/21


 

SEPA 

 

 

 

 

100.67 

 

 

SLEV 

 

 

 

SOGEFRPP 

 

 

 

 

COMM France Ltd. 

 

Veine Jugulaire 

58/125B 

3PA00 

Paris 

FR 

 

 

 

 

PCA000011789B 

Paris Central Authority 

 

 

 

 

 

 

 

FR1420041010050500013M02606 

 

 

 

 

Goods-and-Services-Tax Pay-Off (max length 140 characters) 

 

 

 

 

 

 

 

TRF 

 

2008-02-26 

 

 

TKT_NTI a.s. 

 

s 




17/21


Na Příkopě 

22 

114 07 

Praha 1, Staré Město 

CZ 

 

 

 

 

DIC 026-123456789 

Issuer of document - payment 2 

 

 

 

 

 

 

 

CZ0801000000353105260267 

 

USD 

 

 

 

 

KOBACZPX 

 

 

 

 

 

CZ0801000000353105270297 

 

CZK 

 

 

 

 

KB00002 client ID 

 

00002 ID agreed with partner 

 

 

 

 


 

 

 

 

200.21 

 

 

SLEV 

 

 

NTI a.s. 

 

 

s 




18/21


 

 

DEUTDEDB101 

 

 

 

 

Hans Friedrich 

 

Halsschlagader Strasse 

1 

14165 

Berlin - Zehlendorf 

DE 

 

 

 

 

FS123456 

Fuhrerschein 

 

Berliner Landesamt 

 

 

 

 

 

 

DE89370400440532013000 

 

 

 

 

 

 

 

DE012345678901 

Passport No. 

 

Münchener Landesamt 

 

 

 

 

 

service-supply payment /VS/9876543210 /KS/10 (max length 140 characters) 

 

 

 

 

 

9. Example of SEPA urgent payment version 03 

 

- 

- 

- 

KB 

2014-08-04T14:34:37 

1 

1.15 

- 

s 




19/21


- 

NA STROUZE 1 

110 00 

PRAHA 

CZ 

 

 

 

- 

- 

NOVE 

TRF 

- 

HIGH 

 

2014-08-04 

- 

KLIENT ABC 

- 

NA STROUZE 1 

110 00 

PRAHA 

CZ 

 

 

- 

- 

- 

CZ1701000000514127800257 

 

CZK 

 

- 

- 

KOMBCZPPXXX 

 

 

- 

- 

CZ1701000000514127800257 

 

CZK 

 

- 

- 

1 

1 ID dohodnuté s partnerem 

 

- 

- 

- 


 

 

- 

1.15 

 

SLEV 

- 

- 

SOGEFRPPXXX 

s 




20/21


 

 

- 

Jean Luc Creperu 

- 

Le Pufova 1 

PARIS 

FR 

 

 

- 

- 

FR1420041010050500013M02606 

 

 

- 

 

 

- 

AV1 DO EHP EUR IBAN AV2 DO EHP EUR IBAN AV3 DO EHP EUR IBAN AV4 DO EHP EUR IBAN 

 

 

 

- 

 

 

s 




21/21

XML SEPA client format (PDF file) - Komerční banka

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?