General Information (Origin of Request)
User Requirements (URD)
Other User Functional or Technical Documentation (SYS)
Request raised by: Euroclear
Institute: CSD
Date raised: 11/09/2015
Request title: Statement of Transactions and Statement of Settled IntraPosition Movements reporting for Partially Settled transactions to be
made SMPG compliant
Request ref. no: T2S 0549 SYS
Request type: Common
Urgency: Normal
1. Legal/business importance parameter: High
2. Market implementation efforts parameter: Low
3. Operational/Technical risk parameter: Low
4. Financial impact parameter: Medium
Requestor Category: CSD
Status: Authorised at Steering Level
Reason for change and expected benefits/business motivation
The aim of the change request is to address current discrepancy between:

The way T2S reports the Partial settlement in Statement of Transaction reporting (semt.017) and
Statement of Settled Intra-Position Movements (semt.016) and

The SMPG guidelines on Partial Settlement reporting (Last updated in April 2015)
SMPG
According to SMPG Guidelines, the Statement of Transactions should report the settlement information only for the
current business day, i.e.:
•
Settled Quantity during the current business day
•
Settled Amount during the current business day
If a transaction was partialled multiple times across several business days, the statement of transaction should
report each day only the amount/quantity of what settled during that business day.
T2S
T2S reports in the Statement of Transactions (semt.017) and statement of settled intra-position movements
(semt.016) the following information (UDFS v2.0, Page 636, lines 16 to 23)
•
Settled Quantity which is settled up to now
•
Settled Amount which is settled up to now
If a transaction was partialled multiple times during several business days, the T2S statement of transaction
(semt.017) and statement of settled intra-position movements (semt.016) reports the cumulative amount/quantity of
what settled up to now.
Example
Example of a partial settlement over two business days
Instructed Quantity: 10,000 units – 25,000 EUR
Settled Day 1
4,000 units – 10,000 EUR (Partially)
Settled Day 2
6,000 units – 15,000 EUR
Settlement Date S
Settlement Date S+1
SMPG Guidelines
Settled Quantity : 4,000 EUR
Settled Amount : 10,000 EUR
Settled Quantity : 6,000 units
Settled Amount : 15,000 EUR
T2S Reporting
Settled Quantity : 4,000 EUR
Settled Amount : 10,000 EUR
Settled Quantity : 10,000 units
Settled Amount : 25,000 EUR
T2S Programme Office
Request: T2S 0549 SYS
Benefits
The change request will help harmonize market practices and reduce system developments for participants. T2S
reporting will be aligned with standards and participants will not need to develop a specific solution for T2S.
______________________________________________________________________________________________
Description of requested change:
For transactions undergoing partial settlement in multiple partial windows across several business days, T2S must
report in the statement of transaction (semt017) and in statement of settled intra-position movements (semt.016) the
Cumulative Amount/Quantity over ONE business day only.
For a transaction partially settled multiple times during the same business day, the statement of transaction and
statement of settled intra-position movements should report the cumulative amount/quantity during that given
business day.
For a transaction partially settled multiple times across several business days, the statement of transaction and
statement of settled intra-position movements should report each day only the cumulative amount/quantity of what
settled during the current business day.
The delta version of the statement of transaction (semt.017) and statement of settled intra-position movements
(semt.016) should report the cumulative quantity/amount that settled during the reporting period of the delta report only.
The flat file versions of statement of transaction and statement of settled intra-position movements should also report
the Cumulative Amount/Quantity over ONE business day only, following a like-for-like approach regarding the
report content.
_______________________________________________________________________________________________
Submitted annexes / related documents:

SMPG Partial Settlement guidelines
http://smpg.info/fileadmin/documents/3_Settlement%20and%20Reconciliation%20WG/A_Final%20Global%20Market%
20Practices/PARTIAL_SETTLEMENT_4_7.pdf

T2S_0549_SYS_attachment – Flat file for Statement of settled intra-position movements

