Other

Rating History Files Publication Guide

Goals

This guide provides technical guidance on the creation of files containing rating histories conforming to the requirements of paragraph (b) of Rule 17g-7 of the Securities Exchange Act of 1934 (Exchange Act), which was adopted by the Securities and Exchange Commission (SEC) on August 27, 2014 and became effective on June 15, 2015.  Rule 17g-7(b) can be briefly summarized as follows:

  • A nationally recognized statistical rating organization (NRSRO) must make publicly available, for classes of credit ratings in which the NRSRO is registered with the SEC as of June 15, 2015, credit ratings that were outstanding as of, or initially determined on or after, June 15, 2012 (or, for a class of credit ratings in which the NRSRO becomes registered with the SEC after June 15, 2015, the date three years prior to the date the NRSRO becomes registered in such class) and any subsequent upgrades, downgrades and withdrawals of such credit ratings.  An NRSRO must disclose such credit ratings, along with certain additional information, within 12 months of the rating action for credit ratings paid for by the obligor or issuer and within 24 months of the rating action for all other credit ratings.

This guide is specific to the Record of Credit Ratings (ROCR) taxonomy dated 2015-03-31 (R15), which supersedes, as of June 15, 2015, the US-ROCR taxonomy dated 2009-10-31 (R09).There are a number of differences between R09 and R15.Some result from differences between the requirements of the superseded rules (paragraphs (d)(2) and (d)(3) of Rule 17g-2 of the Exchange Act) as compared to the requirements of paragraph (b) of Rule 17g-7.Other changes are simplifications to better align the format to the content of rating files previously published by NRSROs using R09.

This guide assumes a full understanding of the requirements of paragraph (b) of Rule 17g-7.This guide has been created for the limited purpose of providing guidance on file creation to technical audiences.Certain requirements that are explained in more detail in Rule 17g-7(b) and the accompanying rule release may be referred to in an abbreviated way in this guide.Reference should be made to Rule 17g-7(b) and the accompanying rule release for a description of the requirements of Rule 17g-7(b).This guide is not intended to provide additional interpretive guidance regarding paragraph (b) of Rule 17g-7.

Table of Contents

1. Web Site Location

2. Rating History File (Instance) Format

2.1. Schemas and namespaces

2.2. XML Syntax

2.3. Elements and attributes

2.4. Enumerated Values

2.4.1. SEC Category/Subcategory values

2.4.2. Obligor or Issuer Identifier Scheme values

2.4.3. Instrument Identifier Scheme values

2.4.4. Rating Action Classification Values

2.4.5. Rated Object Type values

2.5. Identifiers

2.5.1. Obligor Identifiers

2.5.2. Issuer Identifiers

2.5.3. Instrument Identifiers

2.6. XBRL Syntax example

3. Instance Scope

4. Instance Naming

5. Zip Format Archives

6. Errata and changes in this version

Appendix A. Logical Data Model

Figure 1. Namespaces and suggested prefixes

Figure 2. Element and Attribute Syntax

Figure 3. SEC Category/Subcategory values from 17g-7(b)(2)(vi)

Figure 4. Obligor or Issuer Identifier Schemes

Figure 5. Instrument Identifier Schemes

Figure 6. Rating Action Classifications

Figure 7. Rated Object Type values

Figure 8. Example syntax

Figure 9. A non-normative example of instance names

Figure 10. A non-normative example of an archive and its contents

Figure 11. Logical model of a Record of Credit Rating Actions

Figure 12. Logical model of Obligor Rating Data

Figure 13. Logical model of Issuer and Instrument Rating Data

1. Web Site Location

An NRSRO should maintain a single permanent URL for a web page where the ratings data required by Rule 17g-7(b) and any explanatory material will be found. In order for users to be able to easily access the required disclosures, it is recommended that once an NRSRO establishes an URL where the ratings data has been published, the files should not be removed or relocated in a way that makes it inaccessible from that same URL.

The following sections detail the format of individual rating history files and how they should be organized to make them accessible to the public in conformance with Rule 17g-7(b).

2. Rating History File (Instance) Format

