# Security-Based Swap Data Technical

> Briefs, arguments, decisions, and more.

URL: https://www.frixlaw.com/law-library/documents/agency%3Asec%3A1408aa8b33089262

## Record

- **Collection:** Agency decision
- **Document type:** Agency decision

## Text

DECEMBER 11, 2015

Security-Based Swap Data Technical
Specification (DRAFT)
De ce mber 1 1, 2015
This draft Security-Based Swap Data Technical Specification is being posted for public review
before Commission approval of potential regulatory changes. Commission staff encourages the
public to participate in the public review of this draft Technical Specification, which provides the
technical specifications that security-based swap data repositories will use to provide the
Commission with direct electronic access to data that they store. The availability for public
comment of this draft Technical Specification does not indicate Commission approval of any
potential regulatory changes reflected in this draft Technical Specification. Please provide
comments on the draft Security-Based Swap Data Technical Specification via email to
StructuredData@sec.gov and include “Draft Security-Based Swap Data Technical Specification”
in the “General Subject Matter” section no later than February 22, 2016.
1

2

Introduction ..................................................................................................................... 2
1.1

Goal .......................................................................................................................... 2

1.2

General Approach to the Common Data Model and the Schemas................................. 2

Common data model ........................................................................................................ 3
2.1

Security-Based Swap Data Reports............................................................................. 3

2.2

Definition Table Columns .......................................................................................... 3

2.3

Definition Tables ....................................................................................................... 4

2.3.1

Primary trade information report ......................................................................... 4

2.3.2

Secondary trade information report...................................................................... 5

2.3.3

Asset (Instrument) .............................................................................................. 6

2.3.4

Issuer (of an Instrument) ..................................................................................... 6

2.3.5

Index .................................................................................................................. 6

2.3.6

Frequency........................................................................................................... 7

2.3.7

Fixed Rate Payment Terms ................................................................................. 7

2.3.8

Floating Rate Payment Terms ............................................................................. 7

2.3.9

Party (per SDR) .................................................................................................. 7

2.3.10

Transaction Flag (Examples) ............................................................................... 7

2.3.11

Terminations ...................................................................................................... 8

2.3.12

Amendment ........................................................................................................ 8

2.3.13

Payment Stream.................................................................................................. 9

1

DECEMBER 11, 2015

3

4

5

2.3.14

Settlement Terms ................................................................................................ 9

2.3.15

Agreement Data.................................................................................................. 9

FIXML Schemas.............................................................................................................10
3.1

FIXML Type Restrictions .........................................................................................10

3.2

FIXML Primary Information Report..........................................................................12

3.3

FIXML Regulatory Information Report .....................................................................15

3.4

Additional FIXML Validation Criteria.......................................................................19

FpML Schemas ...............................................................................................................19
4.1

FpML Primary Trade Information Report ..................................................................20

4.2

FpML Regulatory Trade Information Report..............................................................22

4.3

Additional FpML Validation Criteria.........................................................................26

References......................................................................................................................26

1 INTRODUCTION
1.1 Goal
This document provides the technical specification for how a security-based swap data repository
(“SDR”) must provide the Commission with direct electronic access under Exchange Act Rule
13n-4(b)(5). 1
This Technical Specification describes the two schemas from which an SDR must choose when
making security-based swap data available to the Commission. The specification defines syntax
constraints on individual data elements, their contents, and the content of arrangements of
elements that describe an individual security-based swap.
This Technical Specification has been created for the limited purpose of providing a technical
audience with the specifications for conforming security-based swap data to the Commission’s
FIXML and FpML schemas. This specification does not provide interpretative guidance for the
SDR Rules 2 or Regulation SBSR. 3

1.2 General Approach to the Common Data Model and the Schemas
When an SDR makes security-based swap data available to the Commission, the Commission
will test the security-based swap data for validity against formatting constraints, and only if the
data adheres to those formatting constraints will the SDR be considered to have provided the

1

17 CFR 240.13n-4(b)(5). See also 17 CFR 240.13n-4(a)(5) (defining “direct electronic access”).

2

Securities Exchange Act Release No. 74246 (February 11, 2015), 80 FR 14437 (March 19, 2015)
(“SDR Rules”).

