Version 1.0

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

TB / EAI / SOARVršanský OndrejSponsor

TB / EAI / SOARFilip PeterConsultant

TB / EAI / SOARProcháczka MilanConsultant

TB / EAI / SOARHoranský PavolConsultant

TB / EAI / SOARČerňanský VladimírConsultant

TB / EAI / SOARŽatko JúliusConsultant

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.

0.6 / 23.9.2013 / Vršanský Ondrej /
  • Corrected the cardinality of the proprietary agent FinInstnId (chapter 3.2.5.2.1.6.4).

0.7 / 25.9.2013 / Vršanský Ondrej /
  • Changed the “no value” string in Table 10and Table 12.
  • Corrected the specification of account owner custom attributes (CIF, RC) in chapters2.2, 3.2.1.1.2.1 and 3.2.1.1.2.2.

0.8 / 2.10.2013 / Vršanský Ondrej /
  • Corrected the data format of the Amount and ExchangeRate elements in chapters 3.2.5.2.1.2 and 3.2.5.3.1.2.

0.9 / 16.10.2013 / Vršanský Ondrej /
  • Completed a missing row in Table 13.

0.10 / 18.10.2013 / Vršanský Ondrej /
  • Corrected the placement of the Entry.TxCode attribute from <TxDtls>/<BkTxCd> to <Ntry>/<BkTxCd>.

0.11 / 23.10.2013 / Vršanský Ondrej /
  • Corrected the description of the <NtryDtls> element in chapter 3.2.5.

0.11 / 29.10.2013 / Vršanský Ondrej /
  • Revised the specification of StructuredFee and its attributes.

0.12 / 21.11.2013 / Vršanský Ondrej /
  • Renamed the Entry.CounterPartyAccountIDScheme attribute to CounterPartyAccountIDFormat.
  • Added the AccountOwner.SubjectType attribute. Updated the XPath specification of related attributed due to this.
  • Updated the XPath specification of CounterParty, CounterPartyAccountID, CounterPartyAgent, SEPAPaymentCounterParty, SEPAPaymentCounterPartyID, UltimateParty, SEPAPaymentUltimateParty, SEPAPaymentUltimatePartyID and Purpose attributes.
  • Added the RemittanceInfoFormat attribute. Updated the XPath specification of the RemittanceInfo attribute due to this.

0.13 / 4.12.2013 / Vršanský Ondrej /
  • Updated the description of the / Document / BkToCstmrStmt / Stmt / Ntry / NtryDtls [2] / Btch element and its TtlAmt subelement.

0.14 / 6.12.2013 / Vršanský Ondrej /
  • Corrected damaged and shifted cells in the “Mapping into XML” table in chapter 2.2.

0.15 / 17.12.2013 / Vršanský Ondrej /
  • Changed the cardinality of several Person attributes from mandatory to optional.

0.16 / 31.12.2013 / Vršanský Ondrej /
  • Corrected the Owner.PostalAddress section in chapter 3.2.1.1.1.

0.17 / 7.1.2014 / Vršanský Ondrej /
  • Changed the scheme type and name for account owner birth number from “Cd”/”NIDN” to “Prtry”/”RC” in chapter 3.2.1.1.2.2.

0.18 / 9.1.2014 / Vršanský Ondrej /
  • Included specific reference to SDD CreditorID

0.19 / 20.1.2014 / Vršanský Ondrej /
  • Replaced misspelled “PrvId” with “PrvtId” on 7 occasions.
  • Enhanced the description of “virtual” logical attributes (which are not stored directly but determine a certain choice selection instead – such as OrgId/PrvtId, Cd/Prtry and others).

0.20 / 30.1.2014 / Vršanský Ondrej /
  • Clarified the mapping for SEPA UltimateCreditor and UltimateDebtor in chapter 2.2.

1.0 / 5.2.2014 / Vršanský Ondrej / FIRST PUBLISHED MAJOR VERSION.
1.1 / 4.3.2014 / Vršanský Ondrej /
  • Corrected the cardinality of the <SchmeNm> and <Issr> elements in private identification of payment parties (Creditor, Debtor, UltimateCreditor, UltimateDebtor).