A rating history file is an XML instance document (instance) that is Schema-valid with respect to the R15 schema, and is furthermore XBRL-valid with respect to that same R15 schema. An instance that is not valid in both ways does not comply with Rule 17g-7(b). To ensure validity of the instance, it is useful to perform both XML and XBRL validation against the R15 schema.

2.1. Schemas and namespaces

The R15 schema is located here: http://xbrl.sec.gov/rocr/2015/ratings-2015-03-31.xsd.

The following table includes the namespace URIs and suggested namespace prefixes that should be attached to the root <xbrli:xbrl> element. See section 2.6 for an example.

Figure 1. Namespaces and suggested prefixes

targetNamespace Suggested namespace prefix
http://xbrl.sec.gov/ratings/2015-03-31 “”, i.e., blank.
http://www.xbrl.org/2003/instance xbrli
http://www.xbrl.org/2003/linkbase link
http://www.w3.org/1999/xlink xlink
http://www.w3.org/2001/XMLSchema-instance xsi
http://www.xbrl.org/2003/iso4217 iso4217

2.2. XML Syntax

The preferred XML heading on the instance is <?xml version="1.0" encoding="UTF-8"?>.

Element content must have no leading, trailing, or repeated space characters (space-normalized) unless otherwise specified. All element and attribute content should be considered case-sensitive.

2.3. Elements and attributes

Every valid R15 instance must have certain XML elements, attributes, and attribute values. In the table below, the columns are described as follows:

  • Element or Attribute: <…> indicates an element and @ indicates an attribute.
  • ContextRef: Y in this column means the element requires a @contextRef attribute whose value equals the @id of the <xbrli:context> element.
  • Depth: This indicates the level of nesting for a particular element.
  • Count:
    • 1 when the element or attribute is required by its parent element;
    • 0..1 when it is optional;
    • 0..* when there can be any number of occurrences;
    • 1..* when there must be one or more occurrences; or
    • A description of when the element must or may appear in conjunction with other elements.
  • Text content: Description of the value. “Constant value =” indicates a required value.

The elements below are using the suggested namespace prefixes from section 2.1, including the suggested blank prefix for R15.

Figure 2. Element and Attribute Syntax

Element or Attribute Con-text-Ref Depth Count Text content

<xbrli:xbrl>

0

1

@xsi:schemaLocation

1

Constant value = “http://xbrl.sec.gov/ratings/2015-03-31 http://xbrl.sec.gov/rocr/2015/ratings-2015-03-31.xsd”

<link:schemaRef>

1

1

@xlink:type

1

Constant value = “simple”

@xlink:href

1

Constant value = “http://xbrl.sec.gov/rocr/2015/ratings-2015-03-31.xsd”

<xbrli:context>

1

1

@id

1

Any valid XML id, such as “m”. The value must equal the value of every @contextRef attribute elsewhere in the instance.

<xbrli:entity>

2

1

<xbrli:identifier>

3

1

Name of the NRSRO. Example: “ACME Ratings Inc.”

@scheme

1

Constant value = “http://www.sec.gov/NRSRO”. Note that this is a URI, not a web URL.

<xbrli:period>

2

1

<xbrli:startDate>

3

1

The date of the earliest rating in the file, in ISO 8601 format YYYY-MM-DD. Example content: “2012-06-15”.

<xbrli:endDate>

3

1

The date of the latest rating in the file, in ISO 8601 format YYYY-MM-DD. Example content: “2015-03-31”.

<xbrli:unit>

1

0..1

This element is needed if element <CR> appears anywhere in the document.

@id

1

Constant value = “Rate”.

<xbrli:measure>

2

1

Constant value = “xbrli:pure”.

<xbrli:unit>

1

0..*

One unit element is needed for each different currency appearing in <PV> elements in the document.

@id

1

A three-character ISO 4217 currency code. Example values: “USD”, “GBP”.

<xbrli:measure>

2

1

The currency code in the @id attribute of the parent element <xbrli:unit>, with the prefix iso4217. Example content: “iso4217:USD”.

<ROCRA>