3

Securities Exchange Act Release No. 74244 (February 11, 2015), 80 FR 14563 (March 19, 2015)
(“Regulation SBSR”).

2

DECEMBER 11, 2015
Commission with direct electronic access. SDRs are encouraged to use the schemas to check the
validity of the security-based swap data before making the data available to the Commission.
The common data model allows an SDR to use multiple identifier sources for a Unique
Identification Code (“UIC”), as defined by Rule 900(qq). 4 Where a UIC is required but the
Commission does not mandate a specific code list or code issuing authority, the common data
model specifies a default identifier source, and the SDR is free to choose a standard identifier
source to be used consistently across otherwise identical data. For example, the common data
model identifies GLEIF as the default identifier source for the parties to a swap, but an SDR may
use other entity identifiers so long as their source is given and the identifiers are used
consistently.
The common data model allows an SDR to include the additional “flags” that are dependent on
SDR-specific policies and procedures. The schemas limit the format of these flags but not their
names or content.
The common data model allows an SDR to provide transaction information of an open-ended or
evolving nature, such as the details of non-standard terms or payment streams, subject to schema
validation as detailed in this specification or as detailed by the underlying standard format.

2 COMMON DATA MODEL
2.1 Security-Based Swap Data Reports
The data describing a new security-based swap transaction or a life cycle event such as an
amendment or termination is contained in a distinct “report.”
Primary Trade Information (“PTI”) reports contain only the data about a single transaction as
required by Rule 901(c) 5 and the life cycle events in Rule 901(e). 6
Regulatory Trade Information (“RTI”) reports contain all of the information in a PTI along with
the Secondary Trade Information (“STI”) required by Rule 901(d). 7 The content of an RTI is a
superset of that in a PTI.
Acceptance for Clearing reports are produced by clearing services, not the SDR, and are not
detailed in this specification.

2.2 Definition Table Columns
A concept definition table shows:
Ref denotes a clause within Rule 901. 8

4

17 CFR 242.900(qq).

5

17 CFR 242.901(c).

6

17 CFR 242.901(e).

7

17 CFR 242.901(d).

8

17 CFR 242.901.

3

DECEMBER 11, 2015
Concept shows the formal name of the concept, which is then abbreviated in some fashion when
it appears in FIXML or FpML. For example, “Trade Identifier” is a concept, while “trdID” and
“tradeId” would be legitimate abbreviations in FIXML and FpML, respectively. In some cases
where the meaning of the term is defined precisely in Regulation SBSR, that defining phrase is
used instead of a name.
Data type: Simple concepts may be described as text, numbers, dates, etc., but in a complex
model, it is useful to define a data type that may itself be composed of other elements. In this
Technical Specification, the data type may be the subject of yet another element definition table.
Two asterisks (**) indicate a reference to a different table.

2.3 Definition Tables
2.3.1 Primary trade information report
Ref.
(c)(1)
(c)(1)(i)
(c)(1)(i)
(c)(1)(i)
(c)(1)(i)
(c)(1)(ii)

Concept
Product ID
Asset Class
Underlying Reference Asset(s)
Underlying Reference Issuer(s)
Underlying Reference Index
Effective Date

(c)(1)(iii)
(c)(1)(iv)
(c)(1)(iv)
(c)(1)(iv)
(c)(1)(iv)
(c)(1)(v)
(c)(2)

Scheduled Termination Date
Terms of any standardized fixed rate payments
Frequency of any fixed rate payments
Terms of any standardized floating rate payments
Frequency of any floating rate payments
Custom Swap Flag
Execution Date Time (the date and time, to the
second, of execution, expressed using
Coordinated Universal Time (UTC))
The price
The currency in which the price is expressed
The amount(s) of any up-front payments
The currenc(ies) of any up-front payments
The notional amount(s)
The currenc(ies) in which the notional amount(s)
is expressed
Inter-Dealer Transaction Flag
Intention to Clear Flag

(c)(3)
(c)(3)
(c)(3)
(c)(3)
(c)(4)
(c)(4)
(c)(5)
(c)(6)

9