1.2 / 25.5.2014 / Vršanský Ondrej /
  • Added the XPath mapping for GrpHdr.CreDtTm
  • Completed the data type specification of Stmt.ElctrncSeqNb
  • Corrected the cardinality for TxDtls/Refs/ChqNb.
  • Corrected the cardinality for Creditor/Id/PrvtId/Othr

Table1: Version History.

Version History of the template TB_Doc_ENG:

VersionDateAuthorDescription

1.015.7.2009Vršanský OndrejInitial version translated from the slovak version 2.0

1.124.8.2009Vršanský OndrejMetatext for Title and Subtitle added.

1.21.10.2009Vršanský OndrejMetatext for pre-made styles added.

2.09.11.2009Vršanský OndrejReworked Header and Footer to accommodate to page orientation.

2.118.11.2009Vršanský OndrejTOC styles modified – hanging indent assigned.

Pre-made styles:

Following styles have been pre-made for different document parts:

Body Text First Indentfor plain text

Heading 1 .. Heading 9for section and chapter headings. Headings are outline numbered.

Heading 0a 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.

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

Metatextfor meta-instructions (just like this text ). 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

1.1. Document structure

1.2. Legend

1.3. Glossary

2. Statement attributes description

2.1. Logical attributes hierarchy

2.1.1. Statement attributes up to the Entry level

2.1.2. EuroSIPS payment

2.1.3. SWIFT payment

2.1.4. SEPA payment

2.1.5. Debit card transaction

2.1.6. Loan transaction

2.1.7. Structured fee

2.2. Mapping into XML

3. XML file structure

3.1. GroupHeader

3.2. Statement

3.2.1. Account

3.2.1.1. Owner

3.2.1.1.1. PostalAddress

3.2.1.1.2. Identification

3.2.1.1.2.1. OrganisationIdentification

3.2.1.1.2.2. PrivateIdentification

3.2.1.1.3. ContactDetails

3.2.2. RelatedAccount

3.2.3. Balance

3.2.4. TransactionsSummary

3.2.5. Entry

3.2.5.1. BankTransactionCode

3.2.5.2. EntryDetails – Instance 1

3.2.5.2.1. TransactionDetails

3.2.5.2.1.1. References

3.2.5.2.1.2. AmountDetails

3.2.5.2.1.3. BankTransactionCode

3.2.5.2.1.4. Charges

3.2.5.2.1.5. RelatedParties

3.2.5.2.1.5.1. InitiatingParty

3.2.5.2.1.5.2. Debtor

3.2.5.2.1.5.2.1. PostalAddress

3.2.5.2.1.5.2.2. Identification

3.2.5.2.1.5.2.2.1. OrganisationIdentification

3.2.5.2.1.5.2.2.2. PrivateIdentification

3.2.5.2.1.5.3. DebtorAccount

3.2.5.2.1.5.4. UltimateDebtor

3.2.5.2.1.5.4.1. Identification

3.2.5.2.1.5.4.1.1. OrganisationIdentification

3.2.5.2.1.5.4.1.2. PrivateIdentification

3.2.5.2.1.5.5. Creditor

3.2.5.2.1.5.5.1. PostalAddress

3.2.5.2.1.5.5.2. Identification

3.2.5.2.1.5.5.2.1. OrganisationIdentification

3.2.5.2.1.5.5.2.2. PrivateIdentification

3.2.5.2.1.5.6. CreditorAccount

3.2.5.2.1.5.7. UltimateCreditor

3.2.5.2.1.5.7.1. Identification

3.2.5.2.1.5.7.1.1. OrganisationIdentification

3.2.5.2.1.5.7.1.2. PrivateIdentification

3.2.5.2.1.6. RelatedAgents

3.2.5.2.1.6.1. DebtorAgent

3.2.5.2.1.6.1.1. PostalAddress

3.2.5.2.1.6.2. CreditorAgent

