RIXML Documentation

SecurityDetails

RIXML 2.5 Element

Level OneRequired

Optional container element for describing securities associated with an issuer. When present, must contain at least one Security element providing financial instrument details.

Usage

Optional element within Issuer, appearing at most once. When included, must contain at least one Security child element.

Business Context

Enables detailed security-level tagging for research products, supporting precise investment instrument identification and portfolio-specific content organization.

Source:level-one-2.5
Schema:RIXML-Common-2_5.xsd:1835

Specification Guide

Overview

SecurityDetails is a container element that groups all information about specific securities issued by a particular issuer and discussed in a research product. It functions purely as an organisational wrapper — it carries no attributes or text content of its own — and exists to host one or more Security child elements within an Issuer context (sources: data-dictionary-2.5.1 p.54, level-one-2.5 p.13, user-guide-2.3.1 p.37). By nesting security-level data beneath the issuer that produced it, SecurityDetails preserves the issuer → security hierarchy required for accurate routing, filtering, and analytical processing of research that addresses individual financial instruments such as share classes, bond issues, or derivatives.

Usage

SecurityDetails appears within Issuer (itself a child of IssuerDetails, inside Context) and may occur zero or one times per issuer. When present, it MUST contain at least one Security element; additional Security children may follow to describe multiple instruments from the same issuer (sources: level-one-2.2 p.18, level-one-2.5 p.13). Include SecurityDetails when the research discusses specific tradable instruments — for example, equity research with target prices and ratings, fixed-income coverage of particular bond issues, or analysis of companies with multiple share classes. Omit it when the research addresses only issuer-level topics (e.g. corporate strategy, sector positioning) without instrument-level recommendations (sources: example-company-basic-2.4, data-dictionary-2.5.1 p.54). Because SecurityDetails has no attributes or direct content, all identification, classification, financial metrics, ratings, and target-price information are carried on the nested Security elements.

Rules

  • MUSTWhen SecurityDetails is present, it MUST contain at least one Security child element.[RIXML Level One Addendum v2.2 p.18] [RIXML Level One Addendum v2.3 p.13] [RIXML Level One Addendum v2.3.1 p.13] [RIXML Level One Addendum v2.4 p.13] [RIXML Level One Addendum v2.5 p.13]
  • SHOULDSecurityDetails itself is optional within Issuer and SHOULD be omitted entirely if no security-level information is being conveyed, rather than included as an empty container.[RIXML Level One Addendum v2.4 p.13] [RIXML Level One Addendum v2.5 p.13]

Relationships

Where It Fits

Canonical Path

Children

Definition

TypeSecurityDetailsType
Namespacehttp://www.rixml.org/2017/9/RIXML
Min Occurs1
Max Occurs1

Attributes

No attributes defined for this element

Children

SecuritySecurityType1..unbounded
requiredSince 2.1

Example

<SecurityDetails>
  <Security> ... </Security>
</SecurityDetails>

Version History

Unchanged since introduction in RIXML 2.1

SecurityDetails has been present and stable across the RIXML 2.x line. In RIXML 2.1 the user guide describes it as a container grouping security-related information for a research product, positioned within Context [user-guide-2.1 p.35]. From RIXML 2.2 onward the documentation consistently locates it at Research.Product.Context.IssuerDetails.Issuer.SecurityDetails, formalising its role as a child of Issuer rather than a direct child of Context (sources: level-one-2.2 p.18, user-guide-2.2 p.37). The structural contract — optional within Issuer, requiring at least one Security when present — is unchanged through versions 2.3, 2.3.1, 2.4, and 2.5 (sources: level-one-2.3 p.13, level-one-2.3.1 p.13, level-one-2.4 p.13, level-one-2.5 p.13, data-dictionary-2.5.1 p.54).

Business Rules

MUST

When SecurityDetails element is present, it must contain at least one Security element

validationconditional-requirement

Semantic Relationships

Constrains1 relationship

SecurityMUST

If SecurityDetails element is present, this element must contain at least one Security element

RIXML Level One Addendum v2.5, p.13Research.Product.Context.IssuerDetails.Issuer.SecurityDetails