Transactions Output Specification — XML

General Information
Detailed Element Descriptions
Client Batch Confirmation Reconciliation Files
Client Confirm File Process for Managed Accounts
Transaction XML Examples

General Information

Overview of File Types

The specifications for the batch transactions output and real-time transactions output for Morningstar Retirement Manager appear in this document. The schema is the same regardless whether the transaction is sent back as a batch file or a real-time string. The only difference is that only one user will appear in each real-time transaction string, but there could be multiple users in the batch transaction files. There are three different files that will be explained in this document:

Morningstar batch transaction file and real-time transactoin string
Client real-time confirmation receipt file
Client batch confirmation reconciliation file.

Real-Time Transaction String

The Morningstar real-time transaction string will be used when a transaction is generated from the Retirement Manager web application for Advice, Guidance, and **Managed Accounts service options. The transaction string will indicate which service the user has chosen. For the 'OnlineAdvice' and 'OnlineGuidance' service options, the transaction will also include current rebalancing and future investment allocations. Other items, such as contribution rate, catch up contributions, and the user’s company stock target, will also be sent back if required by the client. If "NONE" is sent back as the service option the participant is being opted-out of this service.

Batch Transaction File

The Morningstar batch transactions output file will be used in any of the following circumstances: (1) clients who do not use the Retirement Manager web interface to enroll users or adjust data for the Managed Accounts service option, (2) batch quarterly rebalancing transaction files for Managed Accounts, (3) for the Managed Accounts service option, all participants who enroll or make changes through the Retirement Manager web interface will have transactions sent back in a batch file. Batch transactions will include the service option chosen as well as any current rebalancing and future investment allocations. Other items, such as contribution rate, catch up contributions, and the user’s company stock target, will also be sent back if required by the client and setup in the configuration file. If "NONE" is sent back as the service option the participant is being opted-out of this service.

For Managed Accounts, please note the following:

If the user is simply opting out of Managed Accounts through the Retirement Manager web application (and not switching to a different service option), this will be indicated through a real-time and batch transaction sent with service option of ‘NONE’. This type of opt-out transaction will not include fund reallocations or future allocations. (If the user is opting out of Managed Accounts, but switched to another service option, such as Advice or Guidance, a real-time transaction will be sent out as described above with the new service option value).
- If the real-time opt-out transaction is confirmed by the record keeper real-time, Morningstar will not send an opt-out transaction in the batch transaction file.
- If Morningstar does not receive a real-time confirmation of the real-time opt-out transaction, Morningstar will send the opt-out transaction in the batch transaction file.
- If the user is opted-out and is confirned by the record keeper, the record keeper should not send this user in the batch opt-out file. The batch opt-out file should only include users cancelling service outside of the Retirement Manager interface.
**For users enrolling in Managed Accounts, we will send back an opt-in transaction letting the client know the user is opting into Managed Accounts. This type of transaction is sent real-time for real-time opt-in and via batch for batch opt-in, and will be indicated by a service option of ‘QualMRP’, but will not include fund reallocations or future allocations. These will later get a batch transaction for fund reallocations and future allocations, as described above.
If the user is already enrolled in Managed Accounts, updates information through the Retirement Manager web application, and submits a transaction, transaction is always sent back in a batch file. In this case, no real-time transaction is sent at all (neither a regular real-time transaction nor the real-time opt-in transaction letting the client know that the user is opted into Managed Accounts). This scenario does not apply if the user is switching to a different service option.
Direct transactions must be used for any client offering a Managed Account service option. In addition, instructions regarding company stock, when applicable, will be included in the transaction string and must be accepted and processed by the client.

For clients using direct transactions, the client real-time confirmation receipt file will be sent to Morningstar and information from that file will be displayed on the web application to confirm that the client has received the transactions and have queued transaction to be processed.

The client batch confirmation reconciliation file will be sent to Morningstar for those participants that enroll in Managed Accounts real-time (via the website) or batch. This file does not apply to Advice or Guidance service options. This file will indicate which transactions were successfully processed. Morningstar has an automatic checking process that will reconcile transactions. If Morningstar has not received a client batch confirmation receipt within a specified amount of time, we will send the client a transactions missing email with error reports.