1

1

<RAN>

Y

2

1

The Rating Agency Name, equal to the text content of <xbrli:identifier>.

<FCD>

Y

2

1

The File Creation Date in ISO 8601 format YYYY-MM-DD; the date the file was created and made available on the NRSRO’s web site. Example content: “2015-03-01”.

<OD>

2

0..*

<OSC>

Y

3

1

The SEC Category or Subcategory applicable to the Obligor (see
“SEC Category/Subcategory values”, 2.4.1 below).

<OIG>

Y

3

0..1

Obligor Industry Group within the broad heading provided by the SEC Category or Subcategory. For example, an Obligor associated with the “Financial” SEC Category could be further identified as a “Bank”, “Broker” or another applicable identifier. The values used are the proprietary values used by the NRSRO.

<OBNAME>

Y

3

1

The Obligor Name.

<LEI>

Y

3

0..1 and at least one of LEI, CIK, or OI must be present.

The 20-character alphanumeric value Legal Entity Identifier issued by a utility endorsed or otherwise governed by the Global LEI Regulatory Oversight Committee or the Global LEI Foundation (LEI) to the obligor, if available.

<CIK>

Y

3

0..1 and at least one of LEI, CIK, or OI must be present.

The 10-digit Central Index Key (CIK) number of the Obligor, if available; it is used only when no LEI is available for the Obligor.

<OI>

Y

3

0..1 and at least one of LEI, CIK or OI must be present.

The content of this element is an Obligor Identifier in a scheme other than LEI or CIK; it is used only when neither LEI nor CIK is available for the Obligor.

<OIS>

Y

3

0..1 and if OI appears then either OIS or OIOS but not both must appear.

The scheme of the identifier in <OI>. This must be one of the allowed obligor or issuer identifier scheme values (see “Obligor or Issuer Identifier Scheme values”, 2.4.2 below).

<OIOS>

Y

3

0..1 and if OI appears then either OIS or OIOS but not both must appear.

The scheme of the identifier in <OI> if such scheme is not identifiable by a listed standard obligor or issuer identifier scheme value.

<ORD>

3

1..*

<IP>

Y

4

1

Issuer Paid. True if the rating was issuer-paid, otherwise False.

<R>

Y

4

1

The credit rating symbol, number, or score in the applicable rating scale of the NRSRO (after giving effect to the reported credit rating action). Example values: AAA, A+ or Ba.

<RAD>

Y

4

1

The date of the credit rating action, in ISO 8601 YYYY-MM-DD format. Example value: 2014-10-28.

<RAC>

Y

4

0..1 and at least one of RAC, WST, ROL or OAN must appear.

Rating Action Classification (see “Rating Action Classification Values”, 2.4.4 below) as required by Rule 17g-7(b)(v).

<WST>

Y

4

0..1 and at least one of RAC, WST, ROL or OAN must appear.

Watch Status. This item records watch list status such as Positive, Negative, Evolving, Developing, and Stable. The NRSRO should use its own standard terminology.

<ROL>

Y

4

0..1 and at least one of RAC, WST, ROL or OAN must appear.

Rating Outlook. This item is used to record Outlook, such as Positive, Negative, Evolving, and Developing. The NRSRO should use its own standard terminology.

<OAN>

Y

4

0..1 and at least one of RAC, WST, ROL or OAN must appear.

The description of an Other Announcement type not classifiable under <RAC>, <WST>, or <ROL>. The NRSRO should use its own standard terminology. Example values: “Company name change”, “Affirm”.

<RT>

Y

4

0..1

The rating type. The NRSRO should use its own standard terminology. Example values: “Bank Financial Strength”.

<RST>

Y

4

0..1 and may only appear if RT is present.

Sub type of the rating type used by the NRSRO. This is used to further classify a Rating Type if necessary.

<RTT>

Y

4

0..1

The Rating Type Term; the NRSRO should use its own standard terminology. Example values: “short-term”, “long-term”.

<ISD>

2

0..*

<SSC>

Y

3

1