Data Type
Text
Text
** Asset
** Issuer
** Index
YYYY-MM-DDZ
(ISO 8601, UTC)
YYYY-MM-DDZ
** Fixed Rate Payment Terms
** Frequency
** Floating Rate Payment Terms
** Frequency
Boolean
YYYY-MM-DDTHH:MM:SSZ
(ISO 8601, UTC)
Positive Number
ISO 4217 Code
Positive Number 9
ISO 4217 Code
Positive Number
ISO 4217 Code
Boolean
Boolean

Primary trade information includes no identification of payer or receiver parties, so the sign of the number
is moot.

4

DECEMBER 11, 2015
(c)(7)

(f)
(g)
(e)(1)(i)

(e)(1)(i)
(e)(1)(i)
(e)(2)

If applicable, any flags pertaining to the
transaction that are specified in the policies and
procedures of the registered security-based swap
data repository
Time stamp, to the second, its receipt of any
information submitted to the SDR
A transaction ID to each security-based swap
A life cycle event, and any adjustment due to a
life cycle event, that results in a change to
information previously reported
Amendment
Termination (Allocation, Assignment, Novation)
All reports of life cycle events… shall include
the transaction ID of the original transaction.

** Transaction Flag (varies by
SDR)

YYYY-MM-DDTHH:MM:SSZ
(ISO 8601, UTC)
SDR (or third party) Defined
Sequence Number

** Amendment
** Terminations
SDR (or third party) Defined

2.3.2 Secondary trade information report
Ref.
(c)

Concept
(See above)

(d)(1)
(d)(1)
(d)(1)
(d)(1)

(d)(4)
(d)(4)

The counterparty ID [on the reporting side]
The execution agent ID [on the reporting side], as applicable
The counterparty ID [on the non-reporting side]
The execution agent ID [on the non-reporting side], as
applicable
[As applicable] the branch ID of the direct counterparty on
the reporting side
[As applicable] the broker ID of the direct counterparty on
the reporting side
[As applicable] the execution agent ID of the direct
counterparty on the reporting side
[As applicable] the trader ID of the direct counterparty on
the reporting side
[As applicable] the trading desk ID of the direct
counterparty on the reporting side
the terms of any fixed or floating rate payments, or
otherwise customized or non-standard payment streams
the frequency of any fixed or floating rate payments, or
otherwise customized or non-standard payment streams
the contingencies of any fixed or floating rate payments, or
otherwise customized or non-standard payment streams
title of any master agreement
date of any master agreement

(d)(4)

title of any collateral agreement

(d)(2)
(d)(2)
(d)(2)
(d)(2)
(d)(2)
(d)(3)
(d)(3)
(d)(3)

5

Data Type
** Primary trade
information report
Party
Party
Party
Party
Text (SDR Defined)
Text (SDR Defined)
Party
Text (SDR Defined)
Text (SDR Defined)
** Payment Stream
** Payment Stream
** Payment Stream
Text
YYYY-MM-DDZ
(ISO 8601, UTC)
Text

DECEMBER 11, 2015
Ref.
(d)(4)

Concept
date of any collateral agreement

(d)(4)
(d)(4)

title of any margin agreement
date of any margin agreement

(d)(4)
(d)(4)

title(s) of any other agreement(s)
date(s) of any other agreement(s)

(d)(5)

any additional data elements included in the agreement
between the counterparties that are necessary for a person to
determine the market value of the transaction
(d)(6) the name of the clearing agency to which the security-based
swap will be submitted for clearing
(d)(7) whether they have invoked the exception in Section 3C(g)
of the Exchange Act (15 U.S.C. 78c-3(g))
(d)(8) a description of the settlement terms
(d)(8) whether the security-based swap is cash-settled or
physically settled, and the method for determining the
settlement value
(d)(9) The platform ID, if applicable
(d)(10) The transaction ID of an allocated security-based swap

(d)(10) The transaction ID of a terminated security-based swap
(d)(10) The transaction ID of an assigned security-based swap

Data Type
YYYY-MM-DDZ
(ISO 8601, UTC)
Text
YYYY-MM-DDZ
(ISO 8601, UTC)
Text
YYYY-MM-DDZ
(ISO 8601, UTC)
** Agreement Data

Text
Boolean
** Settlement Terms
** Settlement Terms