3.2.5.2.1.6.2.1. PostalAddress

3.2.5.2.1.6.3. IntermediaryAgent1

3.2.5.2.1.6.4. Proprietary

3.2.5.2.1.7. Purpose

3.2.5.2.1.8. RemittanceInfo

3.2.5.2.1.9. RelatedDates

3.2.5.2.1.10. ReturnInformation

3.2.5.2.1.10.1. Originator

3.2.5.3. EntryDetails – Instance 2

3.2.5.3.1. TransactionDetails

3.2.5.3.1.1. References

3.2.5.3.1.2. AmountDetails

3.2.5.3.1.3. BankTransactionCode

3.2.5.3.1.4. RelatedQuantities

4. External sources and appendices

4.1. ISO 20022

4.1.1. camt.053

4.1.2. Code lists

4.2. SEPA

4.2.1. SCT

4.2.2. SDD

4.3. SBA

4.4. TB

4.4.1. Proprietary elements schema

4.4.2. Code – books

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

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

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

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 chapter4.1.1).
  • ISO name:the ISO name of the node according to the ISO 20022 camt.053 MDR (see chapter4.1.1).
  • 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 tagaccording to the ISO 20022 camt.053 MDR (see chapter4.1.1).
  • the XML tag name is stated withouth the „<“ and „>“ characters.
  • Cardinalitydescribes the allowed node cardinality:
  • [x..y]states that the node is present aminimum ofxand amaximum ofytimes, 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 typedescribes the node data type
  • 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).
  • RulesLists rules and constraints on top of the ISO 20022 camt.053 MDR. The rules can constrain:
  • cardinality(e.g. [0..n] -> [0..1])
  • data type(e.g. String [35] -> String [5])
  • value(e.g. „only „Yes“ a „No“ values allowed“)
  • semantics(e.g. „for card transactions, this is the card number“)
  1. Appendices (Chapter4).

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.





Version 1.0

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
GenerationFinish / / Document / BkToCstmrStmt / GrpHdr / CreDtTm
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 / SubjectType / While not persisted itself, it determines the location of other account owner attributes.
  • / Document / BkToCstmrStmt / Stmt / Acct / Ownr / Id / OrgId represents a corporate subject
  • / Document / BkToCstmrStmt / Stmt / Acct / Ownr / Id / PrvtId represents a person

