February 22, 2016
Comments on the “DRAFT TECHNICAL SPECIFICATIONS FOR CERTAIN
SWAP DATA ELEMENTS” issued bythe U.S. Commodity Futures Trading Commission
Japanese Bankers Association
We, the Japanese Bankers Association (“JBA”), would like to express our gratitude forthis opportunity to comment on the “DRAFT TECHNICAL SPECIFICATIONS FOR
CERTAIN SWAP DATA ELEMENTS,” issued on December 22, 2015 by the U.S.
Commodity Futures Trading Commission (“CFTC”).
We respectfully expect that the following comments on questions will contribute to yourfurther discussion.
1．p.11, Question (1):
Are there challenges associated with identifying the Ultimate Parent and/or Ultimate
Guarantor of a swap counterparty? If so, how might those challenges be addressed?
(Out comment)
The CFTC should carefully consider adding data elements related to Ultimate Parent
and Ultimate Guarantor to swap data reporting because it would be extremely
difficult to accurately identify and manage such information on an ongoing basis andsuch inclusion would impose a considerable amount of burden on financial
institutions and their counterparties.
However, even if the CFTC still determined to add these data elements in thereporting of swap transactions, it is recommended, in terms of efficiency and accuracy,
to require counterparties, rather than swap dealers (i.e. reporting entity), to manage
and update such information given that counterparties themselves are managing andmaintaining such information. For example, regulators could directly obtain thesedata elements from LEI.

Even in such cases, the CFTC should exempt swap dealers from reporting obligationsof data elements related to Ultimate Parent and Ultimate Guarantor when theircounterparties are a non-US entity, as it is difficult and require undue burden toaccurately manage such data elements of counterparties of which accounting andlegal regimes (and LEI-related rules) are different.
2．p.12, Question (7):Please provide feedback on any aspect of the draft technical specifications for thedata elements presented below.
(Our comment)
We do not support the draft technical specifications for the Counterparty ID dataelement which designates only valid LEIs as an allowable value.
(Rationale)
If a swap dealer reports an LEI as a counterparty ID but the status of the LEI is“lapsed” because the counterparty has failed to update its LEI, the swap dealer’s swap
transaction report will not satisfy regulatory requirements. Swap counterparties
should be responsible for updating their own LEIs and it would be difficult for swap
dealers, a reporting entity, to control them. It is unreasonable if a reporting entity’sswap transaction report is declined by swap data repositories (“SDRs”) due to reasons
attributable to the counterparty and results in incompliance with the swap datareporting rules.
3．p.24, Question (36):
Please provide feedback on any aspect of the draft technical specifications for thedata elements presented below.
(Our comment)
Application of overall swap data reporting rules related to orders should be limited toswap execution facilities (“SEFs”) and designated contract markets (“DCMs”).
(Rationale)
Under off-facility transactions, orders are placed and received by means ofunstructured data, such as communications via telephone and voice. To report very
detailed information related to orders whenever entering into a transaction will
additionally necessitate data entry into the booking system upon transaction, which is2

extremely inefficient and may lead to frequent delays in reporting. For swap dealers
to comply with this reporting requirement, they will need to use SEFs or DCMs or
fulfill a similar function as SEFs by themselves. Given this, the coverage of the swap
data reporting obligations related to orders should be limited to SEFs and DCMs.
4．p.26, Question (41):
Please provide feedback on any aspect of the draft technical specifications for thedata elements presented below.
(Our comment)
As for package transactions, the current rule to report Unique Swap Identifiers ofcorresponding CFTC swap components are enough and should not require additional
data.
(Rationale)
As long as linkage information is identifiable, regulators should be able to analogize,
among other things, spread price information. Therefore, there is not much necessity
to report package trade prices and other data elements. Further, the data element of“Package Contains Non-CFTC Swap Components” lacks value as information
because with only Y/N values, this data element will not be able to identify
corresponding asset classes nor prices. Given this, it is difficult to find any benefits
that outweigh regulatory burdens arising from the reporting of this data element.
5．p.29, Question (43):
Please provide feedback on any aspect of the draft technical specifications for thedata elements presented below.
(Our comment)
The data elements related to clearing should be deleted.
(Rationale)
Sufficient information is being reported in other data elements to enable identificationof swaps subject to mandatory clearing. Therefore, regulators should be able toidentify whether a swap is subject to mandatory clearing without data elements
presented in relation to clearing. Adding less-important data elements may increase
the risk of reporting errors.