SDR Defined
SDR Defined Unique
Transaction Identifier
(UTI)
SDR Defined UTI
SDR Defined UTI

2.3.3 Asset (Instrument)
Ref.
(c)(1)(i)
(c)(1)(i)

Concept
Asset Identifier
Asset Identifier Authority (Scheme)

Data Type
Text
Text

2.3.4 Issuer (of an Instrument)
Ref.
(c)(1)(i)
(c)(1)(i)

Concept
Issuer Identifier
Issuer Identifier Authority (Scheme)

Data Type
Text
Text

Concept
Index Identifier
Index Identifier Authority (Scheme)

Data Type
Text
Text

2.3.5 Index
Ref.
(c)(1)(i)
(c)(1)(i)

6

DECEMBER 11, 2015

2.3.6 Frequency
Ref.
(c)(1)(iv)

Concept
Period

(c)(1)(iv)
(c)(1)(iv)

Period Multiplier
First Period Start Date

Data Type
ISO 8601 Duration Designator:
P, Y, M, W, or D
Positive Number 10
ISO 8601 UTC

2.3.7 Fixed Rate Payment Terms
Ref.
(c)(1)(iv)
(c)(1)(iv)
(c)(1)(iv)

Concept
Fixed Rate
Base Currency
Base Amount 11

Data Type
Number
ISO 4217
Positive Number

2.3.8 Floating Rate Payment Terms
Ref.
(c)(1)(iv)
(c)(1)(iv)
(c)(1)(iv)
(c)(1)(iv)
(c)(1)(iv)
(c)(1)(iv)

Concept
Floating Rate Index
Spread(s)
Reset Dates
Index Tenor
Base Currency
Base Amount 12

Data Type
** Index
Number(s)
** Frequency
** Frequency
ISO 4217
Positive Number

2.3.9 Party (per SDR)
The Party ID consists of an authority (source or scheme) and an identifier issued by that
authority. When unspecified, the Authority defaults to ISO 17442 (Legal Entity Identifier).
Ref.
(d)(2)
(d)(2)

Concept
Party ID
Party ID Authority (Scheme)

Data Type
Text
Text

2.3.10 Transaction Flag (Examples)
Transaction flags are defined by SDRs. Two non-normative examples are shown here.
Ref.
(c)(7)
(c)(7)

Concept
Collateralization Type
Intent to Allocate

Data Type
Text
Boolean

10

For example, a quarterly payment schedule is represented as Period=M and Multiplier=3.

11

The base currency and amount appear only if the principal is different from the notional.

12

The base currency and amount appear only if the principal is different from the notional.

7

DECEMBER 11, 2015

2.3.11 Terminations
In addition to a simple termination of a security-based swap, reportable events such as
allocations, assignments, and novations also result in a termination and one or more new
reportable events, affecting both the primary and the secondary trade information, and both of
which must be reported by the SDR as transactions that refer back to the original transaction. All
RTI is reported for any kind of termination.
2.3.11.1 Termination - Additional Primary Information
Ref.
(e)(1)(ii)

Concept
Original Transaction ID

Data Type
SDR (or third party) Defined

A termination resulting from allocation of a trade requires the RTI along with the allocated
notionals and fees.
2.3.11.2 Termination - Additional Primary Information for an Allocation
Ref.
(e)(1)(i)
(e)(1)(i)
(e)(1)(i)
(e)(1)(i)

Concept
Allocation Fee Currenc(ies)
Allocation Fee Amount(s)
Allocation Notional Currenc(ies)
Allocation Notional Amount(s)

Data Type
ISO 4217
Positive Number
ISO 4217
Positive Number

2.3.11.3 Termination - Additional Secondary Information for an Allocation
Ref.
Ref.
(e)(1)(i)

Concept
Concept
Allocation Part(ies)

Data Type
Data Type
Party

2.3.12 Amendment
All PTI is reported for each reportable event resulting from amendment of a previously reported
transaction even if the amendment affected only the STI (for example, an amendment to the
Agreement data, which is not in the PTI).
Amendments include: a change in the cash flows originally reported; for a security-based swap
that is not a clearing transaction, any change to the title or date of any master agreement,
collateral agreement, margin agreement, or any other agreement incorporated by reference into
the security-based swap contract; or a corporate action affecting a security or securities on which
the security-based swap is based (e.g., a merger, dividend, stock split, or bankruptcy).
2.3.12.1 Amendment - Additional Primary Information
Ref.
(e)(1)(ii)