The SEC Category or Subcategory applicable to the Issuer (see “SEC Category/Subcategory values”, 2.4.1 below).

<IG>

Y

3

0..1

The Issuer Industry Group within the broad heading provided by the SEC Category or Subcategory. For example, an Issuer associated with the “Financial” SEC Category could be further identified as a “Bank”, “Broker” or another applicable identifier. The values used are the proprietary values used by the NRSRO.

<ISSNAME>

Y

3

1

The Issuer name.

<LEI>

Y

3

0..1 and at least one of LEI, CIK, or ISI must be present.

The 20-character alphanumeric value Legal Entity Identifier issued by a utility endorsed or otherwise governed by the Global LEI Regulatory Oversight Committee or the Global LEI Foundation (LEI) to the Issuer, if available.

<CIK>

Y

3

0..1 and at least one of LEI, CIK, or ISI must be present.

The 10-digit Central Index Key (CIK) number of the Issuer, if available; it is used only when no LEI is available for the Issuer.

<ISI>

Y

3

0..1 and at least one of LEI, CIK or ISI must be present.

An Issuer Identifier in a scheme other than LEI or CIK and is used only when neither LEI nor CIK of the Issuer is available.

<ISIS>

Y

3

0..1 and if <ISI> appears, then either <ISIS> or <ISIOS> but not both must appear.

The scheme of the identifier in <ISI>; it must be one of the allowed Obligor or Issuer identifier scheme values (see “Obligor or Issuer Identifier Scheme values”, 2.4.2 below).

<ISIOS>

Y

3

0..1 and if <ISI> appears, then either <ISIS> or <ISIOS> but not both must appear.

The scheme of the identifier in <ISI> if such scheme is not identifiable by a listed standard Issuer identifier scheme.

<IND>

3

1..*

<OBT>

Y

4

1

The Object Type being rated; the value must be one of the rated object categories (see “Rated Object Type values”, 2.4.5 below).

<INSTNAME>

Y

4

1

The security or money market instrument name.

<CUSIP>

Y

4

0..1

The CUSIP of the security or money market instrument.

<INI>

Y

4

0..1 and appears only if no CUSIP is available.

An Instrument Identifier within a scheme other than CUSIP and is used only when a CUSIP is not available.

<INIS>

Y

4

0..1 and if <INI> appears then either <INIS> or <INIOS> but not both must appear.

The scheme of the identifier in <INI> and must be one of the allowed instrument identifier scheme values (see “Instrument Identifier Scheme values”, 2.4.3 below).

<INIOS>

Y

4

0..1 and if <INI> appears then either <INIS> or <INIOS> but not both must appear.

The scheme of the identifier in <INI> if such scheme is not identifiable by a listed standard instrument identifier scheme.

<IRTD>

Y

4

0..1

The Instrument Rate (coupon) Type Description as being fixed, variable, stepped, zero, index plus spread, floating, none, etc.

<CR>

Y

4

0..1

Coupon Rate stated in the contractual debt agreement. This is not a percentage, it is a decimal value. For example, a 4% rate is represented as “.04”.

@decimals

1

Constant value = “INF”.

@unitRef

1

Constant value = “Rate”.

<MD>

Y

4

0..1

The Maturity Date of the instrument, in ISO 8601 format YYYY-MM-DD.

<PV>

Y

4

0..1

The Par (face) Value of the debt instrument. The number is not scaled; for example, if the value is one million, the content is “1000000”. If element <PV> is present there must be at least one <xbrli:unit> child element of <xbrli:xbrl>.

@decimals

1

The value “-3” if par value was rounded to thousands, “-6” if in millions, “-9” if in billions, “0” if not rounded, etc.

@unitRef

1

The attribute value must match the @id value on an <xbrli:unit> element representing the currency code.

<ISUD>

Y

4

0..1

Issuance Date of the instrument, in ISO 8601 format YYYY-MM-DD.

<RODC>

Y

4

0..1

Other Debt Category using the NRSRO’s own categorization method to identify the class of debt such as senior, subordinated or other properties of the debt issued.

<INRD>

Y

4

1..*

<IP>

Y

5

