Strana 4 / 121 Last saved: 18.12.2014 11:33:00
Cash Account XML Statement
SK Format Specification
Company / Name / Role /Czech Banking Association / Author of the czech standard, on which the slovak standard is based.
Management Data Praha spol. s r.o. / Consultant
Slovak Banking Association WG / Facilitator
Table 1: Document Authors.
Revision History
Version / Date / Author / Description /1 / 9/27/2012 / Czech Banking Association / Final version of the czech standard, background document for the slovak standard.
2 / 5/13/2012 / Vršanský Ondrej / · In-depth review of the document, creation of the IssueLog.
· Inclusion of XML elements that weren’t covered by the original document.
· Enriched the information about individual elements with their exact interpretation within the SK standard (cardinality, type and content constraints)
· Concentration of the whole SK standard into one document.
· Replacement of the “sample” Excel with a sample XML.
· Enhanced the document design (header, footer, logo, …)
3 / 6/6/2013 / Vršanský Ondrej / · Revision of the document according to the final SK standard..
4 / 9/27/2014 / Vršanský Ondrej / · A complete redesign of the document.
· Translation of the document into english language.
· Reformulated the “character set” rule in chapter 1.2 (originally chapter 6, page 11).
· Removed the “XML header” sample (chapter 6, page 11); a complete XML sample in chapter 4.4 is provided instead.
· Included the Legend chapter 1.3 and Glossary chapter 1.4.
· Changed the rules for publishing a new version of the standard (chapter 1.5).
· Included a statement type clasifier into the <GrpHdr>/<MsgId> element.
· Reformulated the description of the <GrpHdr>/<AddtlInf> element and removed it from the sample file.
· Included a statement definition ID into the <Stmt>/<Id> element.
· Changed the <Stmt>/<FrToDt> element to mandatory.
· Removed the time portion of the <Stmt>/<FrToDt> subelements from the standard.
· Set the <Acct>/<IBAN> as mandatory (and thus prohibited the <Othr> branch).
· Introduced a set of standardized subject identifiers (chapter 4.3.1) to be used to identify the account owner (and, if necessary, any other party).
· Included the <SchmeNm> and <Issr> subelements of the account servicer and related agent’s <Othr> IDs into the standard.
· Included the <SchmeNm> and <Issr> subelements of an <Othr> identifier of <MsgRcpt>/<Id> and <Acct>/<Ownr>/<Id> into the standard.
· Included the “ITBD”, “OPBD” and “OPAV” balance types into the standard.
· Allowed the <DtTm> option of the <Ntry>/<BookDt> choice.
· Set the <Prtry> subelement of the <BkTxCd> element (both on the <Ntry> and <TxDtls> level and in the <RtrInf>) as mandatory. Its <Issr> subelement was also set as mandatory with a constant value.
· Removed the <Ntry>/<AmtDtls> branch from the standard.
· Reformulated the descriptions of the <MsgId> and <PmtInfId> subelements of the <Ntry>/<NtryDtls>[1]/<Btch> element.
· Constrained the cardinality of the <TxDtls> element.
· Reformulated the descriptions of the <MsgId>, <PmtInfId>, <InstrId>, <EndToEndId>, <TxId> and <ClrSysRef> subelements of the <TxDtls>/<Refs> element.
· Restored the cardinality of the <RltdPties>/<Prtry> element to [0..n].
· Constrained the cardinality of the number of <Othr> identifiers of any “related” party to 1.
· Allowed the <Prtry> option of the <SchmeNm> choice of an <Othr> identifier of a “related” party and included the <Issr> element into the standard.
· Reformulated the descriptions of the <Othr> identifiers of <CdtrAcct> and <DbtrAcct>.
· Corrected the description of the ultimate creditor <Othr> identifier.
· Removed the <RcvgAgt> from the standard. Instead, the <IntrmyAgt1> and <SttlmPlc> were included.
· Aligned the specification of structured remittance info with SEPA rules.
· Introduced the R-Message type into the <RtrInf>/<AddtlInf> element.
· Redefined the placement of card transaction details as follows:
o CardAssociation: RelatedParties / Proprietary [Tp = "CardAssociation"]
o Issuer RelatedAgents / Proprietary [Tp = "Issuer"]
o CardHolder RelatedParties / InitiatingParty
o Merchant RelatedParties / TradingParty
o PointOfTrade RelatedAgents / Proprietary [Tp = "Acquier"] / Branch
o Acquier RelatedAgents / Proprietary [Tp = "Acquier"]
· Unified the formatting of all Date and DateTime elements.
· Added the “Call Center” channel into the specification of the transaction codes.
· Introduced new transaction codes regarding interest and taxes.
5 / 21.11.2014 / Vršanský Ondrej / · Corrected a few minor typo-errors and replaced the term “Current account” in the document title (and on a few other places in the document) with the term “Cash account”.
Table 2: Revision History.
Contents
1. Introduction 6
1.1. Document Structure 6
1.2. Character set 7
1.3. Legend 7
1.4. Glossary 7
1.5. Further maintenance of the standard 8
2. Statement attributes description 9
2.1. Logical attributes hierarchy 9
2.2. Mapping of the attributes into XML 12
3. Statement XML structure 19
3.1. Root element 20
3.2. GroupHeader 21
3.2.1. MessageRecipient 23
3.2.1.1. PostalAddress 24
3.2.1.2. Identification 25
3.2.1.2.1. OrganisationIdentification 26
3.2.1.2.2. PrivateIdentification 27
3.3. Statement 28
3.3.1. Account 30
3.3.1.1. Owner 31
3.3.1.1.1. PostalAddress 32
3.3.1.1.2. Identification 33
3.3.1.1.2.1. OrganisationIdentification 34
3.3.1.1.2.2. PrivateIdentification 35
3.3.1.2. Servicer 37
3.3.1.2.1. PostalAddress 39
3.3.2. Interest 40
3.3.3. Balance 42
3.3.4. TransactionsSummary 45
3.3.5. Entry 47
3.3.5.1. BankTransactionCode 50
3.3.5.2. Charges 51
3.3.5.3. EntryDetails – Instance 1 53
3.3.5.3.1. TransactionDetails 54
3.3.5.3.1.1. References 56
3.3.5.3.1.2. AmountDetails 59
3.3.5.3.1.3. BankTransactionCode 62
3.3.5.3.1.4. Charges 63
3.3.5.3.1.5. RelatedParties 65
3.3.5.3.1.5.1. InitiatingParty 66
3.3.5.3.1.5.2. Debtor 67
3.3.5.3.1.5.2.1. PostalAddress 68
3.3.5.3.1.5.2.2. Identification 69
3.3.5.3.1.5.2.2.1. OrganisationIdentification 70
3.3.5.3.1.5.2.2.2. PrivateIdentification 71
3.3.5.3.1.5.3. DebtorAccount 72
3.3.5.3.1.5.4. UltimateDebtor 73
3.3.5.3.1.5.4.1. PostalAddress 74
3.3.5.3.1.5.4.2. Identification 75
3.3.5.3.1.5.4.2.1. OrganisationIdentification 76
3.3.5.3.1.5.4.2.2. PrivateIdentification 77
3.3.5.3.1.5.5. Creditor 78
3.3.5.3.1.5.5.1. PostalAddress 79
3.3.5.3.1.5.5.2. Identification 80
3.3.5.3.1.5.5.2.1. OrganisationIdentification 81
3.3.5.3.1.5.5.2.2. PrivateIdentification 83
3.3.5.3.1.5.6. CreditorAccount 85
3.3.5.3.1.5.7. UltimateCreditor 86
3.3.5.3.1.5.7.1. PostalAddress 87
3.3.5.3.1.5.7.2. Identification 88
3.3.5.3.1.5.7.2.1. OrganisationIdentification 89
3.3.5.3.1.5.7.2.2. PrivateIdentification 90
3.3.5.3.1.5.8. TradingParty 91
3.3.5.3.1.5.8.1. Identification 92
3.3.5.3.1.5.8.1.1. OrganisationIdentification 93
3.3.5.3.1.5.8.1.2. PrivateIdentification 94
3.3.5.3.1.5.9. ProprietaryParty 95
3.3.5.3.1.6. RelatedAgents 96
3.3.5.3.1.6.1. DebtorAgent 98
3.3.5.3.1.6.1.1. PostalAddress 100
3.3.5.3.1.6.2. CreditorAgent 102
3.3.5.3.1.6.2.1. PostalAddress 104
3.3.5.3.1.6.3. IntermediaryAgent1 105
3.3.5.3.1.6.3.1. PostalAddress 106
3.3.5.3.1.6.4. SettlementPlace 108
3.3.5.3.1.6.4.1. PostalAddress 109
3.3.5.3.1.6.5. Proprietary 111
3.3.5.3.1.7. Purpose 112
3.3.5.3.1.8. RemittanceInfo 113
3.3.5.3.1.8.1. Structured 114
3.3.5.3.1.9. ReturnInformation 115
3.3.5.3.1.9.1. OriginalBankTransactionCode 116
3.3.5.3.1.9.2. Originator 117
3.3.5.3.1.9.2.1. PostalAddress 118
4. External sources and appendices 119
4.1. ISO 20022 119
4.1.1. camt.053 119
4.1.2. Code lists 119
4.2. SEPA 119
4.2.1. SCT 119
4.2.2. SDD 119
4.3. SK code-books 120
4.3.1. Regulated subject identifiers 120
4.3.2. Balance types 120
4.3.3. Transaction codes 121
4.4. Sample statements 121
4.4.1. Astatement withouth pagination 121
4.4.2. Astatement divided into two parts using pagination 121
1. Introduction
The Slovak Payments legislation[1] obliges the payment service providers to notify their payment services consumers about transactions realised on their accounts and defines the minimal mandatory set of attributes to be included in these notifications. The most typical way to comply with this legislation is to provide the client with a transaction statement that covers all required information for a given time period. These statements are being generated either periodically (forming a continuous sequence) or ad-hoc on a customer’s request.
While the legislation defines the “minimal information content” of a statement, it lacks any further instructions regarding internal statements structure and/or format. As a result, a wide range of proprietary implementations emerged on the market, varying both in the internal content and format and in the delivery logistics. While this variety poses no problems for a retail customer, it complicates the statements processing and reconciliation within corporations that typically have to deal with statements from a multitude of accounts in different banks.
On a global scale, the need for standardization of bank statements increased with the growing use of electronic statements and the related prospect of their automated processing. Since 2004, the ISO 20022 standard – in particular the camt.053 schema – defines an international standard for cash account statements structure. All information relevant can be found at www.iso20022.org.
Since 2002, the European Payments Council (further referred as “EPC”) defines rulebooks and standards that constitute the Single European Payment Area (further referred as “SEPA”). All SEPA interbank and bank-to-customer messages were based on the ISO 20022 standard. In October 2009, SEPA issued a “recommendation” to use the camt.053 schema for bank-to-customer currenct account transaction statements. All information regarding EPC and SEPA can be found at http://www.europeanpaymentscouncil.eu/index.cfm.
As in many other countries, the final specification of the national standard for cash account electronic statements was developed under the supervision of the Slovak Banking Association. A close cooperation with the Czech Banking Association in specifying the czech national standard, on which the slovak standard is based, ensured further harmonization of both standards to the benefit of all legal or corporate entities with organisational units in both countries. On top of that, the specification was repeatedly being consulted with experts that were participating on equivatent projects in other countries. This document is the result of this process.
The use of this standard is not obligatory by any part of the Slovak legislation; however, it is highly recommended due to its cost-reduction effects for all parties involved.
1.1. Document Structure
The document is divided into three sections:
1. Description of logical attributes that make up a statement (Chapter 2.1). An XPath for the attribiute “location” within the XML file is provided for each logical attribute.
2. Structure of the XML file (Chapter 2.2). The structure of this chapter reflects the structure of the camt.053 schema; on each level, following information is provided:
· an XPath to the described node
· apicture of the node structure
· atable with information about the node attributes and sub-elements with following columns:
· ISO index: the ISO ID of the node according to the ISO 20022 camt.053 MDR (see chapter 4.1.1).
· ISO name: the ISO name of the node according to the ISO 20022 camt.053 MDR (see chapter 4.1.1).
o one or more “+” signs before the node name signalize that the node is a sub-node of the first preceding node with one-less “+” signs”. The number of „+“ signs denotes the level of node „indentation“ compared to the node decribed by the particular chapter.
· XML Tag : the name of the XML tag according to the ISO 20022 camt.053 MDR (see chapter 4.1.1).
o the XML tag name is stated withouth the „<“ and „>“ characters.
· Cardinality describes the allowed node cardinality:
o [x..y] states that the node is present aminimum of x and amaximum of y times, e.g.:
§ [0..0] means that the node is forbidden
§ [0..1] means that the node is optional
§ [0..n] means that the node can be present any number of times
§ [1..1] means that the node is mandatory
§ [1..n] means that the node is mandatory but can be repeated any number of times
§ [3..3] means that the node is present exactly three times
· Data type describes the node data type
o If the data type field is striked-through with two diagonal lines, the node data type is complex and its individual parts are further described either on the next table rows (in which case they are indented by an additional „+“ sign) or in aseparate chapter (referenced in the last table column).
· Rules Lists rules and constraints on top of the ISO 20022 camt.053 MDR. The rules can constrain:
o cardinality (e.g. [0..n] -> [0..1])
o data type (e.g. String [35] -> String [5])
o value (e.g. „only „Yes“ a „No“ values allowed“)
o semantics (e.g. „for card transactions, this is the card number“)
3. External Sources and Appendices (Chapter 4).
1.2. Character set
Following characters are ensured to be correctly recognised and passed on, unchanged, throughout the entire end-to-end chain:
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
/ - ? : ( ) . , ' +
Space
Other characters might be removed or replaced if not recognised by the system.
1.3. Legend
The national standard regulates only asubset of the elements available within the ISO schema. To clearly distinguish the elements that the standard defines as mandatry from the optional (but still regulated) ones and finally from those it prohibits, following colors are used for the apropriate document sections:
· elements prohibited by the national standard
· elements that the standard allows but somehow regulates
· elements that the standard doesn’t regulate
1.4. Glossary
Term / Description /ISO / International Organisation for Standardisation or one of its products. In the context of this document, this refers to the ISO 20022 standard.
camt.053 / An ISO 20022 standard for bank-to-customer cash account statements.
MDR / „Message Definition Report“ – an ISO document containing the interpretation rules of an ISO standard (such as the camt.053 XSD schema).
EU / European Union
EPC / „European Payments Council“ – an EU body that defines SEPA rulebooks and standards.
SEPA / „Single Euro Payment Area“.
SCT / SEPA Credit Transfer. SEPA standard for payments initiated by the debtor.
SDD / SEPA Direct Debit. SEPA standard for payments initiated by the creditor.
SDD Core / SEPA scheme for debiting retail customers.
SDD B2B / SEPA scheme for debiting corporate customers.
CID / SDD Creditor ID.
SBA / Slovak Banking Association.
XML / „Extensible markup Language“ – awide-spread standard for structured data transfer.
XSD / XML Schema Definition – an XML standard for XML structure specification.
XPath / Standard language used to reference information stored in an XML structure.
Bulk payment / A group of payments that are booked on the debtor account as asingle debit.
Indirect debit / Pre-SEPA national standard for payments initiated by the creditor.
SIPO / „Sústredené inkaso platieb obyvateľstva“ - aspecial type of indirect debit commonly used in CZ and SK.
TPS, SIPS, EuroSIPS / Pre-SEPA Domestic Payments.
ZPS / Foreign Payments
Card Association / The card „trademark holder“ (VISA, MasterCard, ...).
Card Issuer / The bank that issued the card to a customer
Card Holder / The customer to which the card was „issued“
Card Merchant / The company that accepts card transactions as payments for its services.
Card Acquier / The bank that provides the merchant with the POS machines.
ATM / Automatic Teller Machine. Astandalone machine belonging to the card issuer that provides cash withdrawals and other card services.
POS / Point-of-Sale. Amachine belonging to the card acquier and installed by the merchant that provides carrd payments, cashbacks and other card services.
Cash Advance / A cash withdrawal service with apayment card as the authentification tool provided by the card issuer.
Cashback / A cash withdrawal service with apayment card as the authentification tool provided by the card acquier.
Table 3: Glossary.