T2S_0549_SYS_attachment - Flat file for Statement of transactions
_______________________________________________________________________________________________
Proposed wording for the Change request:
Statement of Transaction and Statement of Settled Intra-Position Movements in Case of Partial Settlement made
SMPG compliant (Cumulative amount/quantity over one business day).
_______________________________________________________________________________________________
High level description of Impact:
UDFS:
1.6.4.2.3 Report generation process , p.694 :
Statement of Transactions
This report is available in both versions – complete and delta versions. The complete version informs the T2S
Actor about those Settlement Instructions that reached "settled" status or "partially settled" status (that means the
quantity and amount that settled (so far) on the current business day are returned) since the SoD of the current
settlement day. It provides information on their latest status and current attribute values at the time of the report
generation.
1.6.4.2.3 Report generation process , p.699-700 :
Statement of Settled Intra-Position Movements
This report is available in both versions – complete and delta versions. The complete report informs the T2S Actor
about those intra-position movements that reached “settled status” or “partially settled” status during the reporting
period between the SoD of the current business day and the moment of report creation. The cumulative quantity
which was settled on the current business day/during the reporting period will be reported.
2
T2S Programme Office
Request: T2S 0549 SYS
Flat File Format Specifications
The specifications of the statement of transactions and settled intra position movements need to be updated as
follows:
Data
Format
Description
Body 9
Settled Quantity
NUMERI
C(p)
1
4
Body 1
0
Number of
decimal digits
For Settled
Quantity
NUMERI
C(p)
2
Body 1
1
Previous Settled
Quantity
NUMERI
C(p)
1
4
Body 1
2
Number of
decimal digits
For Previous
Settled Quantity
NUMERI
C(p)
2
Body 1
3
Remaining to be
Settled Quantity
NUMERI
C(p)
1
4
Body 1
4
Number of
decimal digits
for remaining to
be Settled
Quantity
DECIMA
L(n)
2 Number of
decimal digits for
remaining to
settled Quantity
Field Type
Field Name
Length
Rec
ord
Typ
e
Field Number
Statement of Settled Intra-position Movements flat file - File format specifications
Additional Information
M Integer Part of the Settled Quantity
Quantity of
financial
The settled quantity will be the quantity
instrument
settled during the business day which the
effectively settled
information contained in the report refers to.
in Unit or Face
Amount
M Number of decimals for the Settled
Number of
decimal digits for
Quantity.
the Settled
The settled quantity will be the quantity
Quantity
settled during the business day which the
information contained in the report refers to.
O Integer Part of the Previous Settled
Quantity of
Quantity.
financial
instrument
The previous settled quantity will be
previously settled
calculated as the Original Quantity minus
in Unit or Face
Settled Quantity (of the reporting period)
Amount
minus Remaining to be Settled Quantity
O Number of decimals for the Previous
Number of
Settled Quantity.
decimal digits for
the Settled
The previous settled quantity will be
Quantity
calculated as the Original quantity minus
Settled quantity (of the reporting period)
minus Remaining to be Settled Quantity
O Integer Part of the Remaining to be Settled
Quantity of
Quantity
financial
instrument
Remaining to be
settled
O Number of decimals for the Remaining to
be Settled Quantity
3
T2S Programme Office
Request: T2S 0549 SYS
Data
Format
Body 1
8
Posting Quantity
integer part
NUMERI
C(p)
1
4
Body 1
9
Number of
decimals for
Posting Quantity
NUMERI
C(p)
2
Body 2
0
Posting Amount
Currency
CHAR(n) 3
Body 2
1
Posting Amount
integer part
NUMERI
C(p)
1
4
Body 2
2
Number of
decimals for
Posting Amount
NUMERI
C(p)
2
Description
Field Type
Field Name
Length
Rec
ord
Typ
e
Field Number
Statement of Transactions flat file - File format specifications
Additional Information
Quantity of
financial
instrument (to be)
posted to the
safekeeping
account.
Expressed as
units or face
amount
Quantity of
financial
instrument (to be)
posted to the
safekeeping
account.
Expressed as
units or face
amount
Currency of the
amount of money
that is to be/was
posted to the
account:
(active or historic
currency code)
Cash entry
(amount)
M The posting quantity will be the quantity
settled during the business day which the
information contained in the report refers to.
Number of
decimals for the
cash entry
(amount)
O The posting amount will be the amount
settled during the business day which the
information contained in the report refers to.
M The posting quantity will be the quantity
settled during the business day which the
information contained in the report refers to.
O * If Posting Amount is present, both
* Currency and Credit/Debit Indicator must
be present.
O The posting amount will be the amount
settled during the business day which the
information contained in the report refers to.
UHB:
2.4.1.21 Available Report - Statement of Transactions - Details Screen, p. 490-491
Settled Settlement Quantity
Shows the so far settled settlement quantity which was settled on the current
business day/during the reporting period.
…
…
Settled Settlement Amount
Shows the so far settled settlement amount which was settled on the current
business day/during the reporting period.
4
T2S Programme Office
Request: T2S 0549 SYS
2.4.1.18 Statement of Settled Intra-Position Movements - Details Screen, p. 469
Settled Settlement Quantity
Shows the number of already settled securities which was settled on the
current business day/during the reporting period.
_______________________________________________________________________________________________
Outcome/Decisions:
*CRG meeting of 17-18 September 2015: The CRG agreed to put the Change Request on hold and exclude it from
Release 1.2. The ECB will seek the SMPG guidance to check whether the Change Request is implementing the
Statement of Transactions in line with the SMPG standards, in particular, whether the standards also apply to the delta
version of the Statement of Transactions. The ECB will also ask the SPMG for clarifications regarding some
contradictory statements in the SPMG standards (e.g. “that the partial settlements must be immediately reported”;
however, the Statement of Transactions is not a real-time report).
*CRG meeting of 28 October 2015: The CRG acknowledged that the scope of the Change Request will be updated for
including Statement of Settled Intra-Position Movements (semt.016) to align it with the SMPG standards. The CRG also
acknowledged informal feedback from SMPG that the CR-549 is implementing the Statement of Transactions in line
with the SMPG standards.
* CRG meeting on 8-9 February 2016: The CRG identified the Change Request as a candidate for the Release 1.3. The
CRG agreed to re-discuss the Change Request in the next CRG teleconference on 24 February 2016 when deciding on
the list of Change Request for Release 1.3.
* CRG teleconference of 24 February 2016: The CRG decided to put the Change Request on hold and identified as
candidate for Release 1.3.
* CRG meeting of 10 March 2016: The CRG decided to put the Change Request on hold.
* CRG teleconference of 24 March 2016: The CRG recommended the Change Request for detailed assessment.
* Advisory Group on 06 April 2016: In a written procedure from 31 March 2016 to 06 April 2016, the Advisory Group
was in favour of launching the detailed assessment on the Change Request.
* CSD Steering Group on 07 April 2016: In a written procedure from 31 March 2016 to 07 April 2016, the CSD Steering
Group was in favour of launching the detailed assessment on the Change Request.
* OMG on 8 April 2016: During a written procedure from 31 March 2016 to 8 April 2016, the Operations Managers
Group did not identify any operational impact.
* CRG meeting on 6/7 July 2016: The CRG recommended the approval of Change Request and its inclusion in the T2S
Release 1.3, in principle subject to feasibility of delivery for Release 1.3.
* OMG on 6 July 2016: During a written procedure from 30 June 2016 to 06 July 2016, the Operations Managers Group
did not identify any operational impact.
* CRG teleconference on 29 July 2016: The CRG was informed about the potential performance impact of the Change
Request and the need of having a dedicated performance testing campaign to identify any potential performance
impact. In case of performance impact, the 4CB will also provide mitigation measures that could potentially result in an
increase of the Change Request cost. The CRG also took note that the planning of this campaign will be provided
around mid-August 2016.
* OMG in a written procedure from 5 to 12 August 2016: The OMG was in favour of adding the Change Request to the
T2S Release 1.3.
* Advisory Group on 18 August 2016: Following a written procedure from 12 to 18 August 2016, the AG was in favour of
approving the Change Request.
* CSD Steering Group on 19 August 2016: Following a written procedure from 12 to 19 August 2016, the CSG adopted
the resolution to approve the Change Request.
* Advisory Group on 20 September 2016: Following a written procedure from 14 to 20 September 2016, the AG was in
favour of inclusion of Change Request in T2S Release 1.3.
* CSD Steering Group on 21 September 2016: During the CSG meeting on 21 September 2016, the CSG adopted the
resolution to include the Change Request in T2S Release 1.3.
5
T2S Programme Office
Request: T2S 0549 SYS
EUROSYSTEM ANALYSIS – GENERAL INFORMATION
Impact
On
T2S
Static data management
Party data management
Securities data management
T2S Dedicated Cash account data
management
Securities account data management
Rules and parameters data
management
Interface
Communication
Outbound processing
Inbound processing
Settlement
x Standardisation and preparation to
settlement
Night-time Settlement
Daytime Recycling and optimisation
Daytime Validation, provisioning &
booking
Auto-collateralisation
Liquidity management
Outbound Information Management
NCB Business Procedures
Liquidity Operations
LCMM
Instructions validation
Status management
Instruction matching
Instructions maintenance
Statistics, queries reports and archive
x Report management
Query management
Statistical information
Legal archiving
x
Operational services
Data Migration
Scheduling
Billing
Operational monitoring
All modules (Infrastructure request)
No modules (infrastructure request)
Business operational activities
Technical operational activities
Impact on major documentation
Document
Chapter
Impacted
GFS chapter
1.6.4.2.3 Report generation process
Impacted UDFS
chapter
Additional
deliveries for
Message
Specification
UHB
Change
Add the information that the cumulative amount
or quantity which settled on the current business
day/during the reporting period will be reported.
Statement of Settled Intra-position
Movements flat file - File format
specifications
Statement of Transactions flat file - File
format specifications
Add the information as regards how the
quantities / amounts reported in the flat file are
calculated
3.3.7.5
IntraPositionMovementPostingReportV03
(semt.016.001.03)
3.3.7.6
SecuritiesTransactionPostingReportV03
(semt.017.001.03)
2.4.2.21 Available Report - Statement of
Transactions - Details Screen
2.4.1.18 Available Report - Statement of
Settled Intra- Position Movements Details Screen
To update the message documentation
Update of field descriptions: Settled Settlement
Quantity and Settled Settlement Amount
Update of field description: Settled Settlement
Quantity
External training
materials
Other
6
T2S Programme Office
Request: T2S 0549 SYS
documentations
Links with other requests
Links
Reference
Title
OVERVIEW OF THE IMPACT OF THE REQUEST ON THE T2S SYSTEM AND ON THE PROJECT
Summary of functional, development, infrastructure and migration impacts
Update of documentation for Statement of Transactions and Statement of Settled Intra-Position Movements both
for ISO reports and for the flat file format. The reports will report the quantity and amount which have settled on the
current business day/during the reporting period. In case partial settlement occurred on previous business day(s),
the formerly settled quantity/amount will not be taken into account.
Therefore, the respective A2A documentation has to be updated.
As these reports can also be viewed via GUI, additionally the respective U2A specification has to be corrected.
The correct behaviour has to be tested.
As regards of the flat file reports, the way T2S calculates the following fields should be changed:
For Statement of Transactions:
Posting Quantity and Posting Amount: The settled quantity would be the quantity settled during the business
day to which the information contained in the report refers.
For Statement of Settled Intra-position Movements:
Settled Quantity: The settled quantity would be the quantity settled during the business day to which the
information contained in the report refers.
Previously Settled Quantity: It will be calculated as Original Quantity minus Settled quantity (of the reporting
period) minus Remaining quantity
Remaining to be Settled Quantity: the description and calculation of this field does not change but it is included
here for comprehensive reasons.
Summary of project risk
-Security analysis
No potentially adverse effect was identified during the security assessment.
7
T2S Programme Office
Request: T2S 0549 SYS
DG - MARKET INFRASTRUCTURE & PAYMENTS
MARKET INFRASTRUCTURE MANAGEMENT
ECB-PUBLIC
30 June 2016
Cost assessment on Change Requests
T2S-549-SYS – Statement of Transactions and Statement of Settled Intra-Position Movements reporting for
Partially Settled transactions to be made SMPG compliant
One-off
Assessment cost*
- Preliminary
- Detailed
One-off
Project phase costs
Annual
Running costs
2,000.00
Euro
10,000.00
Euro
203,558.70
Euro
15,880.34
Euro
*The relevant assessment costs will be charged regardless of whether the CR is implemented (Cf. T2S Framework Agreement,
Schedule 7, par. 5.2.3).
8
Statement of Settled Intraposition Movements flat file
File format specifications
Author 4CB
Version 0-0-4
Date 07/06/2016
Status Draft
Classification
Accessible
Classified until
Table of Content
TABLE OF CONTENT ............................................................................... 2
INTRODUCTION ..................................................................................... 4
CONTEXT ..................................................................................................................... 4
PURPOSE ..................................................................................................................... 4
FILE TECHNICAL SPECIFICATION ...................................................... 4
IDENTIFICATION AND ROUTING ................................................................................ 4
STRUCTURE ................................................................................................................. 5
XML Schema for the Request ...................................................................... 5
Example of XML Request ............................................................................. 6
Encoding.......................................................................................................... 6
Default Values ................................................................................................ 6
ISO 15022 Interoperability ......................................................................... 6
Character Set ................................................................................................. 6
FORMAT OF STRUCTURED FILES ........................................................ 7
RECORD TYPES ........................................................................................................... 7
FIELD TYPES................................................................................................................ 7
DATA FORMAT TYPES ................................................................................................. 7
PAGINATION ............................................................................................................... 7
FORMAT OF RECORDS ................................................................................................ 8
2
History of releases
1
RELEASE
DATE
ISSUES
STATUS1
V0-0-1
16/05/2015
First draft CR 494
Draft
V0-0-2
15/07/2015
Second draft CR 494
Draft
V0-0-3
30/12/2015
CR 589 Non-Editorial changes to the Flat File solution for reports at EoD
Draft
V0-0-4
07/06/2016
CR 549 Statement of Transactions and Statement of Settled IntraPosition Movements reporting for Partially Settled transactions to be
made SMPG compliant
Draft
Status value : Draft, Open, Final, Dismiss
3
Introduction
Context
The following critical EoD reports may be generated in full and/or delta versions as flat files if opted by
CSDs, following a like-for-like approach to the report content of the already available XML versions:
 semt.002 - Statement of Holdings
 semt.016 - Statement of Settled Intra-position Movements
 semt.017 - Statement of Transactions
 semt.018 - Statement of Pending Instructions
 semt.034 - Statement of Pending Intra-position Movements