1

Same as <IP> above, for an Instrument rating.

<R>

Y

5

1

Same as <R> above, for an Instrument rating.

<RAD>

Y

5

1

Same as <RAD> above, for an Instrument rating.

<RAC>

Y

5

0..1 and at least one of RAC, WST, ROL or OAN must appear.

Same as <RAC> above, for an Instrument rating.

<WST>

Y

5

0..1 and at least one of RAC, WST, ROL or OAN must appear.

Same as <WST> above, for an Instrument rating.

<ROL>

Y

5

0..1 and at least one of RAC, WST, ROL or OAN must appear.

Same as <ROL> above, for an Instrument rating.

<OAN>

Y

5

0..1 and at least one of RAC, WST, ROL or OAN must appear.

Same as <OAN> above, for an Instrument rating.

<RT>

Y

5

0..1

Same as <RT> above, for an Instrument rating.

<RST>

Y

5

0..1 and may only appear if <RT> is present.

Same as <RST> above, for an Instrument rating.

<RTT>

Y

5

0..1

Same as <RTT> above, for an Instrument rating.

2.4. Enumerated Values

2.4.1. SEC Category/Subcategory values

The figure below shows the values allowed in <OSC> and <SSC>.

Figure 3. SEC Category/Subcategory values from 17g-7(b)(2)(vi)

Value

Meaning

Financial

Financial institutions, brokers, or dealers

Insurance

Insurance companies

Corporate

Corporate issuers

Issuers of structured finance products will be in one of the following subclasses:

RMBS

Residential mortgage backed securities (for purposes of this subclass, RMBS means a securitization primarily of residential mortgages)

CMBS

Commercial mortgage backed securities (for purposes of this subclass, CMBS means a securitization primarily of commercial mortgages)

CLO

Collateralized loan obligations (for purposes of this subclass, a CLO means a securitization primarily of commercial loans)

CDO

Collateralized debt obligations (for purposes of this subclass, a CDO means a securitization primarily of other debt instruments such as RMBS, CMBS, CLOs, CDOs, other asset backed securities, and corporate bonds)

ABCP

Asset-backed commercial paper conduits (for purposes of this subclass, ABCP means short term notes issued by a structure that securitizes a variety of financial assets, such as trade receivables or credit card receivables, which secure the notes)

Other ABS

Other asset-backed securities (for purposes of this subclass, other ABS means a securitization primarily of auto loans, auto leases, floor plans, credit card receivables, student loans, consumer loans, or equipment leases)

Other SFP

Other structured finance products (for purposes of this subclass, other SFPs means any structured finance product not identified above)

Issuers of government securities, municipal securities, or securities issued by a foreign governmentwill be in one of the following subclasses:

Sovereign

Sovereign issuers

US Public

U.S. public finance

INT Public

International public finance

2.4.2. Obligor or Issuer Identifier Scheme values

The figure below shows the values allowed in elements <ISIS> and <OIS>.

Figure 4. Obligor or Issuer Identifier Schemes

Value

Meaning

DUNS

Dun & Bradstreet D-U-N-S® Number

BIC

Business Identifier Code (ISO 9362)

NRSRO

Obligor or Issuer identifier scheme that is specific to the reporting NRSRO

2.4.3. Instrument Identifier Scheme values

The figure below shows the values allowed in element <INIS>.

Figure 5. Instrument Identifier Schemes

Value

Meaning

ISIN

International Securities Identification Number (ISO 9166)

SEDOL

Stock Exchange Daily Official List (UK)

VALOR

Valorennummer (CH)

WKN

Wertpapierkennnummer (DE)

SICC

Securities Identification Code Committee (JP)

NRSRO

Instrument identifier scheme that is specific to the reporting NRSRO

2.4.4. Rating Action Classification Values

The figure below shows the values allowed in element <RAC>.

Figure 6. Rating Action Classifications

Value

Title

Meaning

HS

History-Start

An addition to the rating history disclosure because the credit rating was outstanding as of the date 6/15/2012, or because the credit rating was outstanding as of the date three years prior to the nationally recognized statistical rating organization becoming registered in the class of credit ratings.