Concept
Original Transaction ID

Data Type
SDR (or third party) Defined

8

DECEMBER 11, 2015

2.3.12.2 Amendment - Additional Secondary Information
Ref.
(e)(1)(ii)

Concept
Primary Trade Information

Data Type
** Amendment - Primary

2.3.13 Payment Stream
Ref.
(d)(3)
(d)(3)
(d)(3)
(d)(3)
(d)(3)
(d)(3)
(d)(3)
(d)(3)
(d)(3)
(d)(3)
(d)(3)
(d)(3)
(d)(3)

Concept
Initial Payment Payer
Initial Payment Receiver
Initial Payment Currency
Initial Payment Amount
Initial Payment Points
Periodic Payment Payer
Periodic Payment Receiver
Payment Frequency
First Payment Date
Fixed Periodic Payment Currency
Fixed Periodic Payment Amount
Fixed Rate Payment Terms
Floating Rate Payment Terms

Data Type
Party
Party
ISO 4217
Number
Number
Party
Party
** Frequency
ISO 8601 YYYY-MM-DDZ
ISO 4217
Number
** Fixed Rate Payment Terms
** Floating Rate Payment Terms

2.3.14 Settlement Terms
Ref.
(d)(8)
(d)(8)
(d)(8)
(d)(8)
(d)(8)
(d)(8)
(d)(8)
(d)(8)
(d)(8)
(d)(8)
(d)(8)
(d)(8)
(d)(8)
(d)(8)

Concept
Cash Settlement Date
Cash Settlement Time
Cash Settlement Quotation Method
Cash Settlement Quotation Currency
Cash Settlement Quotation Amount
Cash Settlement Business Days
Cash Settlement Fixed Recovery Currency
Cash Settlement Fixed Recovery Amount
Cash Settlement Recovery Factor
Cash Settlement Accrued Interest
Cash Settlement Valuation Method
Physical Settlement Business Days
Physical Settlement Obligations
Physical Settlement Escrow

Data Type
ISO 8601 YYYY-MM-DDZ
ISO 8601 HH:MM:SSZ
Text
ISO 4217
Nonnegative Number
Nonnegative Number
ISO 4217
Number
Number
Boolean
Text
Number
Any
Boolean

2.3.15 Agreement Data
Rule 901(d)(5) of Regulation SBSR requires the STI to include any additional data elements
included in the agreement between the counterparties that are necessary for a person to determine
9

DECEMBER 11, 2015
the market value of the transaction. This may involve additional concepts that could be
considered part of the product description, payment stream, settlement terms, or any other data
item in the STI.
Ref.
(d)(5)

Concept
Additional Terms

Data Type
Any (per SDR)

3 FIXML SCHEMAS
The schemas in this document are derived from FIXML 5.0 SP2 EP 193. Final schemas will be
derived from a FIXML final recommendation, not a working draft. When a schema is presented
here in its entirety, note that the xsd:documentation element for each redefinition does not repeat
the xsd:documentation content of the original element. It only describes the way in which the
original data type is being restricted, and is shown in a box only to facilitate review. Concepts in
the common data model that are implemented in the base FIXML schemas without change are
not duplicated in this document.

3.1 FIXML Type Restrictions
Schema sec-sbsr-tradecapture-types-5-0-SP2.xsd

As restricted, timestamps are to the second, 901(c)(2).

10

DECEMBER 11, 2015

As restricted, timestamps are to the second in time zone UTC, 901(c)(2).

Flag indicating whether the End-user exception applies, 901(d)(7).

No exception
End-user exception