36．p.30, Question (44):
To represent that the reporting counterparties and the SDRs have confirmed data
accuracy, is there a methodology better than reporting the Data Accuracy
Confirmation by Counterparty data element?
(Our comment)
The data elements related to reconciliation should be deleted.
(Rationale)
Under Part 43.3 and 45.14, it is required to notify any identified errors tocounterparties but there is no specific requirement for confirming accuracy of all data.
Further, since this data element is deemed as an additional regulatory requirement,rather than a change to data elements, the CFTC should take the procedures foramendments to regulatory requirements.
7．p.30, Question (45):
Please provide feedback on any aspect of the draft technical specifications for thedata elements presented below.
(Our comment)
Even if all data elements related to reconciliation will not be deleted, at least the “Part43/45/46” data element should be deleted.
In addition, the reporting of timestamps is considered to be unnecessary. Further, theCFTC should allow reporting entities to report the data elements related toreconciliation on an entity-by-entity basis, instead of on a transaction-by-transaction
basis and also, should define reporting rules for the case where any dispute have been
received for some material terms.
(Rationale)
Sufficient information is being reported in other data elements to enable identificationof applicable parts. Therefore, regulators should be able to identify pursuant to whichparts the record is being submitted without the “Part 43/45/46” data element. Adding
less-important data elements may increase the risk of reporting errors.
In practice, reconciliation of portfolios is carried out at the entity level, and therefore,
it is impossible to identify a timestamp at the transaction level. Given this, only the4date of reconciliation is sufficient and practical. If the reporting of this data element isrequired at the transaction level, the reconciliation status of respective transactions
will be needed. However, the draft technical specifications for this data element do
not provide different reporting rules for the case where any disputes have been
received and for the case where no dispute has been received. As long as the reportingof only the date of reconciliation would suffice, there is not much significance inrequiring transaction-by-transaction reporting. Therefore, in this case, the reporting at
the entity level should be permitted.
8．p.34, Question (56):
Should Netting Set valuation, collateral and margin information be reported at thetransaction level or only at the aggregated portfolio level?
(Our comment)
The reporting at the aggregated portfolio level is preferable.
(Rationale)
The reporting at the aggregated portfolio level is preferable because, in practice,collateral is calculated and exchanged at the aggregated portfolio level, and not at thetransaction level.
9．p.41, Question (61):What are some of the challenges with the Event Types listed below? If so, pleaseprovide suggestions to address them.
(Our comment)
Some of Allowable Values in the Event Type should be integrated.
(Rationale)
Some Allowable Values, such as NOVATION (4 WAY), are difficult to capture fromthe perspective of individual industries. It is not therefore appropriate to require
reporting of such granular values at the industry level. Further, those values, which
are extremely difficult to distinguish automatically by systems, such asAMENDMENT and ERROR CORRECTION, would need to be covered by manual
operation. Introducing all of these granular allowable values in a short period of timeand concurrently may heighten the risk of reporting deficiencies caused byoperational errors and also could lead to data inconsistencies across industries. In this5

view, it is preferable to implement these Allowable Values in a phased manner andprovide a sufficient preparation period as well.
10．p.50, Question (73):
Are any of the Data Elements listed herein unclear? Do any Data elements require
greater standardization?
(Our comment)
The reporting requirements for margin information in relation to Package
Transactions, Business Day Convention, Leg NPV and Periodic Reporting should bedefined in detail and clarified.
(Rationale)
Given that some swap dealers are subject to not only the CFTC’s margin requirements
but also the margin requirements published by the prudential regulators, if differencesin wording of the terms exist between the these regulations, consistent definitions
should be applied in order to prevent confusion. Further, although the draft technicalspecifications state that a Standard Credit Support Annex (“SCSA”) should bereferenced for definitions of some terms, the use of a SCSA is not a common practiceand instead, a Credit Support Annex (“CSA) is generally adopted internationally(particularly outside the U.S.). Therefore, the terms should be defined in detail andclarified.
In fact, for those entities to which the prudential regulators’ margin requirements areapplied and which enter into a CSA only, detailed definitions of the reporting
requirements related to the margin rules are very difficult to understand, which maylead to reporting errors.
In particular, it is necessary to define the requirements in detail in order to clarify
whether the required data is the collateral netting under a CSA at the portfolio level or
the Close out Netting under an ISDA master agreement.
11．p.51, Question (74):
Are any of the Descriptions inconsistent with common industry usage or yourutilization of the data element?

6

(Our comment)
There are different market environment across regions and products, therefore inapplying the requirement, the CFTC is requested to provide sufficient time before
implementation and also consider a phased-in scheme.
Also, the CFTC should make a sufficient analysis of cost effectiveness in applying theregulation.
(Rationale)
The draft technical specifications include a number of additional data elements andmany of them require operational changes for the responsible personnel of swap
transactions, and thus would impose considerable compliance burdens. Therefore,
unless a sufficient preparation period is provided to banks, deficiencies and delays inreporting and other problems may occur.
While the reporting requirements of some data elements (e.g. Package Transaction,Event and Orders) are difficult to comply with unless SEFs and DCMs are used orreported by SEFs and DCMs, the degree of use of SEFs differs significantly acrossregions and products (e.g. SEFs are rarely used for FX products outside the U.S.). If
such actual market conditions are not considered and the regulation is enhanced in a
uniform manner, it is our concern that the market liquidity may decrease and systemicrisk may increase.
Further, as this draft technical specifications will make significant regulatory changes,
the CFTC is requested to assess cost effectiveness of the implementation of swap datareporting to date and then to give due consideration to the necessity of additional dataelements.

7