NW

New

An initial credit rating.

UP

Upgrade

An upgrade of an existing credit rating.

DG

Downgrade

A downgrade of an existing credit rating, which would include classifying the obligor, security, or money market instrument as in default, if applicable.

A withdrawal of an existing credit rating and, if the classification is withdrawal, the nationally recognized statistical rating organization also must classify the reason for the withdrawal as either:

WD

Withdrawal-Default

The obligor defaulted, or the security or money market instrument went into default.

WE

Withdrawal-Extinguished

The obligation subject to the credit rating was extinguished by payment in full of all outstanding principal and interest due on the obligation according to the terms of the obligation.

WO

Withdrawal-Other

The credit rating was withdrawn for reasons other than Default or Extinguished.

2.4.5. Rated Object Type values

The figure below shows the values allowed in element <OBT>.

Figure 7. Rated Object Type values

Value

Definition

Instrument

The rating applies to an instrument.

Program

The rating applies to a program.

Shelf

The rating applies to a shelf registration.

Other

The rating applies to an object other than instrument, program or shelf.

2.5. Identifiers

Users should be able to correctly and uniquely identify obligors or issuers and securities or money market instruments, as applicable, no matter what instance they appear in.

If an NRSRO chooses to provide identifiers of any kind with their own identifier scheme, the NRSRO should maintain a list of all identifiers used, so as to avoid duplication.

2.5.1. Obligor Identifiers

In <OD>, the name element <OBNAME> is always required, but is not as reliable as other alphanumeric identification schemes.

If the Obligor has an LEI, then <LEI> should appear in <OD>.

Otherwise, if the Obligor has a CIK, then <CIK> should appear in <OD>.

Otherwise, if the scheme is among those in 2.4.2 above, then both <OI> and <OIS> must be provided.

Otherwise, <OI> and <OIOS> must be provided.

Any particular combination of <OI> with <OIS> and <OIOS> should refer to the same Obligor in all instances.

2.5.2. Issuer Identifiers

In <ISD>, the name element <ISSNAME> is always required, but is not as reliable as other alphanumeric identification schemes.

If the Issuer has an LEI, then <LEI> should appear in <ISD>.

Otherwise, if the Issuer has a CIK, then <CIK> should appear in <ISD>.

Otherwise, if the scheme is among those in 2.4.2 above, then both <ISI> and <ISIS> must be provided.

Otherwise, <ISI> and <ISIOS> must be provided.

Any particular combination of <ISI> with <ISIS> or <ISIOS> should refer to the same Issuer in all instances.

2.5.3. Instrument Identifiers

In <IND>, the name element <INSTNAME> is not as reliable as other alphanumeric identification schemes.

If the Instrument has a CUSIP, then <CUSIP> should appear in <IND>.

Otherwise, if the scheme is among those in 2.4.3 above, then both <INI> and <INIS> must be provided.

Otherwise, <INI> and <INIOS> must be provided.

Any particular combination of <INI> with <INIS> or <INIOS> should refer to the same Identifier in all instances.

2.6. XBRL Syntax example

This is an example of a XML heading and root (<xbrli:xbrl>) element. All necessary namespaces are bound to their suggested namespace prefixes, and the root element’s @xsi:schemaLocation attribute is included.

Figure 8. Example syntax

<?xml version="1.0" encoding="UTF-8"?>
<xbrli:xbrl xmlns="http://xbrl.sec.gov/ratings/2015-03-31"
xmlns:xbrli="http://www.xbrl.org/2003/instance"
xmlns:link="http://www.xbrl.org/2003/linkbase"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:iso4217="http://www.xbrl.org/2003/iso4217"
xsi:schemaLocation="http://xbrl.sec.gov/ratings/2015-03-31 http://xbrl.sec.gov/rocr/2015/ratings-2015-03-31.xsd">
<link:schemaRef xlink:type="simple" xlink:href="http://xbrl.sec.gov/rocr/2015/ratings-2015-03-31.xsd"/>
<!--ratings data goes here-->
</xbrli:xbrl>