Name / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / Nm
CIF / For SubjectType = “Corporation”:
/ Document / BkToCstmrStmt / Stmt / Acct / Ownr / Id / OrgId / Othr [SchmeNm / Cd = ‘BANK’] / Id
For SubjectType = “Person”:
/ Document / BkToCstmrStmt / Stmt / Acct / Ownr / Id / PrvtId / Othr [SchmeNm / Cd = ‘BANK’] / Id
ICO / For SubjectType = “Corporation”:
/ Document / BkToCstmrStmt / Stmt / Acct / Ownr / Id / OrgId / Othr [SchmeNm / Prtry = ‘ICO’] / Id
For SubjectType = “Person”:
/ Document / BkToCstmrStmt / Stmt / Acct / Ownr / Id / PrvtId / Othr [SchmeNm / Prtry = ‘ICO’] / Id
Person / Gender / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / CtctDtls / NmPrfx
RC / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / Id / PrvtId / Othr [SchmeNm / Prtry = ‘RC’] / Id
BirthDate / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / Id / PrvtId / DtAndPlcOfBirth / BirthDt
Age / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / Id / PrvtId / Othr [SchmeNm / Prtry = ‘Age’] / Id
OwnerStructuredAddress / StreetName / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / PstlAdr / StrtNm
BuildingNo / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / PstlAdr / BldgNb
PostCode / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / PstlAdr / PstCd
TownName / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / PstlAdr / TwnNm
Country / / Document / BkToCstmrStmt / Stmt / Acct / Ownr / PstlAdr / Ctry
Opening Booked Balance / Amount / / Document / BkToCstmrStmt / Stmt / Bal [Tp / CdOrPrtry / Cd = ‘PRCD’] / Amt
CRDBIndicator / / Document / BkToCstmrStmt / Stmt / Bal [Tp / CdOrPrtry / Cd = ‘PRCD] / CdtDbtInd
Closing Booked Balance / Amount / / Document / BkToCstmrStmt / Stmt / Bal [Tp / CdOrPrtry / Cd = ‘CLBD’] / Amt
CRDBIndicator / / Document / BkToCstmrStmt / Stmt / Bal [Tp / CdOrPrtry / Cd = ‘CLBD’] / CdtDbtInd
Closing Available Balance / Amount / / Document / BkToCstmrStmt / Stmt / Bal [Tp / CdOrPrtry / Cd = ‘CLAV’] / Amt
CRDBIndicator / / Document / BkToCstmrStmt / Stmt / Bal [Tp / CdOrPrtry / Cd = ‘CLAV’] / CdtDbtInd
All EntriesSummary / Count / / Document / BkToCstmrStmt / Stmt / TxsSummry / TtlNtries / NbOfNtries
Amount / / Document / BkToCstmrStmt / Stmt / TxsSummry / TtlNtries / TtlNetNtryAmt
CRDBIndicator / / Document / BkToCstmrStmt / Stmt / TxsSummry / TtlNtries / CdtDbtInd
All CreditsSummary / Count / / Document / BkToCstmrStmt / Stmt / TxsSummry / TtlCdtNtries / NbOfNtries
Amount / / Document / BkToCstmrStmt / Stmt / TxsSummry / TtlCdtNtries / Sum
All DebitsSummary / Count / / Document / BkToCstmrStmt / Stmt / TxsSummry / TtlDbtNtries / NbOfNtries
Amount / / Document / BkToCstmrStmt / Stmt / TxsSummry / TtlDbtNtries / Sum
Entry / ID / / Document / BkToCstmrStmt / Stmt / Ntry / NtryRef
TxCode / / Document / BkToCstmrStmt / Stmt / Ntry / BkTxCd / Prtry / Cd
Category / / Document / BkToCstmrStmt / Stmt / Ntry / AddtlNtryInf
→ / NtryInf / @Ctg
Initiator / / Document / BkToCstmrStmt / Stmt / Ntry / AddtlNtryInf
→ / NtryInf / @Ini
BookingChannel / / Document / BkToCstmrStmt / Stmt / Ntry / AddtlNtryInf
→ / NtryInf / @BkCh
ClearingMethod / / Document / BkToCstmrStmt / Stmt / Ntry / AddtlNtryInf
→ / NtryInf / @Mthd
CounterPartyAccountLocation / / Document / BkToCstmrStmt / Stmt / Ntry / AddtlNtryInf
→ / NtryInf / @CPAL
CounterPartyAccountID / For CounterPartyAccountIDFormat=”IBAN”:
For PartyRole = “Creditor”:
/ Document / BkToCstmrStmt / Stmt / Ntry / NtryDtls [1] / TxDtls / RltdPties / DbtrAcct / Id / IBAN
For PartyRole = “Debtor”:
/ Document / BkToCstmrStmt / Stmt / Ntry / NtryDtls [1] / TxDtls / RltdPties / CdtrAcct / Id / IBAN
For CounterPartyAccountIDFormat=”Other”:
For PartyRole = “Creditor”:
/ Document / BkToCstmrStmt / Stmt / Ntry / NtryDtls [1] / TxDtls / RltdPties / DbtrAcct / Id / Othr / Id
For PartyRole = “Debtor”:
/ Document / BkToCstmrStmt / Stmt / Ntry / NtryDtls [1] / TxDtls / RltdPties / CdtrAcct / Id / Othr / Id
CounterPartyAccountIDFormat / While not persisted itself, it Determines the location of CounterPartyAccountID.
Reversal / / Document / BkToCstmrStmt / Stmt / Ntry /RvslInd
ReversalType / / Document / BkToCstmrStmt / Stmt / Ntry / AddtlNtryInf