All the reports will contain a signature only at DEP level and will be routed to a given Party Technical
Address previously determined and configured by T2S Service Desk.
Purpose
This document provides a description of the structure of the flat file for the semt.016 Statement of
Settled Intra-position Movements sent by T2S to the CSDs.
File Technical Specification
The file has a simple XML format (in order to allow for the network signature). All records are included
into a single “store and forward” message conveyed by the VAN provider. No business signature is
needed.
Within the message, the whole file is embedded in a single XML tag (<File> </File>).
Between these tags the file has fixed-length records, with a header and a footer. This header and footer
are the ones specified within the flat file specifications below, no business header is foreseen. For delta
reports where no activity has occurred the file will be empty between the header and the footer.
Identification and Routing
T2S triggers the generation of flat file reports based on a business event, e.g. End of Day. All flat file
reports are pushed in A2A mode and compressed when they exceed the minimum size of 2KB, since
compression for these reports is mandatory.
All information about the necessary attributes in each named category is stored as static data in T2S
and influences the generation of the report. The privilege to configure these static data or subscribe to
a certain report is granted solely to the T2S Operator.
4
Each flat file report type provides information on the default data scope of the concerned party (i.e.
CSD). The data scope is indicated by the party for which it is configured and is limited to CSDs, i.e. a
Statement of Settled Intraposition Movements reports on all Securities Accounts of the indicated party.
Flat file reports can only be configured at a system entity level, i.e. reports providing the CSD with
information relating to all its CSD participants. The concerned party has to be specified, when the flat
file report is configured for the first time.
A party configured to receive flat file reports cannot receive the equivalent reports through other
channels. This does not, however, prevent CSD participants from receiving those reports through such
channels, even if their CSD has opted for the flat file.
Structure
XML Schema for the Request
The following is the XML schema used to embed the file into a “store and forward” message:
<?xml version="1.0" ?>
<xs:schema xmlns="urn:T2S:StatementOfSettledIntraPositionMovementsFlatFile"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:T2S: StatementOfSettledIntraPositionMovementsFlatFile"
elementFormDefault="qualified">
<xs:simpleType name="RestrictedFileType">
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
<xs:element name="File" type="File"/>
<xs:complexType name="File">
<xs:simpleContent>
<xs:extension base="RestrictedFileType">
<xs:attribute name="fileId" type="xs:string" default="" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
5
Example of XML Request
<?xml version="1.0" encoding="UTF-8"?>
<File fileId = “T2Ssemt016FlatFile20150630” xmlns="urn:T2S:
StatementOfSettledIntraPositionMovementsFlatFile">Header
Record1
Record2
…
Recordn
Footer
</File>
Encoding
The encoding of the flat file is UTF-8 with no Byte Order Mark (BOM).
Default Values
See Field Types.
ISO 15022 Interoperability
In order to ensure the interoperability to the ISO 15022 standard the character set of all fields is restricted
to the SWIFT X Character Set (see below).
Character Set
All characters belong to the SWIFT X Character Set. The character set is as follows:
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
/ - ? : ( ) . , ' + { }
CR LF Space
6
Format of Structured Files
Record Types
Record Type
Description
Multiplicity
Header
First row of the file contains statement general information, common to all data
records.
1
Body
Data record constitutes one instance of report information.
Many
Footer
Last row of the file. Acts as a trailer, marking the end of main body section.
1
XMLTag
XML element, used to tag the start and/or end of a data block.
1
Field Types
Field Type
Description
O
Optional
O*
Optional, with restrictions
M
Mandatory
Whenever an optional field is not present, the position will be filled with spaces (#x20).
Data Format Types
The report data values may appear in one of the formats described in the table below:
Data Type
Format
Description
DATE
YYYY-MM-DD
DATETIME
YYYY-MM-DD-hh.mm.ss.ssssss
Timestamp format
CHAR(n)
Filled with trailing blanks up to the
maximum length
Alphanumeric string with exactly n characters.
NUMERIC(p)
Filled with leading zeroes up to the
maximum length
Number with maximum p integer places and no
decimal places.
Pagination
Pagination will be provided as in the ISO reports, indicating a sequential number and whether the file
is the last one (Page Number, Last Page Indicator Number).
7
XMLTag
Field Name
1
Data Format
Description
Field Type
Record
Type
Length
Field Number
Format of Records
Additional Information
CHAR(n)
60
"<File>"
M
May contain the optional attribute field to provide additional information
such as a file reference assigned by the sender, up to 54 characters long
(this length though fixed is not definitive and may be subject to change
during the design process).
Values:
'H': for Header
Header
Header
1
Record Type
CHAR(n)
1
Identifies record as Header,
Body or Footer
M
Header
2
Page Number
NUMERIC(p)
5
Sequence number of the
concerned message within
the set of divided messages
recurring to pagination
M
Header
3
Last Page Indicator
CHAR(n)
5
Indicator for last message
within the set of divided
messages recurring to
pagination
M
Reference common to all
pages of a statement.
M
Header
4
Statement Identification
CHAR(n)
16
Values:
True (meaning 'Yes, it is the last message')
False (meaning 'No, it is not the last message')
Built like this:
- CSD (4 characters)
- Report type (4 characters)
- Report mode (1 character)
- BD (yymmdd, 6 characters)
- Frequency (1 character)
Header
5
Statement Period From
DATETIME
26
Statement period start date
and time.
M
Header
6
Statement Period To
DATETIME
26
Statement period end date
and time.
M
Header
7
Statement Frequency
CHAR(n)
4
Frequency of the statement.
M
Values are extracted from the Attribute domain depending on the
configuration performed by the T2S Operator; Proposed values:
DAIL: daily
WEEK: Weekly
MONT: Monthly
Header
8
Statement Update Type
CHAR(n)
4
Indicates whether the
statement is complete or
contains changes only.
M
Values:
COMP: Complete - Statement is complete.
DELT: Delta - Statement contains changes only.
Header
9
Statement Activity Indicator
CHAR(n)
5
Indicates whether there is
activity or information update
reported in the statement.
M
Values:
True (meaning 'Yes')
False (meaning 'No')
Header
10
LF
CHAR(n)
1
Fixed Value: LF
M
LF = Line Feed (x'0A')
Body
1
Record Type
CHAR(n)
1
Identifies record as Header,
Body or Footer.
M
Values:
'B': for Body
Body
2
Account Owner BIC
CHAR(n)
11
O
Primary BIC of the T2S
party owning the securities
account (Party code).
Body
3
Safekeeping Account
CHAR(n)
35
Securities account number of
the T2S party.
M
Body
4
ISIN
CHAR(n)
12
Securities Code.
M
Body
5
Balance From
CHAR(n)
4
Sub-balance from which the
securities were moved.
M
Body
Either the restriction type AWAS (Balance of financial instruments that
are freely available with no specific additional status) or a Proprietary
Identification code, defined by the CSD: ex RES1
9
Body
6
Issuer
CHAR(n)
4
Entity that assigns the
identification.
O*
This element is mandatory if a Proprietary Code is given.
Body
7
Scheme Name
CHAR(n)
4
Short textual description of
the scheme.
O*
Body
8
Market Infrastructure
Transaction Identification
CHAR(n)
16
Identification of a transaction
assigned by a market
infrastructure other than a
central securities depository,
for example, Target2Securities.
M
Body
9
Settled Quantity
NUMERIC(p)
14
Quantity of financial
instrument effectively settled
in Unit or Face Amount
M
Number of decimal digits for
the Settled Quantity
M
Quantity of financial
instrument previously settled
in Unit or Face Amount
O
Number of decimal digits for
the Settled Quantity
O
Body
10
Number of decimal digits
NUMERIC(p)
2
For Settled Quantity
Body
Body
11
12
Previous Settled Quantity
Number of decimal digits
NUMERIC(p)
NUMERIC(p)
14
2
For Previous Settled
Quantity
Body
13
Remaining
Quantity
to
be
Settled NUMERIC(p)
Body
14
Number of decimal digits
for remaining to be Settled
Quantity
DECIMAL(n)
Single value: ‘T2S’ as the constant representing the Issuer within T2S.
Single value: ‘RT’ as the constant representing the Schema Name for
‘Restriction Type’ within T2S. This element is mandatory if a Proprietary
Code is given.
Integer Part of the Settled Quantity.
The settled quantity will be the quantity settled during the business day
which the information contained in the report refers to.
Number of decimals for the Settled Quantity.
The settled quantity will be the quantity settled during the business day
which the information contained in the report refers to.
Integer Part of the Previous Settled Quantity.
The previous settled quantity will be calculated as the Original Quantity
minus Settled Quantity (of the reporting period) minus Remaining to be
Settled Quantity
Number of decimals for the Previous Settled Quantity.
The previous settled quantity will be calculated as the Original Quantity
minus Settled Quantity (of the reporting period) minus Remaining to be
Settled Quantity
14
Quantity
of
financial O
instrument Remaining to be
settled
Integer Part of the Remaining to be Settled Quantity
2
Number of decimal digits for
remaining to settled Quantity
Number of decimals for the Remaining to be Settled Quantity
O
10
Body
15
Securities Sub Balance Id
CHAR(n)
30
Restriction Reference as
assigned by T2S during the
setup of a restriction
O
Body
16
Balance To
CHAR(n)
4
Balance to which the
securities were moved
M
Either the restriction type AWAS (Balance of financial instruments that
are freely available with no specific additional status) or a Proprietary
Identification code, defined by the CSD: ex RES1
Body
17
Issuer
CHAR(n)
4
Entity that assigns the
identification.
O*
Single value: ‘T2S’ as the constant representing the Issuer within T2S.
This element is mandatory if a Proprietary Code is given.
Single value: ‘RT’ as the constant representing the Schema Name for
‘Restriction Type’ within T2S. This element is mandatory if a Proprietary
Code is given.
Body
18
Scheme Name
CHAR(n)
4
Short textual description of
the scheme.
O*
Body
19
Settlement Date
DATE
10
Date at which the securities
were moved.
M
Body
20
LF
CHAR(n)
1
Fixed Value: LF
M
LF = Line Feed (x'0A')
Footer
1
Record Type
CHAR(n)
1
Identifies record as Header,
Body or Footer
M
Values:
'F': for Footer
Footer
2
Number Of Records
NUMERIC(p)
18
Total number of data records
in the file.
M
Number: integer representation, 18 digits long.
Footer
3
LF
CHAR(n)
1
Fixed Value: LF
M
LF = Line Feed (x'0A')
XMLTag
1
CHAR(n)
7
"</File>"
M
Footer
11
Statement of Transactions
flat file
File format specifications
Author 4CB
Version 0-0-4
Date 29/04/2016
Status Draft
Classification
Accessible
Classified until
Table of Content
TABLE OF CONTENT .................................................................................2 INTRODUCTION .......................................................................................4 CONTEXT .................................................................................................................. 4 PURPOSE .................................................................................................................. 4 FILE TECHNICAL SPECIFICATION ........................................................4 IDENTIFICATION AND ROUTING .............................................................................. 4 STRUCTURE .............................................................................................................. 5 XML Schema for the Request .................................................................... 5 Example of XML Request ........................................................................... 6 Encoding ....................................................................................................... 6 Default Values ............................................................................................. 6 ISO 15022 Interoperability ....................................................................... 6 Character Set ............................................................................................... 6 FORMAT OF STRUCTURED FILES ..........................................................7 RECORD TYPES ......................................................................................................... 7 FIELD TYPES ............................................................................................................. 7 DATA FORMAT TYPES ............................................................................................... 7 PAGINATION ............................................................................................................. 7 FORMAT OF RECORDS .............................................................................................. 8 2
History of releases
1
RELEASE
DATE
ISSUES
STATUS1
V0-0-1
16/05/2015
First draft CR 494
Draft
V0-0-2
15/07/2015
Second draft CR 494
Draft
V0-0-3
30/12/2015
CR 589 Non-Editorial changes to the Flat File solution for reports at
EoD
Draft
V0-0-4
29/04/2016
CR 549 Statement of Transactions and Statement of Settled IntraPosition Movements reporting for Partially Settled transactions to be
made SMPG compliant
Draft
Status value : Draft, Open, Final, Dismiss
3
Introduction
Context
The following critical EoD reports may be generated in full and/or delta versions as flat files if opted by
CSDs, following a like-for-like approach to the report content of the already available XML versions:
 semt.002 - Statement of Holdings
 semt.016 - Statement of Settled Intra-position Movements
 semt.017 - Statement of Transactions
 semt.018 - Statement of Pending Instructions
 semt.034 - Statement of Pending Intra-position Movements
All the reports will contain a signature only at DEP level and will be routed to a given Party Technical
Address previously determined and configured by T2S Service Desk.
Purpose
This document provides a description of the structure of the flat file for the semt.017 Statement of
Transactions sent by T2S to the CSDs.
File Technical Specification
The file has a simple XML format (in order to allow for the network signature). All records are included
into a single “store and forward” message conveyed by the VAN provider. No business signature is
needed.
Within the message, the whole file is embedded in a single XML tag (<File> </File>).
Between these tags the file has fixed-length records, with a header and a footer. This header and
footer are the ones specified within the flat file specifications below, no business header is foreseen.
For delta reports where no activity has occurred the file will be empty between the header and the
footer.
Identification and Routing
T2S triggers the generation of flat file reports based on a business event, e.g. End of Day. All flat file
reports are pushed in A2A mode and compressed when they exceed the minimum size of 2KB, since
compression for these reports is mandatory.
4
All information about the necessary attributes in each named category is stored as static data in T2S
and influences the generation of the report. The privilege to configure these static data or subscribe to
a certain report is granted solely to the T2S Operator.
Each flat file report type provides information on the default data scope of the concerned party (i.e.
CSD). The data scope is indicated by the party for which it is configured and is limited to CSDs, i.e. a
Statement of Transactions reports on all Securities Accounts of the indicated party.
Flat file reports can only be configured at a system entity level, i.e. reports providing the CSD with
information relating to all its CSD participants. The concerned party has to be specified, when the flat
file report is configured for the first time.
A party configured to receive flat file reports cannot receive the equivalent reports through other
channels. This does not, however, prevent CSD participants from receiving those reports through such
channels, even if their CSD has opted for the flat file.
Structure
XML Schema for the Request
The following is the XML schema used to embed the file into a “store and forward” message:
<?xml version="1.0" ?>
<xs:schema xmlns="urn:T2S:StatementOfTransactionsFlatFile"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:T2S: StatementOfTransactionsFlatFile"
elementFormDefault="qualified">
<xs:simpleType name="RestrictedFileType">
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
<xs:element name="File" type="File"/>
<xs:complexType name="File">
<xs:simpleContent>
<xs:extension base="RestrictedFileType">
<xs:attribute name="fileId" type="xs:string" default="" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
5
Example of XML Request
<?xml version="1.0" encoding="UTF-8"?>
<File fileId = “T2Ssemt017FlatFile20150630” xmlns="urn:T2S:
StatementOfTransactionsFlatFile">Header
Record1
Record2
…
Recordn
Footer
</File>
Encoding
The encoding of the flat file is UTF-8 with no Byte Order Mark (BOM).
Default Values
See Field Types.
ISO 15022 Interoperability
In order to ensure the interoperability to the ISO 15022 standard the character set of all fields is
restricted to the SWIFT X Character Set (see below).
Character Set
All characters belong to the SWIFT X Character Set. The character set is as follows:
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
/ - ? : ( ) . , ' + { }
CR LF Space
6
Format of Structured Files
Record Types
Record Type
Description
Multiplicity
Header
First row of the file, contains statement general information, common to all data
records.
1
Body
Data record, constitutes one instance of report information.
Many
Footer
Last row of the file. Acts as a trailer, marking the end of main body section.
1
XMLTag
XML element, used to tag the start and/or end of a data block.
1
Field Types
Field Type
Description
O
Optional
O*
Optional, with restrictions
M
Mandatory
Whenever an optional field is not present, the position will be filled with spaces (#x20).
Data Format Types
The report data values may appear in one of the formats described in the table below:
Data Type
Format
Description
DATE
YYYY-MM-DD
DATETIME
YYYY-MM-DD-hh.mm.ss.ssssss
Timestamp format
CHAR(n)
Filled with trailing blanks up to the
maximum length
Alphanumeric string with exactly n characters.
NUMERIC(p)
Filled with leading zeroes up to the
maximum length
Number with maximum p integer places and no
decimal places.
Pagination
Pagination will be provided as in the ISO reports, indicating a sequential number and whether the file
is the last one (Page Number, Last Page Indicator Number).
7
XMLTag
Field Name
1
Data Format
Description
Field Type
Row
Type
Length
Field Number
Format of Records
Additional Information
(original XML data type, values, rules, etc.)
CHAR(n)
60
"<File>"
M
May contain the optional attribute field to provide additional information
such as file reference assigned by the sender, up to 54 characters long
(this length though fixed is not definitive and may be subject to change
during the design process).
Values:
'H': for Header
Header
Header
1
Record Type
CHAR(n)
1
Identifies record as
Header, Body or Footer
M
Header
2
Page Number
NUMERIC(p)
5
Sequence number of the
concerned message
within the set of divided
messages recurring to
pagination
M
Header
3
Last Page Indicator
CHAR(n)
5
Indicator for last message
within the set of divided
messages recurring to
pagination
M
Values:
True (meaning 'Yes, it is the last message')
False (meaning 'No, it is not the last message')
Header
4
Statement Identification
CHAR(n)
16
Reference common to all
pages of a statement.
M
Header
5
Statement Period From
DATETIME
26
Statement period start
date and time.
M
Header
6
Statement Period To
DATETIME
26
Statement period end
date and time.
M
Built like this:
- CSD (4 characters)
- Report type (4 characters)
- Report mode (1 character)
- BD (yymmdd, 6 characters)
- Frequency (1 character)
Header
7
Statement Frequency
CHAR(n)
4
Frequency of the
statement.
M
Values are extracted from the Attribute domain depending on the
configuration performed by the T2S Operator; Proposed values:
DAIL: Daily
WEEK: Weekly
MONT: Monthly
Header
8
Statement Update Type
CHAR(n)
4
Indicates whether the
statement is complete or
contains changes only.
M
Values:
COMP: Complete - Statement is complete.
DELT: Delta - Statement contains changes only.
Header
9
Statement Basis
CHAR(n)
4
Type of balance on which
the statement is prepared
M
Values:
SETT: Settled - The statement is based on settled date
positions to the knowledge of the sender
at the time of the statement preparation.
Header
10
Statement Activity Indicator
CHAR(n)
5
Indicates whether there is
activity or information
update reported in the
statement.
M
Values:
True (meaning 'Yes')
False (meaning 'No')
Header
11
Sub Account indicator
CHAR(n)
5
Indicates whether the
statement reports
holdings at
subsafekeeping account
level.
M
Values:
True (meaning 'Yes')
False (meaning 'No') – default value
Header
12
LF
CHAR(n)
1
Fixed Value: LF
M
LF = Line Feed (x'0A')
Body
1
Record Type
CHAR(n)
1
Identifies record as
Header, Body or Footer
M
Values:
'B': for Body
Body
2
Account Owner BIC
CHAR(n)
11
Primary BIC of the T2S
party owning the
securities account.(Party
code)
O
Body
9
Body
3
Safekeeping Account
CHAR(n)
35
Securities account
number of the T2S party
M
Body
4
ISIN
CHAR(n)
12
Securities Code
M
Body
5
Account Owner Transaction
Identification
CHAR(n)
16
Unambiguous
identification of the
transaction as known by
the account owner (or the
instructing party
managing the account)
M
Reference assigned by the Account Owner if any, otherwise NONREF
Body
6
Account Servicer Transaction CHAR(n)
Identification
16
Unambiguous
identification of the
transaction as known by
the account servicer.
O
The field is optional, depending on the information contained in the
instruction
Body
7
Market Infrastructure
Transaction Identification
CHAR(n)
16
Identification of a
transaction assigned by a
market infrastructure
other than a central
securities depository, for
example, Target2Securities.
M
Body
8
Processor Transaction
Identification
CHAR(n)
16
Identification of the
transaction assigned by
the processor of the
instruction other than the
account owner the
account servicer and the
market infrastructure.
O
The field is optional, depending on the information contained in the
instruction
Body
9
Pool Identification
CHAR(n)
16
Collective reference
identifying a set of
messages.
O
The field is optional, depending on the information contained in the
instruction
Body
10
Common Identification
CHAR(n)
16
Unique reference agreed
upon by the two trade
counterparties to identify
the trade.
O
The field is optional, depending on the information contained in the
instruction
Body
11
Corporate Action Event
Identification
CHAR(n)
16
Identification assigned by
the account servicer to
unambiguously identify a
corporate action event.
O
The field is optional, depending on the information contained in the
instruction
10
Body
12
Transaction Activity Code
CHAR(n)
4
Specifies the type of
activity to which this
instruction relates.
M
Body
13
ISO Transaction Code
CHAR(n)
4
Choice of type for the
transaction reported.
Identifies the type of
securities transaction, as
an ISO 20022 code.
O
Body
14
Securities Movement Type
CHAR(n)
4
Specifies if the movement
on a securities account
results from a deliver or a
receive instruction.
M
Values
DELI: Delivery - Financial instruments will be debited
from the safekeeping account.
RECE: Receive - Financial instruments will be credited to
the safekeeping account.
Body
15
Payment
CHAR(n)
4
Specifies how the
transaction is to be
settled, for example,
against payment.
M
Values:
APMT: AgainstPaymentSettlement - Settlement of the financial instrument
and cash takes place in a delivery versus payment (DVP) environment, ie,
through an International Central Securities Depository (ICSD) or Central
Securities Depository (CSD).
FREE: SeparateSettlement - Settlement of the financial instrument and
cash is separate.
Body
16
Settlement Transaction Code
CHAR(n)
4
Parameters applied to the
settlement of a security
transfer:
- Conditions under which
the order/trade is to be
settled.
O
NOMC: enables the counterparties in a transaction to opt-out from any CAs
transaction management arrangements
CHAR(n)
4
Parameters applied to the O
settlement of a security
transfer:
- Specifies whether partial
settlement is allowed.
NOMC
Body
17
Partial Settlement Indicator
Values:
SETT: SettlementandClearingActivity - Transaction always relates to
settlement and clearing activity.
Values
NPAR: PartialNotAllowed - Partial settlement is not allowed.
PARC: PartialSettlementCashThresholdAllowed - Partial settlement is
allowed but must satisfy a cash value minimum (value defined in static
data).
PARQ: PartialSettlementQuantityThresholdAllowed - Partial settlement is
allowed but must satisfy a minimum quantity of securities (quantity defined
in static data).
PART: PartialAllowed - Partial settlement is allowed.
11
Body
18
Posting Quantity integer part
NUMERIC(p)
14
Quantity of financial
instrument (to be) posted
to the safekeeping
account. Expressed as
units or face amount
M
The posting quantity will be the quantity settled during the business day
which the information contained in the report refers to.
Body
19
Number of decimals for
Posting Quantity
NUMERIC(p)
2
Quantity of financial
instrument (to be) posted
to the safekeeping
account. Expressed as
units or face amount
M
The posting quantity will be the quantity settled during the business day
which the information contained in the report refers to.
Body
20
Posting Amount Currency
CHAR(n)
3
Currency of the amount of O*
money that is to be/was
posted to the account:
* If Posting Amount is present, both Currency and Credit/Debit Indicator
must be present.
(active or historic
currency code)
Body
21
Posting Amount integer part
NUMERIC(p)
14
Cash entry (amount)
O
The posting amount will be the amount settled during the business day
which the information contained in the report refers to.
Body
22
Number of decimals for
Posting Amount
NUMERIC(p)
2
Number of decimals for
the cash entry (amount)
O
The posting amount will be the amount settled during the business day
which the information contained in the report refers to.
Body
23
Credit/Debit Indicator
CHAR(n)
4
Indicates whether an
O*
entry is a credit or a debit.
Values
CRDT: Credit - Operation is an increase.
DBIT: Debit - Operation is a decrease.
*: if Posting Amount is present, both Currency and Credit/Debit Indicator
must be present.
Body
24
Trade Date
DATE
10
Specifies the date on
which the trade was
executed.
O
Body
25
Effective Settlement Date
DATETIME
26
Specifies the date at
which a transaction is
completed and cleared,
that is, payment is
effected and securities
are delivered.
M
12
Body
26
Intended Settlement Date
DATE
10
Specifies the date on
O
which the securities are to
be delivered or received.
Body
27
Delivering Depository BIC
CHAR(n)
11
First party in the
settlement chain of
delivering settlement
parties
O
Body
28
Delivering Party 1 BIC
CHAR(n)
11
BIC of the party that, in a
settlement chain interacts
with the depository
O
Body
29
Delivering Party 1
Safekeeping Account
CHAR(n)
35
Unambiguous
identification for the
account (to or from which
a securities entry is
made) between the
account owner and the
account servicer.
O
Body
30
Delivering Party 1 Processing CHAR(n)
Identification
16
Specifies the reference
meaningful to the T2S
party that delivers the
settlement quantity
O
Body
31
Delivering Party 2 BIC
CHAR(n)
11
Party that, in a settlement
chain interacts with the
party 1
O*
*: if Party2 exists then one of AnyBIC, ProprietaryIdentification or
NameAndAddress must exist.
Body
32
Delivering Party 2 Proprietary CHAR(n)
Identification
34
Party that, in a settlement
chain interacts with the
party 1:
O*
*: if Party2 exists then one of AnyBIC, ProprietaryIdentification or
NameAndAddress must exist.
O*
*: If Proprietary Identification is present, then Issuer is mandatory
-Proprietary information,
often a code, issued by
the data source scheme
issuer.
Body
33
Delivering Party 2 Issuer
CHAR(n)
4
Entity that assigns the
identification.
13
Body
34
Delivering Party 2 Scheme
Name
CHAR(n)
4
Short textual description
of the scheme.
O
Body
35
Delivering Party 2 Name and
Address
CHAR(n)
140
Party that, in a settlement
chain interacts with the
party 1:
- Entity that assigns the
identification.
O*
Body
36
Receiving Depository BIC
CHAR(n)
11
First party in the
settlement chain of
receiving settlement
parties
O
Body
37
Receiving Party 1 BIC
CHAR(n)
11
BIC of the party that, in a
settlement chain interacts
with the depository
O
Body
38
Receiving Party 1
Safekeeping Account
CHAR(n)
35
Unambiguous
identification for the
account (to or from which
a securities entry is
made) between the
account owner and the
account servicer.
O
Body
39
Receiving Party 1 Processing CHAR(n)
Identification
16
Specifies the reference
meaningful to the T2S
party that receives the
settlement quantity
O
Body
40
Receiving Party 2 BIC
CHAR(n)
11
Party that, in a settlement
chain interacts with the
party 1
O*
*: if Party2 exists then one of AnyBIC, ProprietaryIdentification or
NameAndAddress must exist.
Body
41
Receiving Party 2 Proprietary
Identification
CHAR(n)
34
Party that, in a settlement
chain interacts with the
party 1:
O*
*: if Party2 exists then one of AnyBIC, ProprietaryIdentification or
NameAndAddress must exist.
O*
*:If Proprietary Identification is present, then Issuer is mandatory
*: if Party2 exists then one of AnyBIC, ProprietaryIdentification or
NameAndAddress must exist. Within ProprietaryIdentification, Issuer is
mandatory.
-Proprietary information,
often a code, issued by
the data source scheme
issuer.
Body
42
Receiving Party 2 Issuer
CHAR(n)
4
Entity that assigns the
identification.
14
Body
43
Receiving Party 2 Scheme
Name
CHAR(n)
4
Short textual description
of the scheme.
O
Body
44
Receiving Party 2 Name and
Address
CHAR(n)
140
Party that, in a settlement
chain interacts with the
party 1:
- Entity that assigns the
identification.
O*
45
LF
CHAR(n)
1
Fixed Value: LF
M
LF = Line Feed (x'0A')
Footer
1
RecordType
CHAR(n)
1
Identifies record as
Header, Body or Footer
M
Values:
'F': for Footer
Footer
2
NumberOfRecords
NUMERIC(p)
18
Total number of data
records in the file.
M
Number: integer representation, 18 digits long.
Footer
3
LF
CHAR(n)
1
Fixed Value: LF
M
LF = Line Feed (x'0A')
XMLTag
1
CHAR(n)
7
"</File>"
M
Body
*: if Party2 exists then one of AnyBIC, ProprietaryIdentification or
NameAndAddress must exist. Within ProprietaryIdentification, Issuer is
mandatory.2
Footer
2
Parties 3 to 5 are not present in order to optimize the size of the report. Confirmed by the users.
15