3. Instance Scope

The elements for SEC Category/Subcategory, Industry Group, and Name implicitly define a hierarchy. For Obligors, these elements are <OSC>, <OIG> and <OBNAME>. For Issuers (and therefore for Instruments), these elements are <SSC>, <IG>, and <ISSNAME>. The hierarchy provides consistency in the way that different NRSROs partition their published data into instances. A single instance may contain the rating histories for:

  • All subclasses, all industry groups, and either all obligors or all issuers. That is, an instance contains only <OD> or <ISD> elements, but not both. Note that an “Obligor” is an organization on which a rating is published, appearing in an <OD> element, while an “Issuer” is an organization which may or may not have separate Obligor ratings in an <OD> element, but which has one or more Instrument ratings and therefore appears in an <ISD> element.
  • One subclass, all industry groups, and either all obligors or all issuers. That is, an instance contains only <OD> elements that all have the same value for <OSC>, or only <ISD> elements that all have the same value for <SSC>.
  • One subclass, one industry group, and either all obligors or all issuers. That is, an instance contains only <OD> elements that all have the same value for <OSC> and <OIG>, or only <ISD> elements that all have the same value for <SSC> and <IG>.
  • One obligor or one issuer. That is, an instance contains only one occurrence of <OD> or one <ISD> in the <ROCRA> element.

Furthermore:

  • Different instruments (element <IND>) from the same issuer should NOT be divided among multiple instances.
  • Files should NOT be divided according to whether ratings are issuer paid or not. Use the Boolean flag <IP> in elements <INRD> or <ORD> to indicate this.

As a rule of thumb, a single instance should not have more than 5000 <INRD> or <ORD> occurrences, because extremely large instances can be difficult to use. If an NRSRO were to publish all ratings required by the rule in a single file, it could exceed over 100MB in size; yet only a small fraction of the file’s contents would change on a daily or even monthly basis. Empirically, setting a limit on the number of <INRD> or <ORD> elements appearing in any one instance provides a workable balance between the frequency at which new rating actions are appended to rating histories, the size of the files and the overall number of files.

4. Instance Naming

Each instance should have a unique file name:

  • An instance name must have the suffix “.xml”.
  • The name must not contain spaces or special characters that are commonly used as pathname delimiters, such as “/”, “\” or “;”.

The name should convey the following information to users:

  • The name of the NRSRO.
  • A name identifying the scope of ratings it includes: an identifier or name for a single issuer or obligor, or the appropriate subset of issuers, obligors, industry groups, etc. The purpose of this is to help users identify the content of the instance by looking at the name.
  • The date that the instance was published, in ISO 8601 format (YYYY-MM-DD). The date part ensures that an instance name is unique. This should be the same as the value of <FCD> in the instance.

Figure 9. A non-normative example of instance names

Instance Name

Contents

ACME-2010-12-31.xml

An instance containing all obligor or issuer rating actions of NRSRO “ACME Ratings, Inc.”, but not both.

ACME-Fin-2010-12-31.xml

All ratings in SEC category “Financial”.

ACME-Fin-Bank-2010-12-31.xml

All ratings in SEC category “Financial” and ACME’s industry group “Bank”.

ACME-Chemicals-2010-12-31.xml

All ratings in ACME’s industry group “Chemicals”.

ACME-CIK -9876543210-2010-12-31.xml

All actions for the one issuer with CIK 9876543210.

ACME-NAME-XYZ-Inc-2010-12-31.xml

All actions for the one issuer with Name XYZ Inc.

ZRATE-CUSIP-987654321-2010-12-31.xml

All actions of NRSRO “ZRATE Corp.” for one issuer with CUSIP 987654321.

5. Zip Format Archives

One or more instances may be published in a file with the suffix “.zip”.

  1. This must be a ZIP or ZIP64 format archive with no proprietary extensions.
  2. If the archive contains folders, the folder structure should mirror the scope hierarchy described above.
  3. Zip archives should contain only instances and should not contain other zip archives.
  4. All instances should have the same date, and the date in the name of the archive file should match that date.