Secondary Trade Information includes RT ("Report of data relating to a regulated
transaction including price and volume that is to be disseminated publically.) and PET
("Report to regulators of the full terms of a regulated transaction included in the
legal confirmation.") for trade and post-trade events.

Combination of RT and PET
Post-trade event
Post trade event RT reportable

Trade ID and Src attributes are required, Evnt and Typ optional; other attributes
prohibited, 901(g).

11

DECEMBER 11, 2015

Party and Counterparty identifiers, 901(d)(1).

Parties are required to have an ID 901(d)(1) and branch, desk, broker and trader
identification 901(d)(2).

Default to Legal Entity Identifier (ISO 17442) LEI

3.2 FIXML Primary Information Report
Schema sec-sbsr-tradecapture-primary-5-0-SP2.xsd

12

DECEMBER 11, 2015
Based on the TradeCaptureReport in Volume 5 of the FIXML specification.

Required attributes: TrdID, TxnmyTyp, Ccy, TxnTm, RegRptTyp, ClrIntn; Fixed
attributes: QtyTyp; all other attributes prohibited.

Required and optional elements: RegTrdID, Instrmt, InstrmtExt, Pmt, Undly, TrdLeg,
TrdRegTS, Qty, RptSide, TrdRepIndicatorsGrp. All other elements prohibited.

Transaction ID, 901(g).

Sequence Number, 901(e)(1)(i).

Optional trade report message identifier

Asset Identifier Authority, 901(c)(1)(i)

13

DECEMBER 11, 2015

Quantity type 1 = Contracts.

The price, 901(c)(3).

The currency in which the price is expressed, 901(c)(3).

Cash settlement currency, 901(d)(8).

Optional decimal precision of the price, 901(c)(3).

Upfront price, 901(c)(3).

Percentage or currency used to express upfront price, 901(c)(3).

Execution date time, 901(c)(2).

14

DECEMBER 11, 2015

Cash settlement date, 901(d)(8).

Intention to Clear Flag, 901(c)(6).

Whether the parties have invoked the exception in Section 3C(g) of the Exchange Act
(15 U.S.C. 78c-3(g)).

3.3 FIXML Regulatory Information Report
Schema sec-sbsr-tradecapture-regulatory-5-0-SP2.xsd

Based on the TradeCaptureReport in Volume 5 of the FIXML specification. This element
is called "Nonpublic" to avoid ambiguity with the use of "Secondary" in many FIX
names.

Required attributes: TrdID, TxnmyTyp, Ccy, TxnTm, RegRptTyp, ClrIntn; Fixed
attributes: QtyTyp; all other attributes prohibited.

Required and optional elements: RegTrdID, Pty, Instrmt, InstrmtExt, FinDetls, Pmt,
Undly, TrdLeg, TrdRegTS, Qty, RptSide, TrdRepIndicatorsGrp. All other elements
prohibited.

Agreement titles and dates, 901(d)(4).

16

DECEMBER 11, 2015

Transaction ID, 901(g).

Sequence Number, 901(e)(1)(i).

Optional trade report message identifier.

Asset Identifier Authority, 901(c)(1)(i).

Quantity type 1 = Contracts

The price, 901(c)(3).

The currency in which the price is expressed, 901(c)(3).

Cash settlement currency, 901(d)(8).

17

DECEMBER 11, 2015

Optional decimal precision of the price, 901(c)(3).

Upfront price, 901(c)(3).

Percentage or currency used to express upfront price, 901(c)(3).

Execution date time, 901(c)(2).

Cash settlement date, 901(d)(8).

Intention to Clear Flag, 901(c)(6).

18

DECEMBER 11, 2015

Whether the parties have invoked the exception in Section 3C(g) of the Exchange Act
(15 U.S.C. 78c-3(g)).

3.4 Additional FIXML Validation Criteria
Ordinary XML Schema validation against the appropriate FIXML schema will signal errors such
as duplicate ID attributes, unbound IDREF attributes, along with all of the syntax definitions in
the security-based swap data schema derived from FIXML.

4 FPML SCHEMAS
The FpML schemas to implement the common data model are derived by XML Schema
Restriction from FpML. Restrictions are used to define acceptable values for XML elements or
attributes. In XML Schema 1.0, the XML Schema “redefine” construct allows restrictions on
data elements to use the same element names as in a base schema. XML Schema 1.1 deprecates
the redefine construct in favor of the XML Schema “override” construct, but for the present
purpose the effect is the same.
The schemas in this document are derived from FpML 5.9 WD 2. Final schemas will be derived
from an FpML final recommendation, not a working draft. When a schema is presented here in
its entirety, note that the xsd:documentation element for each redefinition does not repeat the
xsd:documentation content of the original element. It only describes the way in which the
original data type is being restricted, and is shown in a box only to facilitate review. Concepts in
the common data model that are implemented in the base FpML schemas without change are not
duplicated in this document.

19

DECEMBER 11, 2015

4.1 FpML Primary Trade Information Report
The PTI report redefines the data type PublicInformationReport in the FpML Transparency
View having target namespace URI http://www.fpml.org/FpML-5/transparency.
Schema sec-sbsr-transparency-5-9-1.xsd

A PublicExecutionReport must not have Correlation elements, elements related to
Valuation, must not have any Account related elements, and must either have no Party
information OR exactly two Party elements both of type Dealer.

A Date element must record the date as of UTC time zone.

20

DECEMBER 11, 2015

An ExecutionDateTime element must record the time in the UTC time zone, to the second
only.

An element of type ExecutionVenueType must use the default FpML scheme.

The RegulatorId must be a SEC CIK of 1 to 10 digits.

An element of type Party may only appear in Primary Trade Information if its
organization type is 'Dealer'.

21

DECEMBER 11, 2015

Primary trade information is restricted to exclude the optional elements relatedParty,
timestamps, intentToallocate, allocationStatus, clearingStatus,
collaterializationType, offMarketPrice, largeSizeTrade, executionType,
verificationMethod and confirmationMethod.

Element executionVenueType is required by the underlying type TradeInformation. Its
content may be left blank.

4.2 FpML Regulatory Trade Information Report
The RTI report redefines types in the FpML architecture Record Keeping View having target
namespace URI http://www.fpml.org/FpML-5/recordkeeping. The schema restricts the base
types IdentifiedDate , ExecutionDateTime , ExecutionVenueType , and RegulatorId in the same
way the PTI schema does.
Schema sec-sbsr-recordkeeping-5-9-1.xsd

22

DECEMBER 11, 2015

A Date element must record the date as of UTC time zone.

An ExecutionDateTime element must record the time in the UTC time zone, to the second
only.

An element of type ExecutionVenueType must use the default FpML scheme.

The RegulatorId must be a SEC CIK of 1 to 10 digits.

23

DECEMBER 11, 2015

PartyTradeInformation is restricted according to 901(d)(2) so that at least two
related business units and two related persons are present.

Party Id has default value

24

DECEMBER 11, 2015

PartyRole is restricted to be either ExecutionFacility or ClearingOrganization
supporting Rule 901(d)(2). The scheme is restricted to the FpML default party-role
scheme.

BusinessUnitRole is restricted to be either RegisteredBranch or TradingDesk supporting
Rule 901(d)(2). The scheme is restricted to the FpML default unit-role scheme.

PersonRole is restricted to be either Broker or Trader supporting Rule 901(d)(2).
scheme is restricted to the FpML default person-role scheme.

25

The

DECEMBER 11, 2015
BusinessUnit is required to have a businessUnitId, supporting Rule 901(d)(2).

4.3 Additional FpML Validation Criteria
Ordinary XML Schema validation against the appropriate security-based swap data schema will
signal errors such as duplicate ID attributes, unbound IDREF attributes, along with all of the
syntax definitions in the security-based swap data schema derived from FpML.
Also, for any element whose post-validation infoset includes one of the FpML coding scheme
attributes, validation warnings or errors will be signaled when the element content is not among
the values enumerated in that scheme.
Possible additional validation criteria include:
•
•

Warnings of unreferenced elements of type Party
Elements and attributes deprecated in FpML 5.9.

5 REFERENCES
FIXML 5.0 SP 2: www.fixtradingcommunity.org/pg/structure/tech-specs/fix-version/50-service-pack-2/
FpML 5.9 WD 2: www.fpml.org/spec/fpml-5-9-2-wd-2/
FpML Coding Schemes: www.fpml.org/spec/coding-scheme/
XML Schema: www.w3.org/XML/Schema

26

---

Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/agency%3Asec%3A1408aa8b33089262. Public record. Not legal advice.