Preliminary DRAFT version.
Changes and corrections reserved.
Title and Subtitle point to the respective document properties. DO NOT CHANGE THEM DIRECTLY IN THE HEADER, change the appropriate document properties instead !
Indicating Document Sensitivity:
Rules for document classification according to their sensitivity can be found in ORP chapter 1010. The sensitivity of a document is signalized in the upper right corner of each page of the document. This section belongs to the document header to alter the default setting the user has to open the header.
Extra Sensitive: enter “EXTRA SENSITIVE” (on two rows) into the red box.
Sensitive: this is the default setting, the red box says “SENSITIVE”.
Public: discard the red box (the document will not be marked at all).
Since the header of the first page is defined independently on the headers in the rest of the document, it is necessary to execute any changes twice; on the first page and on any other page in the document.
As the Authors and History tables will grow, it is advisable to decrease the vertical gap around the title and subtitle to maintain the contents of the first page „in the middle“ of the page.
Current Account XML Statement
XML file structure specification
Authors of the template TB_Doc_ENG:
Company / Department / Team Name Role
TB / EAI / SOAR Vršanský Ondrej Sponsor
TB / EAI / SOAR Filip Peter Consultant
TB / EAI / SOAR Procháczka Milan Consultant
TB / EAI / SOAR Horanský Pavol Consultant
TB / EAI / SOAR Čerňanský Vladimír Consultant
TB / EAI / SOAR Žatko Július Consultant
The Version History table lists all document versions that have been published over time.
Version / Date / Author / Description /0.1 / 1.8.2013 / Vršanský Ondrej / Initial draft
0.2 / 21.8.2013 / Vršanský Ondrej / Increased the maximal length of the Entry.Narrative attribute.
0.3 / 23.8.2013 / Vršanský Ondrej / · Added the PartyRole attribute to the ComplexPayment class.
· Removed unused attributes of related parties
· Renamed PaymentParty.CountryOfResidence to Country.
· Corrected format od several RltdDts subelements from DateTime to Date. Moved the card POS transaction timestamp from the TradDt to the Prtry element due to this.
0.4 / 9.9.2013 / Vršanský Ondrej / · Corrected “credit”/”debit” copy/paste errors in the Table 9.
· Changed the design of the document header.
0.5 / 19.9.2013 / Vršanský Ondrej / · Removed obsolete links and attributes in Figure 1.
Table 1: Version History.
Version History of the template TB_Doc_ENG:
Version Date Author Description
1.0 15.7.2009 Vršanský Ondrej Initial version translated from the slovak version 2.0
1.1 24.8.2009 Vršanský Ondrej Metatext for Title and Subtitle added.
1.2 1.10.2009 Vršanský Ondrej Metatext for pre-made styles added.
2.0 9.11.2009 Vršanský Ondrej Reworked Header and Footer to accommodate to page orientation.
2.1 18.11.2009 Vršanský Ondrej TOC styles modified – hanging indent assigned.
Pre-made styles:
Following styles have been pre-made for different document parts:
Body Text First Indent for plain text
Heading 1 .. Heading 9 for section and chapter headings. Headings are outline numbered.
Heading 0 a special heading that looks like Heading 1 but has no numbering and is not included in document outline structures. A typical usage is the header for TOC, which we want to look like a heading but at the same time we don’t want it to appear on the TOC.
TBTable for tables. The user can choose which aspect of the style (first row, last row, first column, last column, etc.) should be applied on individual tables.
Metatext for meta-instructions (just like this text J). Metatext uses a hidden font, so that it doesn’t appear on the printed document (or in Word itself, by default). You can make it visible in Word and/or on the paper via Word Options; in such cases, the Metatext can still be distinguished from a normal text by its (blue) color or italics (in case of a B/W printout).
Contents
1. Introduction 4
1.1. Document structure 4
1.2. Legend 5
1.3. Glossary 5
2. Statement attributes description 6
2.1. Logical attributes hierarchy 6
2.1.1. Statement attributes up to the Entry level 6
2.1.2. EuroSIPS payment 7
2.1.3. SWIFT payment 8
2.1.4. SEPA payment 9
2.1.5. Debit card transaction 10
2.1.6. Loan transaction 11
2.1.7. Structured fee 12
2.2. Mapping into XML 13
3. XML file structure 23
3.1. GroupHeader 24
3.2. Statement 26
3.2.1. Account 30
3.2.1.1. Owner 32
3.2.1.1.1. PostalAddress 33
3.2.1.1.2. Identification 34
3.2.1.1.2.1. OrganisationIdentification 35
3.2.1.1.2.2. PrivateIdentification 37
3.2.1.1.3. ContactDetails 39
3.2.2. RelatedAccount 40
3.2.3. Balance 42
3.2.4. TransactionsSummary 45
3.2.5. Entry 48
3.2.5.1. EntryDetails – Instance 1 52
3.2.5.1.1. TransactionDetails 54
3.2.5.1.1.1. References 57
3.2.5.1.1.2. AmountDetails 60
3.2.5.1.1.3. BankTransactionCode 62
3.2.5.1.1.4. Charges 64
3.2.5.1.1.5. RelatedParties 66
3.2.5.1.1.5.1. InitiatingParty 68
3.2.5.1.1.5.2. Debtor 69
3.2.5.1.1.5.2.1. PostalAddress 70
3.2.5.1.1.5.2.2. Identification 71
3.2.5.1.1.5.2.2.1. OrganisationIdentification 72
3.2.5.1.1.5.2.2.2. PrivateIdentification 74
3.2.5.1.1.5.3. DebtorAccount 76
3.2.5.1.1.5.4. UltimateDebtor 77
3.2.5.1.1.5.4.1. Identification 78
3.2.5.1.1.5.4.1.1. OrganisationIdentification 79
3.2.5.1.1.5.4.1.2. PrivateIdentification 81
3.2.5.1.1.5.5. Creditor 82
3.2.5.1.1.5.5.1. PostalAddress 84
3.2.5.1.1.5.5.2. Identification 85
3.2.5.1.1.5.5.2.1. OrganisationIdentification 86
3.2.5.1.1.5.5.2.2. PrivateIdentification 87
3.2.5.1.1.5.6. CreditorAccount 88
3.2.5.1.1.5.7. UltimateCreditor 89
3.2.5.1.1.5.7.1. Identification 90
3.2.5.1.1.5.7.1.1. OrganisationIdentification 91
3.2.5.1.1.5.7.1.2. PrivateIdentification 93
3.2.5.1.1.6. RelatedAgents 95
3.2.5.1.1.6.1. DebtorAgent 97
3.2.5.1.1.6.1.1. PostalAddress 98
3.2.5.1.1.6.2. CreditorAgent 100
3.2.5.1.1.6.2.1. PostalAddress 101
3.2.5.1.1.6.3. IntermediaryAgent1 103
3.2.5.1.1.6.4. Proprietary 104
3.2.5.1.1.7. Purpose 106
3.2.5.1.1.8. RemittanceInfo 106
3.2.5.1.1.9. RelatedDates 108
3.2.5.1.1.10. ReturnInformation 110
3.2.5.1.1.10.1. Originator 112
3.2.5.2. EntryDetails – Instance 2 114
3.2.5.2.1. TransactionDetails 116
3.2.5.2.1.1. References 119
3.2.5.2.1.2. AmountDetails 121
3.2.5.2.1.3. BankTransactionCode 123
3.2.5.2.1.4. RelatedQuantities 124
4. External sources and appendices 125
4.1. ISO 20022 125
4.1.1. camt.053 125
4.1.2. Code lists 125
4.2. SEPA 125
4.2.1. SCT 125
4.2.2. SDD 125
4.3. SBA 125
4.4. TB 125
4.4.1. Proprietary elements schema 125
4.4.2. Code – books 125
1. Introduction
Current account statements are bank-to-client notifications about movements on aclient’s current account. In Tatra banka, these notifications are generated in a variety of formats that range from printed documents through electronic PDF and Excel documents to “pure” data formats (SWIFT, Gemini, Multicash, …).
Since 2004, the ISO 20022 standard – in particular the camt.053 schema – defines an international standard for current 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.
In 2012, Tatra banka decided to use the camt.053 schema internally for data files used to generate current account statements en masse in form of electronic or printed documents.
In 2013, the Slovak Bank Association (further referred as “SBA”) released a national standard for XML bank-to-customer current account transaction statements, based on the camt.053 schema recommended by the EPC. The complete specification of this standard can be found at http://www.sbaonline.sk/sk/presscentrum/aktuality/sepa-narodny-format-xml-vypisu.html.
To keep the interpretation of the camt.053 schema consistent, Tatra banka decided to use a single data structure for both the XML statements based on the national standard and the data files for printed / electronic statements. This way the XML statements can benefit from and build on the existing camt.053 implementation and deliver a much more extensive set of information than required by the SBA standard.
1.1. Document structure
This documents describes the structure of the camt.053 statements generated by Tatra banka. There are three main sections in the document:
1. Description of logical attributes that make up a statement (Chapter 1). An XPath for the attribiute “location” within the XML file is provided for each logical attribute.
2. Structure of the XML file (Chapter 3). 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.:
v [0..0] means that the node is forbidden
v [0..1] means that the node is optional
v [0..n] means that the node can be present any number of times
v [1..1] means that the node is mandatory
v [1..n] means that the node is mandatory but can be repeated any number of times
v [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. Appendices (Chapter 4).
1.2. Legend
To emphasize ISO elements and attributes that are not used by the Tatra banka camt.053 implementation, following background colors are used:
· nodes that are „never used“
· nodes that are „used“ (though they might be optional)
1.3. Glossary
Term / Description /ISO / In the context of this document, this refers to the ISO 20022 standard
camt.053 / An ISO 20022 standard for bank-to-customer current account statetemnts.
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 / „Singe European Payment Area“
SBA / Slovak Banking Association
TB / Tatra banka
XML / „Extensible markup Language“ – awide-spread standard for structured data transfer.
XPath / Standard language used to reference information stored in an XML structure.
Preliminary DRAFT version.
Changes and corrections reserved.
2. Statement attributes description
This chapter lists the logical attributes that can be found within an XML statement.
2.1. Logical attributes hierarchy
2.1.1. Statement attributes up to the Entry level
Figure 1: Statements attributes hierarchy up to the Entry level.
2.1.2. EuroSIPS payment
Figure 2: Attributes of an EuroSIPS payment
2.1.3. SWIFT payment
Figure 3: Attributes of a foreign payment.
2.1.4. SEPA payment
Figure 4: Attributes of a SEPA payment.
2.1.5. Debit card transaction
Figure 5: Attributes of a debit card transaction.
2.1.6. Loan transaction
Figure 6: Attributes of a loan transaction.
2.1.7. Structured fee
Figure 7: Attributes of a structured fee.
2.2. Mapping into XML
Class / Attribute / XPath [ → Proprietary XPath referencing the proprietary elements schema (see chapter 1)] /Document / ID / / Document / BkToCstmrStmt / GrpHdr / MsgId
PageNo / / Document / BkToCstmrStmt / GrpHdr / MsgPgntn / PgNb
IsLastPage / / Document / BkToCstmrStmt / GrpHdr / MsgPgntn / LastPgInd
Recipient / Name / / Document / BkToCstmrStmt / GrpHdr / MsgRcpt / Nm
DeliveryMode / / Document / BkToCstmrStmt / GrpHdr / MsgRcpt / CtctDtls / Othr
EmailAddress / / Document / BkToCstmrStmt / GrpHdr / MsgRcpt / CtctDtls / EmailAdr
GenerationFinish / / Document / BkToCstmrStmt / GrpHdr / CreDtTm
RecipientStructuredAddres / Type / / Document / BkToCstmrStmt / GrpHdr / MsgRcpt / PstlAdr / AdrTp
StreetName / / Document / BkToCstmrStmt / GrpHdr / MsgRcpt / PstlAdr / StrtNm
BuildingNo / / Document / BkToCstmrStmt / GrpHdr / MsgRcpt / PstlAdr / BldgNb
PostCode / / Document / BkToCstmrStmt / GrpHdr / MsgRcpt / PstlAdr / PstCd
TownName / / Document / BkToCstmrStmt / GrpHdr / MsgRcpt / PstlAdr / TwnNm
Country / / Document / BkToCstmrStmt / GrpHdr / MsgRcpt / PstlAdr / Ctry
Statement / ID / / Document / BkToCstmrStmt / Stmt / Id
LegalSeqNo / / Document / BkToCstmrStmt / Stmt / LglSeqNb
FromDate / / Document / BkToCstmrStmt / Stmt / FrToDt / FrDtTm
ToDate / / Document / BkToCstmrStmt / Stmt / FrToDt / ToDtTm
GenerationFinish / / Document / BkToCstmrStmt / Stmt / CreDtTm
Account / Type / / Document / BkToCstmrStmt / Stmt / Acct / Tp / Prtry
Name / / Document / BkToCstmrStmt / Stmt / Acct / Nm
IBAN / / Document / BkToCstmrStmt / Stmt / Acct / Id / IBAN
Currency / / Document / BkToCstmrStmt / Stmt / Acct / Ccy
RelatedAccount / Type / / Document / BkToCstmrStmt / Stmt / RltdAcct / Tp / Prtry
IBAN / / Document / BkToCstmrStmt / Stmt / RltdAcct / Id / IBAN
SavingsSchema / TargetCode / / Document / BkToCstmrStmt / Stmt / AddtlStmtInf
→ StmtInf / SvgsTgt / @Code
TargetName / / Document / BkToCstmrStmt / Stmt / AddtlStmtInf
→ StmtInf / SvgsTgt / Name
TargetAmount / / Document / BkToCstmrStmt / Stmt / AddtlStmtInf
→ StmtInf / SvgsTgt / @Amount
TargetDate / / Document / BkToCstmrStmt / Stmt / AddtlStmtInf
→ StmtInf / SvgsTgt / @Date
MonthlyPayment / / Document / BkToCstmrStmt / Stmt / AddtlStmtInf
→ StmtInf / SvgsTgt / @Payment
CalculatedAttribute / / Document / BkToCstmrStmt / Stmt / AddtlStmtInf
→ StmtInf / SvgsTgt / @CalcAttr
Owner / Name / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / Nm
CIF / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / Id / OrgId / Othr [SchmeNm / Prtry = ‘CIF’] / Id