Figure 10. A non-normative example of an archive and its contents

Archive Name

Contents

ACME-2010-12-31.zip

Corporate/Tech/ACME-XYZ-Inc-2010-12-31.xml

Financial/Bank/ACME-First-Federal-Savings-2010-12-31.xml

Financial/Bank/ACME-Second-State-Savings-2010-12-31.xml

AssetBacked/Consumer/ACME-CIK-9876543210-2010-12-31.xml

ZRATE-Financial-2010-12-31.zip

Financial/Bank/ACME-First-Federal-Savings-2010-12-31.xml

Financial/Bank/ACME-Second-State-Savings-2010-12-31.xml

ZRATE-AssetBacked-2010-12-31.zip

AssetBacked/Consumer/ACME-CIK-9876543210-2010-12-31.xml

AssetBacked/Commerical/ACME-CIK-876543109-2010-12-31.xml

An NRSRO that publishes multiple zip archives each month should consider using an URL hierarchy that resembles the scope hierarchy.

In order for users to be able to easily access the required disclosures, it is recommended that once an NRSRO establishes an URL where the ratings data have been published, an instance (or zip archive) should not be removed or relocated in a way that makes it inaccessible from that same URL. It is further recommended that the ratings data be accessible from a single location on the NRSRO’s Web site.

NRSROs may consider using an URL hierarchy that resembles the scope hierarchy. A typical folder could contain files published at many different dates. This will still help to prevent any individual folder on the web server from containing thousands of files. Organizing the hierarchy by type and scope facilitates verification of historical rating data for a given issue or issuer.

6. Errata and changes in this version

  • Introduction: “becomes effective” changed to “became effective.”
  • Section 2: A sentence was added on validation.
  • Section 2.1: This section has been rewritten to enhance clarity; the R15 schema location and namespace have been revised; the xlink namespace has been revised; the xsi and iso4217 namespaces have been added.
  • Section 2.3: The text before Figure 2 has been reworded for clarity.
  • Figure 2: The “Id” column has been renamed to “Context Ref”, and its contents changed from “@” to “Y” for clarity; an attribute has been added to the root element <xbrli:xbrl>; the value of the attribute @xlink:href of the element <link:schemaRef> has been revised; the description of the element <xbrli:endDate> has been clarified; the count of the attribute @id for both occurrences of <xbrli:unit> has been revised; the descriptions of the @id attribute of the first occurrence of the element <xbrli:unit> and the first occurrence of the element <xbrli:measure> have been reworded for clarity; the description of the second occurrence of <xbrli:measure> has been changed; the description of the elements <FCD>, <RAD>, <MD>, and <ISUD> has been updated to clarify that the date format is using the ISO 8601 standard; the description of the <RAC> element has been simplified; the count of the <CUSIP> element has been revised; the descriptions of the @decimals and @unitRef attributes of the element <CR> have been reworded for clarity; and the @decimals attribute of the element <PV> has been expanded for further clarity.
  • Figure 3: The text introducing the first and second groups of subclasses has been clarified.
  • Section 2.6: This section has been added to provide an example.
  • Section 3: Wording and formatting edits were made for clarity.
  • Section 4: The five points were numbered, now they are bulleted.

Appendix A. Logical Data Model

The XML schema of valid R15 instances lends itself to transformation to and from a relational model. The figures below illustrate how the data in an instance could be stored equivalently in relational tables. The figures are in Unified Modeling Language (UML) syntax with <<FK>> denoting foreign key relationships, and class attributes that are not optional being preceded by *. Blue boxes represent those XML elements that could be represented as tables (ROCRA, OD, ORD, ISD, IND, and INRD) and within each table, the other elements appear as columns of various data types. Green boxes list enumerated values that correspond to a column data type. Notes in each box cross reference to the provisions of paragraph (b) of Rule 17g-7.

Figure 11. Logical model of a Record of Credit Rating Actions

Figure 12. Logical model of Obligor Rating Data

Figure 13. Logical model of Issuer and Instrument Rating Data

Modified: July 5, 2023
Return to Top