Interaction is the root tag for an interaction record. An interaction is an electronic or in-person communication between two or more participant firms (referred to as organizations in this standard). These include, but are not limited to, interactions that must be reported to comply with MiFID II regulations. Indicates the name of the person who created the Interaction record. Container element containing information about the interaction itself. This is the container element containing information about the participants. All individuals will be affiliated with a participant organization. For single-person entities (e.g., some third party experts), the name of the individual can be used as the participant organization name, but the individual should also be referred to as an individual participant under the participant organization umbrella. The Source package that exists in the common schema allows for (but does not require) a great deal of information about the individuals and firms participating in an interaction, including the areas of expertise for third-party experts. Container element for the status information for the interaction. This is the complex element containing information about the topic of the interaction, including identifying the companies, regions, sectors, industries, etc. that are the topic of the interaction. Note that all of this information is optional; firms can include or omit this as desired to provide additional details about the interaction’s purpose. Although this information could be contained in the InteractionName and/or InteractionComment fields, the InteractionTopic complex element will enable presenting this information in a structured format. Container element containing information about related interactions and/or research content. Firm name for the person who created the record. Uses OrganizationType complex type from common schema, which only requires firm name. Additional elements and attributes can be used, if desired, but are not required. The name of the person who created the record. Complex element used to record the number of firms participating in an interaction. Complex element containing details of a firm participating in an interaction. Each firm will have one record with zero, one, or more than one people affiliated. Container element for the information about each individual participating in the interaction. Element to capture the role associated with a participant, as expressed in a standardized list of options. Indicates the person's role within their firm, not role in the context of the interaction. (See free-text JobTitle tag for the person's company-defined title.) Describes how content contained in this product or interaction is associated with other products, or how content in other products is associated with this product or interaction. Can have none or any number of relationships to other products or interactions. Describes how content contained in this interaction is associated with other interactions, or how content in other interactions is associated with this one. Can have none or any number of relationships to other interactions. Describes how content contained in this interaction is associated with other interactions, or how content in other interactions is associated with this one. Can have none or any number of relationships to other interactions. Container element containing details of the location associated with the interaction (when relevant).For interactions that do not occur in person (phone calls, voicemail, data feed, etc.), this tag should be omitted rather than left blank. Container element for the venue information for the interaction. InteractionType is the complex type containing all information for the interaction record. Complex type containing information about the person who created the Interaction record. Appears here rather than in the Participant container element because the record creator may have no other role in the interaction (e.g., an administrative assistant to the interaction host). In cases where the record creator is also a participant, the person would appear in both locations. Complex type containing information about the interaction itself. Complex element containing information about the participants. All individuals will be affiliated with a participant organization. For single-person entities (e.g., some third party experts), the name of the individual can be used as the participant organization name, but the individual should also be referred to as an individual participant under the participant organization umbrella. The Source package that exists in the common schema allows for (but does not require) a great deal of information about the individuals and firms participating in an interaction, including the areas of expertise for third-party experts. Complex type for the status information for the interaction. As with the status tag in the Research standard, the status will pertain to the status of the interaction itself AND of any routine changes/updates to the interaction record. However, status information about individual participants will be located in the Participants area; additionally, information about the start/end date of the interaction will be housed in the InteractionDates area. This is the complex element containing information about the topic of the interaction, including identifying the companies, regions, sectors, industries, etc. that are the topic of the interaction. Note that all of this information is optional; firms can include or omit this as desired to provide additional details about the interaction’s purpose. Although this information could be contained in the InteractionName and/or InteractionComment fields, the InteractionTopic complex element will enable presenting this information in a structured format. Complex element containing information about related interactions and/or research content. Related interactions would include the conference that a particular interaction is part of or a prior interaction that this interaction is a follow up interaction to; related research content would include a data feed file or a research report. Related research content would be described using the RIXML Research Standard. Unique identifier used to identify the interaction record. In cases where an event included multiple interaction consumers, there will be a separate interaction record sent to each consumer firm that contains only the attendee information for attendees from that firm. This interactionRecordID attribute is the unique identifier for the record itself, and is required. In interactions with more than one consumer firm (a blast email, a breakout session at a conference, etc.), the interactionID and all other information contained in the record will be the identical, except for the consumer participant information and the unique identifier contained in this interactionRecordID tag. Thus, this is the unique identifier for this specific interaction + the participant information contained in this record. Any status changes, etc. provided to the consumer firm about this interaction should maintain the same interactionRecordID, using multiple timestamped Status entries (see below) to track the changes. Use of a Universal Unique IDentifier (UUID), as described on page 21 of the RIXML Research v2.5 Data Dictionary, is recommended. The identifier that uniquely identifies the interaction being described in the interaction record. In cases where there is only one record (i.e., an interaction with only one consumer organization), the same unique identifier can be used for interactionID and interactionRecordID; when there are multiple, the interactionID (this attribute) will be the same for each record, and the interactionRecordID will be a unique identifier for the record itself. interactionID is not required, but note that the relatedInteractionID tag references the interactionID tag. Although the interactionID tag is not required, it is necessary for the tag to be populated in any record for which the relatedInteractionID would like to make a connection. Further, in cases where an interaction is a sub-event of a larger event, there will be an interaction record for each. In the sub-event record, the interactionID tag is used for the sub-event, and the Related container element provides the information for the parent event. Similarly, the parent event will have an interaction record, with references to the sub-event(s) indicated in the Related container element. Other events that are considered related can also be indicated, if desired. Complex type containing information about the person who created the Interaction record. Appears here rather than in the Participant container element because the record creator may have no other role in the interaction (e.g., an administrative assistant to the interaction host). In cases where the record creator is also a participant, the person would appear in both locations. Firm name for the person who created the record. Uses OrganizationType complex type from common schema, which only requires firm name. Additional elements and attributes can be used, if desired, but are not required. The name of the person who created the record. Uses PersonDetailsType complex type from common schema. Complex type containing information about the interaction itself. The "title" of the interaction, a name or short description that all participants would recognize to identify or describe the event. Does not need to be unique. Free text comment field. The purpose of interaction – analyst marketing, model, deal roadshow, etc. Indicates whether the interaction was interactive, one-directional, or was a delivered (electronic or physical) product. Enumeration list field that indicates the manner in which an interaction occurred (in person, email, data feed, etc.). Indicates whether the interaction was initiated by the consumer, was initiated by the provider with a specific consumer in mind, or was initiated by the provider for a more general audience. Flag to indicate whether the interaction is considered a blast interaction by the interaction provider. Applies only to InteractionModes of VoiceMail or Email, and only if the voicemail or email was distributed to multiple firms (or was not customized for an individual person/firm). For all other InteractionModes, this tag should be omitted entirely rather than being set to "false". Flag to identify whether an interaction is delivered on a regular basis (data feed, etc.). Flag to indicate whether the interaction provider predicts the interaction to be perceived as high value by the interaction consumer, or has been told by the interaction consumer that it should be tagged as such. Complex type containing details of the dates(s) associated with the interaction. These are the dates related to the interaction itself (start date/time, end date/time, etc.), not timestamps related to the interaction record. Each interaction record requires at least one date. Complex type containing details of the location associated with the interaction, when relevant. For interactions that do not occur in person (phone calls, voicemail, data feed, etc.), this tag should be omitted rather than left blank. Complex element containing information about the participants. All individuals will be affiliated with a participant organization. For single-person entities (e.g., some third party experts), the name of the individual can be used as the participant organization name, but the individual should also be referred to as an individual participant under the participant organization umbrella. The Source package that exists in the common schema allows for (but does not require) a great deal of information about the individuals and firms participating in an interaction, including the areas of expertise for third-party experts. Complex type used to record the number of firms participating in an interaction. Complex type containing details of a firm participating in an interaction, including details about the firm and about the individuals from that firm participating in the interaction. Each firm will have its own ParticipantOrganizationType element with zero, one, or more than one people affiliated. Indicates the type of organization being described. Each type of organization that occurs in the ParticipantOrganization complex element should be captured. Integer indicating the number of organizations (firms, not individuals) of that type involved in the interaction. There will generally be one interaction provider firm. All corporate and expert organizations (if applicable) should match the number of firms represented in the ParticipantOrganization tags. However, the number of Consumer firms may not, since each consumer firm will only receive the consumer firm-related data for their own firm. Complex type containing details of a firm participating in an interaction, including details about the firm and about the individuals from that firm participating in the interaction. Each firm will have its own ParticipantOrganizationType element with zero, one, or more than one people affiliated. Organization types will include: Provider, Consumer, Corporate, and Expert. Describes an organization related to the interaction record. Multiple organizations are generally related to one interaction record – at a minimum, the interaction provider and at least one interaction consumer. Complex type for the information about each individual participating in the interaction. Complex type for the information about each individual participating in the interaction. Complex type collecting the information about each person participating in the interaction (including record creator). Complex type to capture the role associated with a participant, as expressed in a standardized list of options. Indicates the person’s role within their firm, not role in the context of the interaction. (See free-text JobTitle tag for the person’s company-defined title.) Indicates the status of the individual in the context of the interaction. (NOTE: not to be confused with the Status complex type, which contains information surrounding the status of the interaction itself.) InteractionParticipantStatus can be updated multiple times as that participant’s status changes; at a minimum, it should definitely be updated (with timestamp) once meeting has occurred to ensure accurate recording of actual attendance. Any participant with status of Accepted should be updated once the interaction has occurred. A workflow could either include manually updating every individual participant to the appropriate post-interaction status (no show, attended, etc.), or that those who did NOT attend would be manually updated, and an automatic sweep would update everyone else to Attended. A unique identifier used to identify each participant in the interaction. For accurate identification it is required that the personID be unique for a given publisher/provider, but the implementation of the ID is left to the publishers/providers to implement as they deem fit. Examples: email address, combination of LastName and FirstName, combination of internal employee ID and RIXML publisher ID. For records that are submitted to or through third-party aggregator(s), the PersonLabel complex element (within the Person element) can be used to provide the person identifier required for each aggregator. Optional flag to indicate whether an individual served as the host of the interaction. Should be omitted if the participant was not the host. Complex type for the status information for the interaction. As with the status tag in the Research standard, the status will pertain to the status of the interaction itself AND of any routine changes/updates to the interaction record. However, status information about individual participants will be located in the Participants area; additionally, information about the start/end date of the interaction will be housed in the InteractionDates area. Indicates the status represented by the interactionStatusDate timestamp. Firms that will be using this schema to disseminate information exclusively for interactions that actually occurred will likely only use the Delivered status type. Firms that use this schema for internal systems and/or for disseminating information about events at various stages of interaction lifecycle will use the other enumerations as well. For clarity, it is recommended that firms either use just the final status of the interaction or provide the entire interaction lifecycle, rather than providing some (but not all) parts of the lifecycle. Indicates the date and time at which the status was assigned. It is expressed using ISO 8601 as refined by the World Wide Web Consortium's note http://www.w3.org/TR/NOTE-datetime. In addition, RIXML requires the use of Zulu time or Z-time (GMT +/- n hours:minute:seconds). All times are absolute and easier to compute, rather than using a relative (i.e. 08:30 +5) time. Indicates whether or not the statusType is current -- i.e. the most recent. Note that while a product can have multiple statuses, only one of them can be current. This is the complex element containing information about the topic of the interaction, including identifying the companies, regions, sectors, industries, etc. that are the topic of the interaction. Note that all of this information is optional; firms can include or omit this as desired to provide additional details about the interaction’s purpose. Although this information could be contained in the InteractionName and/or InteractionComment fields, the InteractionTopic complex element will enable presenting this information in a structured format. This is the container element containing information about related interactions and/or research content. Related interactions would include the conference that a particular interaction is part of or a prior interaction that this interaction is a follow up interaction to; related research content would include a data feed file or a research report. Related research content would be described using the RIXML Research Standard. Describes how content contained in this product or interaction is associated with other products, or how content in other products is associated with this product or interaction. Can have none or any number of relationships to other products or interactions. Describes how content contained in this interaction record is associated with other interactions, or how content in other interactions is associated with this one. Can have none or any number of relationships to other interactions. The type of interaction – analyst marketing, model, deal roadshow, etc. Indicates whether the interaction was interactive, one-directional, or was a delivered (electronic or physical) product. Enumeration list field that indicates the manner in which an interaction occurred (in person, email, data feed, etc.). Indicates whether the interaction was initiated by the consumer, was initiated by the provider with a specific consumer in mind, or was initiated by the provider for a more general audience. Enumeration list-limited tag defining the person’s role within his/her firm. May or may not match person’s title. The RoleEnum list contains guidance regarding which roles are valid for each participant type (consumer, corporate, third party, or provider). Indicates the status of the individual in the context of the interaction. (NOTE: not to be confused with the Status complex type, which contains information surrounding the status of the interaction itself.) InteractionParticipantStatus can be updated multiple times as that participant’s status changes; at a minimum, it should definitely be updated (with timestamp) once meeting has occurred to ensure accurate recording of actual attendance. Any participant with status of Accepted should be updated once the interaction has occurred. A workflow could either include manually updating every individual participant to the appropriate post-interaction status (no show, attended, etc.), or that those who did NOT attend would be manually updated, and an automatic sweep would update everyone else to Attended. Indicates the participant’s status as related to the associated StatusTimeStamp. Indicates the timestamp for the related status. Describes how content contained in this product or interaction is associated with other products, or how content in other products is associated with this product or interaction. Can have none or any number of relationships to other products or interactions. Describes how content contained in this interaction record is associated with other interactions, or how content in other interactions is associated with this one. Can have none or any number of relationships to other interactions. Describes how content contained in this interaction record is associated with other interactions, or how content in other interactions is associated with this one. Can have none or any number of relationships to other interactions. Describes how content contained in this interaction record is associated with other interactions, or how content in other interactions is associated with this one. Can have none or any number of relationships to other interactions. The unique interactionID of the interaction to which this interaction is related (as stored in InteractionID of the related document). Indicates the type of relationship between this interaction and a related interaction. The description of the relationship between the current interaction and the other interaction to which it is related. Complex type containing the information pertaining to each instance of an InteractionDate complex type used in an interaction record. All elements are optional; however, there should be one instance of either InteractionDateTime OR InteractionDuration each time this complex type is used. Note that there is no mechanism in the standard to ensure consistency between an interaction’s start/end time and the duration indicated in the InteractionDuration element; this consistency must be built into systems using this standard. Timestamp representing the date/time type indicated in the interactionDateType. Type of interaction date/time representated by the interactionDateTime timestamp. Duration of interaction, expressed in minutes. Complex type containing details of the location associated with the interaction, when relevant. For interactions that do not occur in person (phone calls, voicemail, data feed, etc.), this tag should be omitted rather than left blank. Name of venue for the interaction. Attribute used to indicate the type of venue for the interaction.