Batch Output Spec

Purpose of This Document for Batch Transactions

Morningstar Investment Management LLC uses the data collected from a provider (in the Plan and Participant Data Batch XML files) to generate recommendations to be provided to participants by the provider or sponsor. The recommendations and other results of this program are sent to the provider in XML format. This document outlines the specific data points that will be included in this XML file. The batch output spec will be used with Managed Accounts during quarterly rebalancing, batch updates, and when consultants specifically review a user’s recommendations from the web application.

Delivery Method of Batch Files

Morningstar will prepare the batch XML file according to the schema specifications. Files will be transferred to the client using an FTP service. Morningstar will post the files to our FTP site, and the client will retrieve the files from the FTP site. One of two security methods will be used. Either the files will be PGP encrypted before being put onto the Morningstar FTP site, or SSL FTP will be used.

Naming Convention for Batch Files

The file name is “ClientID_MA_transaction_MMDDYYYY_HHMM_server_filenum.xml” for the transaction file that Morningstar will put on the FTP site. The clientID is the code assigned by Morningstar. The filenum value, if present, represents how many transaction files were generated for the clientID. This is an optional value that will only be appended to the filename if the client has requested a limit to the number of records per transaction file.

Real-Time Output Spec

Purpose of This Document for Real-Time Transactions Morningstar Investment Management LLC uses the data collected from the record keeper (in the Plan Batch and Participant Real-time XML Files) and the web application to generate recommendations to be provided to participants by the provider or sponsor. The recommendations and other results of the program are sent to the provider in XML format. This document outlines the specific data points that will be included in this real-time transaction string.

Delivery Method of Real-Time Files Morningstar will prepare the real-time transaction string according to the schema specifications. The transaction will be transferred to the client when the user enrolls in Managed Accounts or adjusts data for Quantitative Managed Accounts, Advice, or Guidance using the web application. Morningstar will use the transurl sent during Seamless Login as the URL to which transactions are sent. The transaction instructions are sent in XML format. This transaction XML string will include instructions for realigning current balances, setting future contributions, and adjusting contribution rates.

Direct Method (Server to server communication) Morningstar passes the transaction instructions to your server using HTTPS POST for processing. Your parsing program will grab the fund identifiers, percentages, and contribution rates and implement the transactions.

Client Real-time Participant Transaction Confirmation of Receipt Files

The client will send back a real-time response with the confirmation that the transaction was received by the client and was processed or queued to be processed in the case of direct transactions. This is the DTD:

<!--**********************************************************************-->
<!-- Filename: CFTransConfirm.dtd  -->
<!--  -->
<!-- Version 1.0 8/8/03  -->
<!--**********************************************************************-->
<!ELEMENT TransXML(ReturnCode,ConfirmNumber,ConfirmInformation)>
<!ELEMENT ReturnCode (#PCDATA)>
<!ELEMENT ConfirmNumber (#PCDATA)>
<!ELEMENT ConfirmInformation (#PCDATA)>

Morningstar will store the value given by ReturnCode, and display the information given in ConfirmInformation to the participant. You will control the content of the confirmation page that is displayed by us to the participant. Please note that the element names are case sensitive.

ReturnCode – Return status of transaction processing. This field is used to indicate whether the transaction was processed or queued to be processed on your site. Anything other than 0 indicates to us that there was an error in processing, and the transaction instructions were not completed. We will display an error message on the web application indicating that an error has occurred and to contact the client for more information.

ConfirmNumber – This element was carried over from the legacy platform and is not used in Retirement Manager.

ConfirmInformation – This is html code and text that we display to the participant indicating the results of the transaction. It may include text indicating the transaction was processed successfully, or error status, etc. You control the content and format--we simply serve the page to the participant.

Detailed Element Descriptions

Transaction Data: Detailed Element Descriptions The following table lists detailed element descriptions for all fields that may contain data in the transaction XML file. Please note the following:

Some data points are required in the schema and must be included in the transaction. These fields will be in bold font in the ‘Element Name’ column.
Some data points may be required in other special situations and are labeled accordingly in the ‘Comments’ column.
To confirm that the correct data was used to generate the results sent in this transaction file, some data points that are collected from the client in the plan and participant XML files are also sent back as part of this transaction XML file. These will be designated as such in the ‘Comments’ column.

Important Notes:

All data elements will be included in the transaction with a value, if the data is available. If the value is ‘null’ for a data point, that section will be omitted.
In addition to the data elements listed here, the following elements may also be sent in the real-time transaction, preceding the Transaction node. Cookie – The value of this element is the value of the cookie parameter sent by the client in seamless login (if applicable). If the client does not send a cookie value in seamless login, this element will not be included in the transaction. sid – Session ID. The value of this element is the value of the sid parameter sent by the client in seamless login (if applicable), or Morningstar’s internal session ID value.

Loading table data...

Client Batch Confirmation Reconciliation Files

Confirmation Reconciliation of Managed Accounts Transactions The provider, sponsor, or record-keeper must send back a file in XML format confirming which Managed Accounts service option transactions were successfully processed by the client. This applies to all Managed Accounts transaction options, including QualMRP as well as None (for participants who have opted out of Managed Accounts and received an opt out transaction). XML format is preferred. The file needs to contain a list of the Social Security Numbers of users who transacted successfully, the timestamp from the Morningstar output file that was sent to the client, the tracking ID from the transaction file, and the number of transactions that were implemented. The file should be sent back to the Morningstar FTP site. The name for the file should be clientID_MA_confirm_date_timestamp (timestamp in hhmmss).

Here is the schema for the file and a sample file:

XML Format – Schema:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xs:schema xmlns="http://www.morningstar.com/clearfuture" xmlns:xs="http://www.w3.org/2001/XMLSchema"targetNamespace="http://www.morningstar.com/clearfuture" elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:element name="CFCONFIRMATION">
		<xs:complexType>
			<xs:sequence>
				<xs:element ref="COMPANYID"/>
				<xs:element ref="CONFIRMATIONNUM" minOccurs="0"/>
				<xs:element ref="FILENAME" minOccurs="0"/>
				<xs:element ref="PARTICIPANTCONF" maxOccurs="unbounded"/>
				<xs:element ref="NUMPARTICIPANT"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
	<xs:element name="COMPANYID">
		<xs:complexType mixed="true"/>
	</xs:element>
	<xs:element name="TIMESTAMP">
		<xs:complexType mixed="true"/>
	</xs:element>
	<xs:element name="TRACKINGID">
		<xs:complexType mixed="true"/>
	</xs:element>
	<xs:element name="CONFIRMATIONNUM">
		<xs:complexType mixed="true"/>
	</xs:element>
	<xs:element name="FILENAME">
		<xs:complexType mixed="true"/>
	</xs:element>
	<xs:element name="NUMPARTICIPANT">
		<xs:complexType mixed="true"/>
	</xs:element>
	<xs:element name="SSN">
		<xs:complexType mixed="true"/>
	</xs:element>
	<xs:element name="PARTICIPANTCONF">
		<xs:complexType>
			<xs:sequence>
				<xs:element ref="SSN"/>
				<xs:element ref="TIMESTAMP"/>
				<xs:element ref="TRACKINGID"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
</xs:schema>

Sample Confirmation File:

In the sample, the following data elements are used:

COMPANYID – The company identifier
SSN – Participant’s social security number
TIMESTAMP – the timestamp from the Morningstar output file that was sent to the client
TRACKINGID – the distinct transaction identifier from Morningstar that is used for reconciling transactions
NUMPARTICIPANT – the number of participants in the file. A user should be counted multiple times here if he appears in the file more than once. For example, if SSN 222-22-2222 is in the file with 3 different transactions, he will be counted 3 times here.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE CFCONFIRMATION>
<CFCONFIRMATION>
	<COMPANYID>abcd</COMPANYID>
	<PARTICIPANTCONF>
		<SSN>123456789</SSN>
		<TIMESTAMP>**2004-12-17T09:30:47**</TIMESTAMP>
		<TRACKINGID>**936DA01F-9ABD-4d9d-80C7-02AF85C823L6**</TRACKINGID>
	</PARTICIPANTCONF>
	<PARTICIPANTCONF>
		<SSN>987654321</SSN>
		<TIMESTAMP>**2004-12-17T09:30:47**</TIMESTAMP>
		<TRACKINGID>**366DA01F-J7BD-4d9U-00C7-02AF85C823L8**</TRACKINGID>
	</PARTICIPANTCONF>
	<PARTICIPANTCONF>
		<SSN>555555555</SSN>
		<TIMESTAMP>**2004-12-17T09:30:47**</TIMESTAMP>
		<TRACKINGID>**df34A01F-8ABk-5d9d-80C7-iUAF85C823L6**</TRACKINGID>
	</PARTICIPANTCONF>
	<NUMPARTICIPANT>3</NUMPARTICIPANT>
</CFCONFIRMATION>

Client Confirm File Process for Managed Accounts

The client confirmation files will be on the Morningstar FTP site where all the confirmation files are located. The files will be named as clientID_MA_confirm_date_timestamp (Timestamp in hhmmss).

The application will check the FTP site for client transaction confirmation files. An automated process will run and compare the incoming client confirmation file against the managed accounts batch transactions that have not yet been reconciled.

The reconciliation process will automatically check each confirmation in the client confirm file against the managed accounts batch transactions that have been sent out.

In the event that a confirmation file is corrupt or the whole file is in the wrong format, an email will be automatically sent to the client teams informing them about this issue (see format below).

Every time we receive a confirmation file from the client, we’ll check to see if any transactions have not been reconciled, and add any such transactions to the error report. This error report will be added to the FTP site.

Format of Confirmation error email: This email will be generated if a client confirmation file is corrupt or in the wrong format or any other discrepancy exists with the confirm file. This will not have any error report attached but will let the client teams know about an incorrect file.

Emails sent to: Client teams and clients.

Email subject: Confirm File Error

Email text: The XXX confirm file for YYY is either corrupt or in the wrong format. Please check the file and correct the errors or replace the file with a new one. The reconciliation process cannot be completed until the file is corrected.

If you have any questions regarding this email, please contact your Relationship Manager. Do not reply to this e-mail address. Any messages sent to this address will be automatically deleted.

Thank you, The Morningstar Team

(XXX is the confirm file name, YYY is the Company ID.)

If a user has not been reconciled, this email will be sent:

Emails sent to: Client teams and clients.

Email subject: Missing Participants Reconciliation Report

Email text: The XXX confirm file for YYY is either corrupt or in the wrong format. Please check the file and correct the errors or replace the file with a new one. The reconciliation process cannot be completed until the file is corrected.

If you have any questions regarding this email, please contact your Relationship Manager. Do not reply to this e-mail address. Any messages sent to this address will be automatically deleted.

Thank you, The Morningstar Team

(YYY is the number of participants in the file)

Format of Transactions Missing Email with Error Report:

The error report will be in csv. format and will contain the following fields:

Client ID
Missing participant SSN
PlanID
Date/Time stamp of transaction
TrackingID
ErrorMsg – This will be “Could not find Confirmation in Database”

For Qualitative Managed Accounts users marked as ‘Do Not Implement’

As part of the qualitative Managed Accounts process, each deviated user’s transaction is reviewed and then implemented by a consultant. At times, however, there may be participants for whom the consultants are unable to implement a transaction. A participant can be marked as a “Do Not Implement” participant for various reasons. One reason could be that the participant excluded the only cash fund in the fund line-up which is required for plan compatibility. In this case, a consultant may select to mark the participant as a “Do Not Implement” participant and no transaction would be generated for the participant. These participants would also appear in a report that can be posted to the client site.

Format of Do Not Implement report:

The error report will be in .xml format and will contain the following fields:

CompanyID
Timestamp
SSN
PLANID

Note: This will contain the explanation of why the consultants could not implement the participant

The naming convention for the report is: clientID_MA_nonImplementUserReport_date_timestamp.xml (timestamp in hhmmss).

Example of the Do Not Implement report:

<CFUSERREPORT>
<COMPANYID>DEMO</COMPANYID>
<TIMESTAMP>1/23/2007 11:42:49 AM</TIMESTAMP>
<USER><SSN>SampleUser1</SSN><PLANID>PLAN123</PLANID><NOTE>Too many excluded funds</NOTE></USER>
<USER><SSN>123456789</SSN><PLANID>PLAN123</PLANID><NOTE>User excluded only cash fund available</NOTE></USER>
</CFUSERREPORT>

Transaction XML Examples

Sample Transaction XML Document 1

The following contents would be included in the transaction file for an integrated Managed Accounts user.

<Transaction ClientID="**DEMO**" TimeStamp="**2005-08-02T09:16:10**">
	<UserTransaction TrackingID="**ce135f81-ab4b-4dfa-9b5b-f96831e21136**" UserID="**TransSample**" FirstName="**Transaction**"LastName="**Sample**" PhoneRepID="" TimeStamp="**2005-08-02T09:16:10**">
		<Account ServiceOption="**QuantMRP**" Type="**401K**" TPAID="" PlanID="**DWHSEMIN**" Status="**Active**">
			<PretaxContriRate Amount="**5000**" Rate="**10.00**"/>
			<PosttaxContriRate Amount="**1000**" Rate="**2.00**"/>
			<Catchup50Years Amount="**500**" Rate="**1**" Roth=”**True**”/>
			<CatchupLongTerm Amount="**1000**" Rate="**2**"/>
			<Brkg/>
			<CSTarget>
				<CS Target="**5**" ID="**_CSTK**"/>
			</CSTarget>
			<Reallocation>
				<Security TransactionID="**BRWIX**" Perc="**25**" IsCS="**false**"/>
				<Security TransactionID="**HACAX**" Perc="**10**" IsCS="**false**"/>
				<Security TransactionID="**VWIGX**" Perc="**4**" IsCS="**false**"/>
				<Security TransactionID="**AADBX**" Perc="**26**" IsCS="**false**"/>
				<Security TransactionID="**PTTRX**" Perc="**24**" IsCS="**false**"/>
				<Security TransactionID="**_CSTK**" Perc="**11**" IsCS="**true**"/>
			</Reallocation>
			<FutureElection>
				<Security TransactionID="**BRWIX**" Perc="**25**" IsCS="**false**"/>
				<Security TransactionID="**HACAX**" Perc="**10**" IsCS="**false**"/>
				<Security TransactionID="**VWIGX**" Perc="**4**" IsCS="**false**"/>
				<Security TransactionID="**AADBX**" Perc="**26**" IsCS="**false**"/>
				<Security TransactionID="**PTTRX**" Perc="**24**" IsCS="**false**"/>
				<Security TransactionID="**SLASX**" Perc="**11**" IsCS="**false**"/>
			</FutureElection>
		</Account>
		<Account ServiceOption="**QuantMRP**" Type="**NonQual**" TPAID="" PlanID="**123456**" Status="**Active**">
			<PretaxContriRate Amount="**5050**" Rate="**10.00**"/>
			<Catchup50Years Amount="**1000**" Rate="**1**"/>
			<CatchupLongTerm Amount="**1000**" Rate="**2**"/>
			<Brkg/>
			<CSTarget>
				<CS Target="**0**" ID="**_CSTK**"/>
			</CSTarget>
			<Reallocation>
				<Security TransactionID="**BRWIX**" Perc="**25**" IsCS="**false**"/>
				<Security TransactionID="**HACAX**" Perc="**10**" IsCS="**false**"/>
				<Security TransactionID="**VWIGX**" Perc="**4**" IsCS="**false**"/>
				<Security TransactionID="**AADBX**" Perc="**26**" IsCS="**false**"/>
				<Security TransactionID="**PTTRX**" Perc="**24**" IsCS="**false**"/>
				<Security TransactionID="**_CSTK**" Perc="**11**" IsCS="**true**"/>
			</Reallocation>
			<FutureElection>
				<Security TransactionID="**BRWIX**" Perc="**25**" IsCS="**false**"/>
				<Security TransactionID="**HACAX**" Perc="**10**" IsCS="**false**"/>
				<Security TransactionID="**VWIGX**" Perc="**4**" IsCS="**false**"/>
				<Security TransactionID="**AADBX**" Perc="**26**" IsCS="**false**"/>
				<Security TransactionID="**PTTRX**" Perc="**24**" IsCS="**false**"/>
				<Security TransactionID="**SLASX**" Perc="**11**" IsCS="**false**"/>
			</FutureElection>
		</Account>
	</UserTransaction>
</Transaction>

Sample Transaction XML Document 2

The following contents would appear in a transaction file for a user who receives transactions but does not have his current portfolio rebalanced due to threshold checking.

<Transaction  TimeStamp="**2004-12-17T09:30:47**" ClientID="**ABCD**">
	<UserTransaction TrackingID="**936DA01F-9ABD-4d9d-80C7-02AF85C823L6**" UserID="**111111111**" FirstName="**John**" LastName="**Smith**"PhoneRepID="**45851**" TimeStamp="**2005-08-02T09:16:10**">
		<Account ServiceOption="**QuantMRP**" Type="**401K**" TPAID="" PlanID="**123444**" Status="**Active**">
			<PretaxContriRate Rate="**10.00**" Amount="**10000**" />
			<Catchup50Years Rate="**2**" Amount="**2000**" />
			<CSTarget>
				<CS  ID="**CSTK**" Target="**3**" />
			</CSTarget>
			<FutureElection>
				<Security  TransactionID="**Fund1**" Perc="**15**" IsCS="**false**" />
				<Security  TransactionID="**Fund2**" Perc="**20**" IsCS="**false**" />
				<Security  TransactionID="**Fund3**" Perc="**65** " IsCS="**false**" />
			</FutureElection>
		</Account>
	</UserTransaction>
</Transaction>

Sample Transaction XML Document 3

The following contents would appear in a real-time transaction file for a user who enrolled into the Qualitative Managed Accounts service option from the Retirement Manager interface (real-time opt-in transaction):

<Transaction TimeStamp="2009-01-28T16:30:59" ClientID="DEVP20">
	<UserTransaction TrackingID="cebd31eb-ed1b-4382-a57b-a94b53fb9f50" UserID="RealTImeQualitativeMA" FirstName="CurFutMax"LastName="Case1UI" TimeStamp="2009-01-28T16:30:59">
		<Account PlanID="AssetAllocationPlan" ServiceOption="QualMRP" Type="401K" Status="Active">
			<PretaxContriRate Rate="7.00" Amount="3150.00"/>
			<PosttaxContriRate Rate="2.00" Amount="900.00"/>
		</Account>
	</UserTransaction>
</Transaction>

Sample Transaction XML Document 4

The following contents would appear in a transaction file for a user who is opting out of a service option (opt-out transaction):

<Transaction TimeStamp="2007-02-14T12:12:37" ClientID="DEVP8">
	<UserTransaction TrackingID="d528b22d-1756-49b6-8792-3e2fa22c3eb3" UserID="MigrationTextDEVP8XX2AccW"FirstName="METHODOLOGYDEV8" LastName="SIMPLE CASE" TimeStamp="2007-02-14T12:12:37">
		<Account PlanID="FPLAN1" ServiceOption="NONE" Type="401K"/>
	</UserTransaction>
</Transaction>

Sample Transaction XML Document 5

If the TransIncContriFrequency flag is set to False,then the following contents would appear in transaction file for a user.We should not show the ContriFrequency node in the transaction XML:

<Transaction TimeStamp="2025-04-11T08:29:35.0228124-05:00" ClientID="INGG">
  <UserTransaction TrackingID="cd23ecab-ce16-4be7-8a38-dc8e65444f1a" UserID="20250410-INGG-gj0dw" FirstName="Stein" LastName="TDF_PIMCO" TimeStamp="2025-04-11T08:29:35">
    <Account PlanID="TEST_PIMCO_2022" ServiceOption="QualMRP" Type="401K" Status="Inactive">
      <Reallocation>
        <Security TransactionID="72203L503" Perc="80" IsCS="false" />
        <Security TransactionID="72203L602" Perc="20" IsCS="false" />
      </Reallocation>
      <FutureElection>
        <Security TransactionID="72203L503" Perc="80" IsCS="false" />
        <Security TransactionID="72203L602" Perc="20" IsCS="false" />
      </FutureElection>
    </Account>
  </UserTransaction>
</Transaction>

Sample Transaction XML Document 6

If the TransIncContriFrequency flag is set to True,then the following contents would appear in transaction file for a user.Include the ContriFrequency node from the PPT at the InstAccount level in the transaction XML at the Account level:

<Transaction TimeStamp="2025-04-11T08:41:13.4199909-05:00" ClientID="INGG">
  <UserTransaction TrackingID="f5b6ce58-9940-4bd2-b3f5-5a2372c8957c" UserID="20250410-INGG-hv0kv" FirstName="Stein" LastName="TDF_PIMCO" TimeStamp="2025-04-11T08:41:13">
    <Account PlanID="TEST_PIMCO_2022" ServiceOption="QualMRP" Type="401K" Status="Inactive" ContriFrequency="Weekly">
      <Reallocation>
        <Security TransactionID="72203L503" Perc="80" IsCS="false" />
        <Security TransactionID="72203L602" Perc="20" IsCS="false" />
      </Reallocation>
      <FutureElection>
        <Security TransactionID="72203L503" Perc="80" IsCS="false" />
        <Security TransactionID="72203L602" Perc="20" IsCS="false" />
      </FutureElection>
    </Account>
  </UserTransaction>
</Transaction>

Sample Transaction XML Document 7

If the contrifrequency node is not provided in the PPT and the TransIncContriFrequency Flag is set to True then ContriFrequency should be set to Annual and included as Annual in the transaction XML.The default value for ContriFrequency should be Annual.:

<Transaction TimeStamp="2025-04-11T08:43:18.921359-05:00" ClientID="INGG">
  <UserTransaction TrackingID="44cfa3b1-e263-4059-b302-59dd1a1b1b0a" UserID="20250410-INGG-oujck" FirstName="Stein" LastName="TDF_PIMCO" TimeStamp="2025-04-11T08:43:18">
    <Account PlanID="TEST_PIMCO_2022" ServiceOption="QualMRP" Type="401K" Status="Inactive" ContriFrequency="Annual">
      <Reallocation>
        <Security TransactionID="72203L503" Perc="80" IsCS="false" />
        <Security TransactionID="72203L602" Perc="20" IsCS="false" />
      </Reallocation>
      <FutureElection>
        <Security TransactionID="72203L503" Perc="80" IsCS="false" />
        <Security TransactionID="72203L602" Perc="20" IsCS="false" />
      </FutureElection>
    </Account>
  </UserTransaction>
</Transaction>

# Transactions Output Specification — XML

# General Information

# Overview of File Types

# Real-Time Transaction String

# Batch Transaction File

# Batch Output Spec

# Real-Time Output Spec

# Detailed Element Descriptions

# Client Batch Confirmation Reconciliation Files

# Client Confirm File Process for Managed Accounts

# Transaction XML Examples

# Sample Transaction XML Document 1

# Sample Transaction XML Document 2

# Sample Transaction XML Document 3

# Sample Transaction XML Document 4

# Sample Transaction XML Document 5

# Sample Transaction XML Document 6

# Sample Transaction XML Document 7