# FIX STP API

The Integral FIX STP API includes the following messages:

* From Integral when a trade is done ([Trade Capture Report](#trade-capture-report)).
* Sent by you for STP message recovery ([Trade Capture Report Request](#trade-capture-report-request)).
* Sent by you with data from further processing in your organization, such as a trade ID assigned by your back office ([Trade Capture Report Ack](#trade-capture-report-ack)).


## Implementation details

This specification is based on the FIX 4.3 standard (https://www.fixtrading.org/) and has been adapted to Integral’s requirements. Users should have a basic knowledge of the FIX protocol and FIX messaging.

The Integral FIX STP API only supports messages, component blocks, and fields that are described in this document. All fields not in this document are ignored by Integral, including fields that are required or conditionally required by the FIX protocol.

### Sessions

TheIntegral FIX STP API operates on a single order session for sending and receiving STP messages. Customers initiate the order session.

Messages are transactional and persistent with guaranteed delivery, reflecting their business criticality. The server resends order session messages in response to a resend request from the customer app.

#### Session availability

Order sessions are available from 17:05:00 EST/EDT Sunday through 17:00:00 EST/EDT Friday.

Sessions are off-line for general maintenance daily from 17:00:00 EST/EDT until 17:05:00 EST/EDT Monday through Thursday.

The FIX sequence numbers for all sessions are reset during general maintenance times.

To successfully reconnect at 17:05 EST/EDT, customers must send a Logon message with a sequence number of “1” (one). Integral’s Logon response also has a sequence number of “1” (one).

Integral sends a Logout message at 17:00 EST/EDT. Upon receipt of this message, customers should disconnect by sending a Logout message.

#### Intra-session reconnections

For intra-session disconnections, Integral recommends using the next sequence number.

If a customer app requires sequence numbers reset, the app must send a Logon message with a sequence number of “1” (one) and the `ResetSeqNumFlag` (#141) set to “Y”. Integral replies with a Logon message with the sequence number set to “1” (one).

### Supported message set

The following message types are supported by the Integral FIX STP API. Any other message types are not applicable and may be rejected.

#### Supported session-level messages

Supported session-level messages 

| Direction | Message name | `MsgType` (#35)  | Message purpose |
|  --- | --- | --- | --- |
| In, Out | [Logon](#logon) | A | You initiate a FIX session.
Integral responds to a successful Logon request. |
| In, Out | [Logout](#logout) | 5 | You or Integral ends a FIX session. |
| In, Out | [Heartbeat](#heartbeat) | 0 | You or Integral signals the status of the communication link. This message should be used when no data has been sent for the number of seconds set by `HeartBtInt` (#108). |
| In, Out | [Test Request](#test-request) | 1 | You or Integral queries the status of the connection when no data message has been received for twice the number of seconds set by `HeartBtInt` (#108).The receiving party should always send a Heartbeat message in response to a Test Request message.
 |
| In, Out | [Session-level Reject](#session-level-reject) | 3 | You or Integral cannot process a message. |
| In, Out | [Resend Request](#resend-request) | 2 | You or Integral detects a gap in the number sequence `MsgSeqNum` (#34) and requests retransmission of messages. |
| In, Out | [Sequence Reset](#sequence-reset) | 4 | You or Integral resets `MsgSeqNum` (#34) after receiving a Resend Request. |


#### Supported business messages

The direction of the message is from your perspective.

Supported business messages 

| Direction | Message name  | `MsgType` (#35)  | Message purpose |
|  --- | --- | --- | --- |
| In | [Trade Capture Report](#trade-capture-report) | AE | Integral sends a done trade. |
| Out
 | [Trade Capture Report Request](#trade-capture-report-request)
 | AD
 | You send this message to  to query a trade’s status by specific trade ID or by a date/time range.
Normally, you should not have to send a Trade Capture Report Request because Integral sends a Trade Capture Report asynchronously when a trade is done. You should send a Trade Capture Report Request for reconciliation purposes if you think a trade download is missing or is incorrect.
 |
| Out | [Trade Capture Report Ack](#trade-capture-report-ack) | AR | You send this message to Integral after receiving a Trade Capture Report (#35=AE) to update a trade with data from further processing in your organization, such as a trade ID assigned by your back office. |


### Common message components

This section describes the features common to each message format in the Integral FIX STP API.

#### Terminology

EachIntegral FIX STP API message is comprised of message fields defined in this document. Each field has its own set of attributes including:

* Tag: field number.
* Field name: human-readable name for reference.
* Req’d: indicates if the field must be sent on the FIX message:
  * Y = required by the FIX protocol.
  * Y(API) = required by the FIX STP implementation.
  * N = optional for both the FIX STP and the FIX protocol.
  * C = conditional. Refer to the field’s description to determine applicability.
* Valid values: specific values accepted for this field.
* Description: brief description of the field.
* Type(length): FIX data type of the field and the maximum length of the field value.
* →: arrow indicates a field in a repeating group.


#### Standard header

Each message type sent over the Integral FIX STP API has a standard header component as described below. The header is abbreviated as <Standard header> in this document.

Standard header format 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| 8 | BeginString | Y | FIX4.3 or FIX4.4 | Identifies beginning of new message and protocol version. Must be the first field in the message. The message format must conform to the FIX 4.3 protocol, but the value “FIX4.4” is acceptable. | String(7) |
| 9 | BodyLength | Y | — | Message length (in bytes) forward to the `CheckSum` (#10) field. Must be the second field in the message. | int(6) |
| 35 | MsgType | Y | — | Defines the type of the message. Must be the third field in the message. | String(2) |
| 49 | SenderCompID | Y | — | This value is used to identify the firm sending the message. Should be set with the `SenderCompID` (#49) supplied by Integral for this FIX connection. | String(20) |
| 56 | TargetCompID | Y | — | This value is used to identify the firm receiving the message. Should be set with the `TargetCompID` (#56) supplied by Integral for this FIX connection. | String(20) |
| 34 | MsgSeqNum | Y | — | Integer message sequence number. | SeqNum(9) |
| 43 | PossDupFlag | N | Y=Possible Duplicate
N=Original Transmission | Indicates possible retransmission of message with this sequence number. Must be set to “Y” for messages sent in response to a Resend Request. | Boolean(1) |
| 52 | SendingTime | Y | — | Time the message was transmitted. Always expressed in UTC. | UTCTimestamp(21) |


#### Standard trailer

Each message type sent over the Integral FIX STP API also has a standard trailer component as described below. The header is abbreviated as <Standard trailer> in this document.

Standard trailer format 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| 10 | Checksum | Y | — | Three-byte checksum. Always the last tag in the message. Functions as an end-of-message delimiter. | String(3) |


## Administrative messages

### Logon

The customer sends a Logon message to establish a FIX session with Integral. If the Logon fails, Integral responds with a Logout message. The `Text` (#58) field of the Logout message contains the reason for the rejection of the Logon message.

Valid responses 

* Logon (#35=A)
* Logout (#35=5)


Message format 

Logon format 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=A | — |
| 98 | EncryptMethod | Y | 0=None | Always unencrypted | int(1) |
| 108 | HeartBtInt | Y | — | Heartbeat interval in seconds. The customer’s app determines the heartbeat interval. | int(3) |
| 141 | ResetSeqNumFlag | N | Y=Yes, reset sequence numbers
N=No | Indicates that both sides of the FIX session should reset sequence numbers. | Boolean(1) |
| 553 | Username | Y(API) | — | Should be set with the username supplied by Integral for this FIX connection. | String(20) |
| 554 | Password | Y(API) | — | Should be set with the password supplied by Integral for this FIX connection. | String(20) |
| <Standard trailer>  | Y | — | — | — |


### Logout

The customer sends a Logout message to end a session. Integral sends a single Logout message in response when all Logout related actions have been completed by Integral.

Valid responses 

* Logout (#35=5)


Message format 

Logout format 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=5 | — |
| 58 | Text | N | — | The reason for the Logon rejection. Only included for Logout messages in response to an invalid Logon message. | String(150) |
| <Standard trailer>  | Y | — | — | — |


### Heartbeat

Integral and the customer send a Heartbeat message in response to a Test Request message to ensure connectivity. The Heartbeat message includes the `TestReqID` (#112) value from the received Test Request.

Valid responses 

* None


Message format 

Heartbeat format 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=0 | — |
| 112 | TestReqID | C | — | Required if heartbeat message is generated in response to a Test Request message. In this case, this tag must contain the TestReqID that was sent in the Test Request message. | String(20) |
| <Standard trailer>  | Y | — | — | — |


### Test Request

Integral and the customer send a Test Request message to force a heartbeat from the receiving app. The receiving app responds with a Heartbeat message that includes the `TestReqID` (#112) value from the received Test Request.

Valid responses 

* Heartbeat (#35=0)


Message format 

Test Request format 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=1 | — |
| 112 | TestReqID | C | — | This identifier should be returned in the Heartbeat response. | String(20) |
| <Standard trailer>  | Y | — | — | — |


### Session-level Reject

A Session-level Reject message is sent by Integral when a message is received but cannot be processed.

Valid responses 

* None


Message format 

Session-level Reject format 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=3 | — |
| 45 | RefSeqNum | Y | — | `MsgSeqNum` (#34) of the message being rejected. | int(9) |
| 371 | RefTagID | N | — | Tag ID of the field being referenced. | int(4) |
| 372 | RefMsgType | Y(API) | — | The `MsgType` (#35) of the FIX message being rejected. | String(2) |
| 373 | SessionRejectReason | Y(API) | — | Rejection code. | int(4) |
| <Standard trailer>  | Y | — | — | — |


### Resend Request

The receiving app sends a Resend Request message to initiate the retransmission of messages, typically when it detects a gap in the message sequence number. The sender can request a single message or a range of messages.

The Resend Request message applies only to persistent sessions.

Valid responses 

* Various


Message format 

Resend Request format 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=2 | — |
| 7 | BeginSeqNo | Y | — | Message sequence number of the first message in range to be re-sent. | int(9) |
| 16 | EndSeqNo | Y | — | Message sequence number of the last message to be re-sent. | int(9) |
| <Standard trailer>  | Y | — | — | — |


### Sequence Reset

The sequence reset messages forces the synchronization of sequence numbers on the sending and receiving sides in the event of lost messages.

Valid responses 

* None


Message format 

Sequence Reset format 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=4 | — |
| 123 | GapFillFlag | Y | Y | Indicates that the Sequence Reset message is replacing the admin or application messages, which are not re-sent. | Boolean(1) |
| 36 | NewSeqNo | Y | — | New sequence number. This number must be greater than either the `BeginSeqNo` (#16) or the `EndSeqNo` (#7) on the Resend Request message that prompted the sequence number reset. | SeqNum(9) |
| <Standard trailer>  | Y | — | — | — |


## STP messages

### Message reliability and reconciliation

Integral uses persistent FIX sessions for reliable message delivery.

If an STP message is in-process and you are disconnected, FIX transport attempts message delivery when you reconnect.

Your app should also use persistent FIX sessions to process incoming messages and persist the last message’s sequence number to enable reconciliation.

Furthermore, Integral strongly recommends that your app implements the Trade Capture Report Request message workflow to fill any gaps between disconnect and reconnect ([Trade Capture Report Request](#trade-capture-report-request)).

### Trade Capture Report Request

You send this message to Integral to query a trade’s status by specific trade ID or by a date/time range.

Normally, you should not have to send a Trade Capture Report Request because Integral sends a Trade Capture Report asynchronously when a trade is done. You should send a Trade Capture Report Request for reconciliation purposes if you think a trade download is missing or is incorrect.

The request can be sent for a specific trade or for all trades in a date range:

* Specific trade (request by ID):
Set `ExecID` (#17) to the trade’s ID. Date-range related fields are ignored: `NoDates` (#580), `TradeDate` (#75) and `TransactTime` (#60).
* All trades in a date range:
  * Do not include `ExecID` (#17) or set to null.
  * `NoDates` (#580) must be set to “2”, indicating a range with a start date/time and end date/time.
  * For queries by trade date only, repeat `TradeDate` (#75) twice for a start date and end date.
  * For queries by trade date and time, repeat `TransactTime` (#60) twice for the start date/time and the end date/time.
  * If both `TradeDate` (#75) and `TransactTime` (#60) are specified, then the `TradeDate` (#75) field is ignored.


Valid responses 

* Trade Capture Report


Message format 

Trade Capture Report Request format 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=AD | — |
| 17  | ExecID | C | — | A specific trading app trade ID (transaction ID).
If `ExecID` (#17) is specified on the message, `NoDates` (#580), `TradeDate` (#75) and `TransactTime` (#60) are ignored. If you want to query for trades within a date/time range, leave empty. | String(20) |
| 568  | TradeRequestID | Y | — | The unique ID of the Trade Capture Report Request message. | String(20) |
| 569  | TradeRequestType | Y | — | Valid values:
0=All trades
1=Matched trades matching criteria provided on request
2=Unmatched trades that match criteria
3=Unreported trades that match criteria
4=Advisories that match criteria | int(1) |
| 580  | NoDates | N | 2 | Group of fields that represent the begin and end of a date range. Value must be 2 for a date or time range.
For queries by trade date only, the `TradeDate` (#75) field is repeated twice. The first instance is the start date and the second instance is the end date. For queries by trade date and time, the `TransactTime` (#60) field is repeated twice. The first instance is the start date/time and the second instance is the end date/time. If both the `TradeDate` (#75) field and `TransactTime` (#60) are specified on the request, then the `TradeDate` (#75) field is ignored. | NumInGroup(1) |
| → | 75 | TradeDate | C | — | Trade date in format *YYYYMMDD*. Used to request trades by trade date only. The `TradeDate` (#75) field is repeated twice. The first instance is the start date and the second instance is the end date. | LocalMktDate(8) |
| → | 60 | TransactTime | C | — | The timestamp of the trade in GMT in the format *YYYYMMDD-hh:mm:ss.sss*. Used to request trades by trade date and time. The `TransactTime` (#60) field is repeated twice. The first instance is the start date/time and the second instance is the end date/time. If both the `TradeDate` (#75) field and `TransactTime` (#60) are specified on the request, then the `TradeDate` (#75) field is ignored. | UTCTimestamp(21) |
| <Standard trailer>  | Y | — | — | — |


TheIntegral FIX STP API only supports fields that are described in this document. All fields not in this document should be ignored.

### Trade Capture Report

Valid responses 

* None


Message format 

If your trading is subject to regulatory requirements, such as MiFID or EMIR, see [Regulatory data (MiFID, EMIR, CFTC)](#regulatory-data-mifid-emir-cftc) for regulation-specific fields.

Trade Capture Report format 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=AE | — |
| 50  | SenderSubID | Y | — | Counterparty A legal entity ID of the trade. By convention, this is the taker of the trade.
If Counterparty A receives the message, this is Counterparty A’s legal entity ID.
If Counterparty B or another counterparty receives the message, this is the message receiver’s trading party ID or settlement code for Counterparty A’s legal entity. | String(20) |
| 57  | TargetSubID | Y | — | Counterparty B legal entity ID of the trade.
By convention, this is the maker or liquidity provider of the trade.
If Counterparty B receives the message, this is Counterparty B’s legal entity ID.
If Counterparty A or another counterparty receives the message, this is the message receiver’s trading party ID or settlement code for Counterparty B’s legal entity.This field can be amended and may take multiple values through the STP workflow.
 | String(20) |
| 115  | OnBehalfOfCompID | Y | — | Counterparty B organization ID of the trade. By convention, this is the maker of the trade.This field cannot be amended.
 | String(20) |
| 116  | OnBehalfOfSubID | N | — | When the stream LP trading workflow is used, the organization ID of the stream LP is sent in this field. | String(20) |
| 128  | DeliverToCompID | Y | — | Counterparty A organization ID of the trade. By convention, this is the taker of the trade. | String(20) |
| 11  | ClOrdID | N | — | The unique ID assigned by the client to the order, the `ClOrdID` (#11) of the originating New Order – Single message. Only included in the STP message if the organization is configured to include the order ID on the STP download. | String(11) |
| 12  | Commission | N | — | The previous day's end-of-date (EOD) rate expressed as a mid rate.
If USD is one of the currency pairs, the rate should be 1.0 since the USD amount is used for billing.
If USD is not one of the currency pairs, then the rate that determines the USD amount should be used. For example, for a EUR/JPY trade, if the dealt currency is EUR, then the EOD rate should be the EUR/USD rate. If the dealt currency is JPY, then the rate should be the JPY/USD rate. If JPY/USD rate is not available, then the rate should be obtained from the USD/JPY rate (JPY/USD rate = 1 divided by the USD/JPY rate). | Amt(20) |
| 13  | CommType | N | 1=per unit (currency) | Commission type. | char(1) |
| 15  | Currency | Y | — | Dealt currency. | Currency(3) |
| 17  | ExecID | Y | — | The trading app’s trade ID. | String(20) |
| 31  | LastPx | Y | — | All in price of the trade.
For Spot, the same as `LastSpotRate` (#194).
For outrights and swaps, the sum of `LastSpotRate` (#194) and `LastForwardPoints` (#195). | Price(20) |
| 32  | LastQty | Y | — | The dealt amount in terms of `Currency` (#15). | Qty(20) |
| 37  | OrderID | N | — | The order’s ID as assigned by the FIX server. Only included in the STP message if the organization is configured to include the order ID on the STP download. | String(20) |
| 38  | OrderQty | Y | — | Dealt amount specified in the `Currency` (#15). Same as `LastQty` (#32). | Qty(20) |
| 44  | Price | Y | — | All in price of the trade, same as `LastPx` (#31). | Price(20) |
| 55  | Symbol | Y | — | Currency pair symbol. | String(35) |
| 58  | Text | N | — | Settlement instructions, if any, that were included with the request to trade. Currently used for RFS workflow only. | String(100) |
| 60  | TransactTime | Y | — | The business execution timestamp (the date and time of the order match) in the format *YYYYMMDD-hh:mm:ss.sss*. | UTCTimestamp(21) |
| 64  | SettlDate | Y | — | Specific date of trade in the format *YYYYMMDD*.* FX spot, outright: Value date.
* FX swap: Near leg value date.

 | LocalMktDate(10) |
| 75  | TradeDate | Y | — | Trade date in the format *YYYYMMDD*. | LocalMktDate(8) |
| 119  | SettlCurrAmt | Y | — | Settled amount in terms of `SettlCurrency` (#120). | Amt(20) |
| 120  | SettlCurrency | Y | — | Settled currency. | Currency(3) |
| 136  | NoMiscFees | N | 1 | Number of repeating groups of miscellaneous fees. | NumInGroup(1) |
| → | 137 | MiscFeeAmt | N | — | Amount of fees in terms of the settled currency. | Qty(20) |
| → | 138 | MiscFeeCurr | N | — | Currency of the fee (settled currency). | String(2) |
| → | 139 | MiscFeeType | N | 4=Exchange fees | The type of fee. Always 4 (exchange fees). | char(1) |
| 150  | ExecType | N | 5=Replace | The state of the included trade. | char(1) |
| 167  | SecurityType | Y | * FOR
* FXNDF
* FXFWD
* FXNDS
* FXSWAP

 | The security type:* FOR: Foreign Exchange Contract. By default, for a given instrument, quote convention settings on the server automatically determine the trade type.

When the system is configured to accept both deliverable and non-deliverable trade types for specific instruments, you can specify the following values as execution instructions that indicate how your request is processed (see [Quote Request](#quote-request)):
* FXNDF: non-deliverable forward.
* FXFWD: deliverable forward.
* FXNDS: non-deliverable swap.
* FXSWAP: deliverable swap.

 | String(20) |
| 192  | OrderQty2 | N | — | FX spot, outright: Not applicable.
FX swap: Far leg dealt amount denominated in `Currency` (#15). | Qty(20) |
| 193  | SettlDate2 | N | * Tenor
* Broken date

 | FX spot, outright: Not applicable.
FX swap: The far leg value date. The field contains either a broken date in *YYYYMMDD* format or a standard tenor symbol:* Today or TOD.
* ON.
* TN.
* SP.
* SN.
* *n*D: A number of days from SPOT (for example, 1D, 2D, 10D).
* *n*W: A number of weeks from SPOT (for example, 1W, 2W, 3W).
* *n*M: A number of months from SPOT (for example, 1M, 2M, 3M).
* *n*Y: A number of years from SPOT (for example, 1Y, 2Y, 3Y).
* *n*IMM: The next International Monetary Market (IMM) settlement date. IMM dates are the third Wednesday of the last month of every quarter (March, June, September, December). Entering `IMM` results in the next IMM date on or after the spot date. Entering `2IMM` results in two IMM dates after the spot date.
* S*n*IMM: (spot + IMM) for swaps.
* T*n*IMM: (tomorrow + IMM) for swaps.

 | * Broken date: LocalMktDate(10)
* Tenor: String(30)

 |
| 194  | LastSpotRate | N | — | FX spot: Not applicable.
FX outright: Spot rate.
FX swap: Near-leg spot rate. | Price(20) |
| 195  | LastForwardPoints | N | — | FX spot: Not applicable.
FX outright: Forward points.
FX swap: Near-leg forward points. | PriceOffset(20) |
| 479  | CommCurrency | N | — | The dealt currency. | Currency(3) |
| 487  | TradeReportTransType | Y | — | The message transaction type:
N=New, for a new STP deal download.
R=Replace, for an STP resend, rebook, or a response to a Trade Capture Report Request from the client.
C=Canceled by the system (usually as part of time-based trade netting, portfolio netting and allocation). See `TradeReportRefID` (#572) for the ID of the net trade.
4=Reverse (FIX 4.4 only). | char(1) |
| 541  | MaturityDate | C | — | The fixing date for NDF trades. | LocalMktDate(8) |
| 8541  | MaturityDate2 | C | — | The fixing date for the far leg of NDF swaps.. | LocalMktDate(8) |
| 568  | TradeRequestID | N | — | Request ID if the message is sent as a response to a Trade Capture Report Request from the client. | String(20) |
| 570  | PreviouslyReported | C | Y=Resend, rebook, or trade status
N=Not previously sent | Indicates if the trade capture report was previously reported to the counterparty. Required if the trade is a resend, rebook, or trade status response. Not required if the trade has not previously been sent. | Boolean(1) |
| 571  | TradeReportID | Y | — | Unique ID for the Trade Capture Report message. | String(20) |
| 572  | TradeReportRefID | C | — | The ID of the net trade executed to net out this trade. Required for netted trades. | String(20) |
| 578  | TradeInputSource | N | — | The channel (app, UI component, or API) that originated the trade. | String(30) |
| 555  | NoLegs | C | 2 | Repeating group for legs of a trade in a synthetic cross currency pair. | NumInGroup(1) |
| → | 600 | LegSymbol | C(Y) | — | The leg’s currency. Required for synthetic cross trades. | String(35) |
| → | 624 | LegSide | C(Y) | * 1
* 2

 | The side of the leg. Required for synthetic cross trades.
1=Buy.
2=Sell. | char(1) |
| → | 687 | LegQty | C(Y) | — | The amount of leg currency. Required for synthetic cross trades. | Qty(20) |
| → | 637 | LegLastPx | C(Y) | — | All-in rate including base rate and spreads. Required for synthetic cross trades. | Price(20) |
| → | 1073 | LegLastForwardPoints | C(Y) | — | All-in points including forward points and spreads. Required for outright synthetic cross trades. | PriceOffset(20) |
| → | 588 | LegSettlDate | C(Y) | — | Value date in format *YYYYMMDD*. Required for synthetic cross trades. | LocalMktDate(8) |
| → | 2872 | TransactionAttributeType | C(Y) | * PURPOSE
* CIF NO

 | Attribute type of the next `TransactionAttributeValue` (#2872) field. Required for synthetic cross trades.* PURPOSE: the leg's purpose.
* CIF NO: the counterparty's CIF ID.

 | String(9) |
| → | 2873 | TransactionAttributeValue | C(Y) | * SYNTHETIC
* *ID number*

 | The value of this field is indicated by the previous `TransactionAttributeType` (#2873) field. Required for synthetic cross trades.* SYNTHETIC: indicates a leg of a synthetic cross-currency trade.
* *ID number*: the counterparty's CIF ID.

 | String(11) |
| 631  | MidPx | N | — | The near-leg all-in mid price. If a provider sends only mid swap points instead of near and far mid prices separately, this field is empty or 0 (zero). | Price(20) |
| 7631  | MidPxFl | N | — | The far-leg all-in mid price. If a provider sends only mid swap points instead of near and far mid prices separately, this field contains the swap points. | Price(20) |
| 640  | Price2 | N | — | Same as LastPx2`` (#7541). | Price(20) |
| 641  | LastForwardPoints2 | N | — | FX spot, outright: Not applicable.
FX swap: Far leg forward points. | PriceOffset(20) |
| 7541  | LastPx2 | N | — | FX spot, outright: Not applicable.
FX swap: Far-leg all-in price. The sum of `LastSpotRate` (#194) and LastForwardPoints2`` (#641). | Price(20) |
| 7545  | SettlCurrAmt2 | N | — | FX spot, outright: Not applicable.
FX swap: Far leg settled amount in `SettlCurrency` (#120). | Amt(20) |
| 7549  | OrderNotes | N | — | Notes on the order entered by the user who submitted the order. Applicable to single-leg trades only. Only included on messages that are sent by the user who submitted the order or sent to the user’s organization. Maximum 256 characters. Angle brackets “<“ and “>“ are not allowed in the value of this field. | String(255) |
| 7571  | PPSpotSprd | N | — | Price Provisioning Spread: Spot.
Defined in price provisioning Admin screens.
Spot trades: The spread applied to the spot rate as defined in the price provisioning rule.
Outright and swap trades: The sum of the tenor based pre-trade and post-trade spreads in price provisioning rule. Applied on the spot rate component.
Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7572  | PPFwdSprd | N | — | Price Provisioning Spread: Forward.
Defined in price provisioning Admin screens.
For outright trades only: The spread as defined in the price provisioning rule applied to the forward rate. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7573  | PPNearSprd | N | — | Price Provisioning Spread: Near Leg.
Defined in price provisioning Admin screens.
The fixed spread as defined in the price provisioning rule applied to the spot rate. The value of this attribute is currently set to zero. Available to makers who have configured STP to include market rate and spreads. | String |
| 7574  | PPFarSprd | N | — | Price Provisioning Spread: Far Leg.
Defined in price provisioning Admin screens.
The fixed spread as defined in the price provisioning rule applied to the spot rate. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7575  | PPCustSprd | N | — | Price Provisioning Spread: Customer.
This is a derived value. The sum of the spot spread (PPSpotSprd), the near leg spread (PPNearSprd), and the far leg forward spread (PPFarSprd). Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7576  | PMSpotSprd | N | — | Price Making Spread: Spot.
This a derived value. The sum of pre-trade and post-trade fixed spreads applied to the spot rate. This value includes price improvement, if any. Can be negative.
Available to makers who have configured STP to include market rate and spreads.
Applied based on the side of the trade or the far leg. If bid, the PMSpotSprd is subtracted. If offer, the PMSpotSprd is added.* PMSpotSprd (bid/sell) = Market spot rate – Customer verified spot rate – PPSpotSprd
* PMSpotSprd (offer/buy) = Customer verified spot rate – Market spot rate + PPSpotSprd

 | String(20) |
| 7577  | PMPreSpotSpread | N | — | Price Making Spread: Spot, Pre-Trade
Defined in price making Admin screens on the price stream.
The pre-trade fixed spread from the price stream configuration applied to the spot rate. This value is applied based on the side of the far leg. If the far leg spot side is bid, the PMPreSpotSpread is subtracted. If the far leg spot side is offer, the PMPreSpotSpread is added. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7578  | PMPostSpotSpread | N | — | Price Making Spread: Spot, Post-Trade.
Defined in price making Admin screens on the price stream.
The post-trade fixed spread from the price stream configuration applied to the spot rate. This value is applied based on the side of the far leg. If the far leg spot side is bid, the PMPostSpotSpread is subtracted. If the far leg spot side is offer, the PMPostSpotSpread is added. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7579  | PMFwdSprd | N | — | Price Making Spread: Forward
This is a derived value. For outright trades only: The sum of the pre-trade and post-trade fixed spreads applied to the forward points. This value includes price improvement, if any. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7580  | PMNearSprd | N | — | Near Tenor-Based Fixed Price-Making Spread.
This is a derived value. The sum of pre-trade and post-trade fixed spreads for the near leg. This value includes price improvement, if any. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7581  | PMFarSprd | N | — | Far Tenor-Based Fixed Price-Making Spread.
This is a derived value. The sum of pre-trade and post-trade fixed spreads for the far leg. This value includes price improvement, if any. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7582  | PMPreFwdSpread | N | — | Price Making Spread: Forward, Pre-Trade.
Defined in price making Admin screens on the price stream.
For outright trades only: The pre-trade fixed spread from the price stream configuration applied to the forward points. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7583  | PMPreNearSpread | N | — | Price Making Spread: Near, Pre-Trade
Defined in price making Admin screens on the price stream.
The pre-trade fixed spread from the price stream configuration for the near leg. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7584  | PMPreFarSpread | N | — | Price Making Spread: Far, Pre-Trade
Defined in price making Admin screens on the price stream.
The pre-trade fixed spread from the price stream configuration for the far leg. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7585  | PMPostFwdSpread | N | — | Price Making Spread: Forward, Post-Trade.
Defined in price making Admin screens on the price stream.
For outright trades only: The post-trade fixed spread from the price stream configuration applied to the forward points. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7586  | PMPostNearSpread | N | — | Price Making Spread: Near, Post-Trade.
Defined in price making Admin screens on the price stream.
The post-trade fixed spread from the price stream configuration for the near leg. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7587  | PMPostFarSpread | N | — | Price Making Spread: Far, Post-Trade.
Defined in price making Admin screens on the price stream.
The post-trade fixed spread from the price stream configuration for the far leg. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7588  | PMMaxSprd | N | — | Maximum Price-Making Spread
This is a derived value. The maximum spread applied to the spot rate.
Available to makers who have configured STP to include market rate and spreads.* Bid trade (sell) min/max spread = (Market spot rate – total Price Making pre-trade spread – total Price Making post-trade spread – total Price Provisioning spread) – Customer accepted rate
* Offer trade (buy) min/max spread = Customer accepted rate – (Market spot rate + total Price Making pre-trade spread + total Price Making post-trade spread + total Price Provisioning spread)

 | String(20) |
| 7589  | PMMinSprd | N | — | Minimum Price-Making Spread
This is a derived value. The minimum spread applied to the spot rate.
Available to makers who have configured STP to include market rate and spreads.* Bid trade (sell) min/max spread = (Market spot rate – total Price Making pre-trade spread – total Price Making post-trade spread – total Price Provisioning spread) – Customer accepted rate.
* Offer trade (buy) min/max spread = Customer accepted rate – (Market spot rate + total Price Making pre-trade spread + total Price Making post-trade spread + total Price Provisioning spread).

 | String(20) |
| 7590  | PPPostSpotSpread | N | — | Price Provisioning Spread: Spot, Post-Trade.
Defined in price provisioning Admin screens.
For spot and outright trades: Post-trade fixed spread as defined in the price provisioning rule applied to the spot rate. Available to makers who have configured STP to include market rate and spreads.
For swaps, this value is applied based on the side of the far leg.
The central bank markup for trades in currencies that require it. | String(20) |
| 7591  | PPPreSpotSpread | N | — | Price Provisioning Spread: Spot, Pre-Trade.
Defined in price provisioning Admin screens.
For spot and outright trades: Pre-trade fixed spread as defined in the price provisioning rule applied to the spot rate. Available to makers who have configured STP to include market rate and spreads.
For swaps, this value is applied based on the side of the far leg. | String(20) |
| 7592  | PPPreFwdSpread | N | — | Price Provisioning Spread: Forward, Pre-Trade
Defined in price provisioning Admin screens.
For outright and swap trades only: Pre-trade fixed spread as defined in the price provisioning rule applied to the forward points. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7593  | PPPostFwdSpread | N | — | Price Provisioning Spread: Forward, Post-Trade.
Defined in price provisioning Admin screens.
For outright and swap trades only: Post-trade fixed spread as defined in the price provisioning rule applied to the forward points. Available to makers who have configured STP to include market rate and spreads. | String(20) |
| 7601  | CoverExecID | N | Single trade cover: *tradeID*
Multiple trade cover: *tradeID*-*tradeID*-*tradeID* | **DEPRECATED.** The ID of the trade that covers this trade. If more than one trade covered this trade, the IDs are included as a single string with the IDs separated by hyphens (ASCII character 45), for example:
`FXI41606-FXI41607-FXI41610`This field has been deprecated. It contains a maximum of six (6) cover trade IDs. Use `CoveredExecID` (#7602) on downloaded cover trades instead to find all cover trades for an originating trade.
 | String(89) |
| 7602  | CoveredExecID | N | — | The ID of the trade that this trade covers. | String(20) |
| 9710  | CoverRiskManagementType | N | * COVER
* NO_COVER
* WAREHOUSE

 | Cover risk management method. For direct counterparty trades and the individual component legs of synthetic cross trades.
The following checkboxes must be selected in the STP Download Configuration screen of the admin app for this field to be included:* **Include Synthetic Cross**: to include the information on individual component legs of synthetic cross trades.
* **Include Cover Risk Management Details**: cover risk management method.

 | String(20) |
| 9711  | WarehouseBookName | N | — | Yield manager warehouse book name. For direct counterparty trades and the individual component legs of synthetic cross trades.
The following checkboxes must be selected in the STP Download Configuration screen of the admin app for this field to be included:* **Include Synthetic Cross**: to include the information on individual component legs of synthetic cross trades.
* **Include Yield Manager Book Name**: book name for direct counterparty trades and the individual component legs of synthetic cross trades.

 | String(30) |
| 552  | NoSides | Y | 1=One side
2=Both sides | The number of sides represented in the message. The required fields must be included as a group for each side. | NumInGroup(1) |
| → | 54 | Side | Y | 1=Buy
2=Sell | The buy/sell side from perspective of the customer specified by the `SenderSubID` (#50) and `DeliverToCompID` (#128) fields in terms of the dealt `Currency` (#15). For swaps, this is the side of the far leg. | char(1) |
| → | 37 | OrderID | Y | — | Unique ID generated by the FIX server | String(20) |
| 453  | NoPartyIDs | Y | — | The number of repeating groupings of `PartyID` (#448), `PartyIDSource` (#447), and `PartyRole` (#452) to represent the parties on the trade (taker user, originating user, originating organization). The required fields must be included as a group for each party. | NumInGroup(1) |
| → | 448 | PartyID | Y | — | The ID of the party specified by the `PartyRole` (#452) of this group of fields. | String(20) |
| → | 447 | PartyIDSource | Y | D=Proprietary/Custom code | The class or source of the `PartyID` (#448) value. | char(1) |
| → | 452 | PartyRole | Y | 3=Taker user
11=Originating user
13=Order Originating Firm | The type or role of the associated `PartyID` (#448). | int(2) |
| <Standard trailer>  | Y | — | — | — |


### Trade Capture Report Ack

You send this message to Integral to update a trade with data from further processing in your organization, such as a trade ID assigned by your back office.

Trade Capture Report Ack is only available in the FIX 4.4 protocol.

Valid responses 

* None


Message format 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=AR | — |
| 8 | BeginString | Y | FIX.4.4 | Trade Capture Report Ack is only available in the FIX 4.4 protocol. | String(20) |
| 115 | OnBehalfOfCompID | Y | — | Counterparty A organization ID of the trade. By convention, this is the taker of the trade. | String(20) |
| 571 | TradeReportID | Y | — | Trade Capture Report Ack is only available in the FIX 4.4 protocol. | String(7) |
| 487 | TradeReportTransType | N | 4 | The message transaction type:
4=Reverse | char(1) |
| 150 | ExecType | Y | F=Trade | The state of the included trade. | char(1) |
| 17 | ExecID | Y | — | The trading app ID (transaction ID) for the trade that prompted this response. | String(20) |
| 55 | Symbol | Y | — | Traded instrument symbol. | String(35) |
| 939 | TrdRptStat | Y | 0=Accepted
1=Rejected | The status in your system of the Trade Capture Report from Integral that triggered this message. | int(1) |
| 751 | TradeReportRejectReason | C | 0=Successful (Default)
1=Invalid party information
2=Unknown instrument
3=Unauthorized to report trades
4=Invalid trade type
99=Other | Required if `TrdRptStat` (#939)=1. (Rejected). | int(2) |
| 818 | SecondaryTradeReportID | Y | — | Additional trade data from further processing in your organization, such as a trade ID assigned by your back office. | String(255) |
| 60 | TransactTime | Y | — | The time this message was sent. | UTCTimestamp(21) |
| <Standard trailer>  | Y | — | — | — |


## Regulatory data (MiFID, EMIR, CFTC)

Fields for regulatory data for the following regulatory regimes are included on relevant FIX messages.

* [MiFID](#mifid)
* [EMIR](#emir)
* [CFTC](#cftc)


### MiFID

The MiFID fields can be included on the [Trade Capture Report](#trade-capture-report-1) message.

#### Trade Capture Report

Trade Capture Report MiFID data 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| <Standard header>  | Y | — | 35=AE | — |
| 9374  | USINamespace | N | — | The ten-character USI namespace for single-leg trades or the near-leg USI prefix for multi-legged trades. Only included when the receiving organization is configured to receive SEF identifiers and when the trade involves SEF instruments and organizations. | String(10) |
| 9375  | USIFarNamespace | N | — | The ten-character USI namespace for the far-leg. Only included when the receiving organization is configured to receive SEF identifiers and when the trade involves SEF instruments and organizations. | String(10) |
| 9376  | USI | N | — | The USI for single-leg trades or the near-leg USI for multi-legged trades. Only included when the receiving organization is configured to receive SEF identifiers and when the trade involves SEF instruments and organizations. | String(10) |
| 9377  | USIFar | N | — | The far-leg USI. Only included when the receiving organization is configured to receive SEF identifiers and when the trade involves SEF instruments and organizations. | String(10) |
| 9378  | UTIPrefix | N | — | UTI namespace for single-leg trades (outrights) and near leg of swaps. | String(20) |
| 9379  | UTIFarPrefix | N | — | UTI namespace for far leg of swaps. Not applicable to single-leg trades. | String(20) |
| 9380  | UTI | N | — | UTI value for single-leg trades (outrights, near leg of swaps, and each leg of multi-leg trades). | String(52) |
| 9381  | UTIFar | N | — | UTI value for far leg of swaps. Not applicable to single-leg trades. | String(52) |
| 9382  | UPI | N | — | Unique Product Identifier value. | String(52) |
| 453  | NoPartyIDs | Y | — | The number of repeating groupings of `PartyID` (#448), `PartyIDSource` (#447), and `PartyRole` (#452) to represent the parties on the trade (taker user, originating user, originating organization). The required fields must be included as a group for each party.
For trades done on an MTF, the repeating groups represent the following entities:* Venue
* Order Originating Firm: If trading on behalf the customer, this is the sales dealer.
* Executing Trader
* Customer Org
* Maker Org
* Investment Decision Maker: Includes maker details if downloaded by the maker and taker details if downloaded by the taker.

 | NumInGroup(1) |
| → | 448 | PartyID | Y | — | The ID of the party specified by the `PartyRole` (#452) of this group of fields.
For trades done on an MTF, this field has the following value based on entity type:* Venue: MIC code
* Order Originating Firm: If trading on behalf the customer, this is the salesdealer’s LEI. Otherwise this is the taker’s LEI
* Executing Trader: Executing Trader short code
* Customer Org: LEI value
* Maker Org: LEI value
* Investment Decision Maker: short code (maker details if downloaded by the maker and taker details if downloaded by the taker)

 | String(20) |
| → | 447 | PartyIDSource | Y | D=Proprietary/Custom code
G=MIC
N=LEI
P=Short Code | The class or source of the `PartyID` (#448) value.
For trades done on an MTF, this field has the following value based on entity type:* Venue: G (MIC)
* Order Originating Firm: N (LEI)
* Executing Trader: P (Short Code)
* Customer Org: N (LEI)
* Maker Org: N (LEI)
* Investment Decision Maker: P (Short Code, maker details if downloaded by the maker and taker details if downloaded by the taker)

 | char(1) |
| → | 452 | PartyRole | Y | 3=Taker user
11=Originating user
12=Executing Trader
13=Order Originating Firm
24=Customer Account
35=Liquidity Provider
64=Multilateral Trading Facility
122=Investment Decision Maker | The type or role of the associated `PartyID` (#448).
For trades done on an MTF, this field has the following value based on entity type:* Venue: 64 (Multilateral Trading Facility)
* Order Originating Firm: 13 (Order Originating Firm)
* Executing Trader: 12 (Executing Trader)
* Customer Org: 24 (Customer Account)
* Maker Org: 35 (Liquidity Provider)
* Investment Decision Maker: 122 (Investment Decision Maker, maker details if downloaded by the maker and taker details if downloaded by the taker)

 | int(2) |
| → | 802 | NoPartySubIDs | N | 2 | The number of repeating groups that indicate whether or not the trade was done by a Systematic Internaliser (SI) and, if true, includes the SI venue’s MIC. | NumInGroup(1) |
| →→ | 523 | PartySubID | C | — | Required if `NoPartySubIDs` (#802) is included.
If `PartySubID` (#523)=32 (Execution venue), this is the venue’s MIC.
If `PartySubID` (#523)=76 (Systematic Internaliser):* Y: Trade was executed by a Systematic Internaliser
* N: Trade was not executed by a Systematic Internaliser

 | String(20) |
| →→ | 803 | PartySubIDType | C | 32=Execution venue
76=Systematic Internaliser | Required if `NoPartySubIDs` (#802) is included. | int(2) |
| → | 2376 | PartyRoleQualifier | C | 22=Algorithm
24=Originating user | User type. Only required for Executing Trader (PartyRole (#452)= 12) and Investment Decision Maker (PartyRole (#452)= 112). | int(2) |
| 29  | LastCapacity | N | 1=Agent (AOTC, any other capacity)
3=Cross as Principal (MTCH, matched principal)
4=Riskless Principal (DEAL, dealing on own account) | Trading Capacity | char(1) |
| 1839  | TradePriceCondition | N | 15=Non-price forming trade. | Price conditions in effect at the time of the trade. | int(2) |
| 2668  | NoTrdRegPublications | N | 3 | Number of regulatory publication rules in repeating group | NumInGroup(1) |
| → | 2669 | TrdRegPublicationType | C | 0=Pre-trade transparency waiver
1=Post-trade deferral
2=Exempt from publication | Required if `NoTrdRegPublications` (#2668) is included. The type of regulatory publication | NumInGroup(1) |
| → | 2670 | TrdRegPublicationReason | C | 4=No public price quoted as instrument is illiquid
7=Deferral due to "Illiquid Instrument"
11=Exempted due to securities financing transaction | Required if `NoTrdRegPublications` (#2668) is included. Additional reason for trade publication type. | int(2) |
| 768  | NoTrdRegTimestamps | N | — | Number of timestamp entries | NumInGroup(1) |
| → | 769 | TrdRegTimestamp | C | — | Required if `NoTrdRegPublications` (#768) is included. Timestamp in the format *YYYYMMDD-hh:mm:ss.sss*. | UTCTimestamp(21) |
| → | 770 | TrdRegTimestampType | C | 10=Order submission time
1=Execution time | Required if `NoTrdRegTimestamps` (#768) is included. Timestamp type. | int(2) |
| 22  | SecurityIDSource | N | 4=ISIN number | Identifies class or source of the `SecurityID` (#48) value. | String(1) |
| 48  | SecurityID | C | — | Required if `SecurityIDSource` (#22) is included. Security identifier value. | String(12) |


### EMIR

The RTN (Report Tracking Number) under EMIR reporting is captured as a repeating group. The unique numbers are assigned to the execution, either for a single-leg trade or in common to all legs of a multi-leg trade, such as swaps. Integral receives these values on the FIX workflow and sets it on the trade for downstream STP.

EMIR fields can be supplied on the Trade Capture Report (`MsgType` (#35)=AE) message.

FIX fields for EMIR REFIT and CFTC data 

| Tag  | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| 1907  | NoRegulatoryTradeIDs | N | — | Repeating group to support regulatory reporting trade IDs (RTNs). Indicates the number of elements in the repeating group. | NumInGroup(2) |
| → | 1903 | RegulatoryTradeID | C | — | Regulatory trade ID as received from the external venue. | String(52) |
| → | 1904 | RegulatoryTradeIDEvent | C | 0=Initial block trade. | Event that caused origination of the regulatory ID. | Int(1) |
| → | 1906 | RegulatoryTradeIDType | C | 6=Report tracking number. | Type of regulatory ID. | Int(1) |
| → | 2411 | RegulatoryLegRefID | C | 1= Single leg trade or near leg of a swap.
2=Far leg of a swap. | Indicates the leg of the trade to which the regulatory trade applies. | String(1) |


### CFTC

The following CFTC data can be captured in FIX messaging:

* UPI (Unique Product Identifier): fields for each leg of a single leg or a multi-leg trade. Integral receives this field from external venues and captures it on the trade to send it on the STP message.
* UTI (Unique Transaction Identifier)


CFTC fields can be supplied on the Trade Capture Report (`MsgType` (#35)=AE) message.

FIX fields for EMIR REFIT and CFTC data 

| Tag | Field name | Req’d | Valid values | Description | Type(length) |
|  --- | --- | --- | --- | --- | --- |
| 9398 | UPI | N | — | Unique Product Identifier under CFTC rules, a product-level identifier for single-leg trades, near leg of swaps, or for individual legs of a multi-leg trade. Integral receives this value on the FIX workflow and sets it on the trade for downstream STP. | String(52) |
| 9399 | UPIFar | N | — | Unique Product Identifier under CFTC rules, a product-level identifier for the far leg of swaps. Integral receives this value on the FIX workflow and sets it on the trade for downstream STP. | String(52) |
| 9378 | UTIPrefix | N | — | Unique code for the code issuing authority for single-leg trades and near leg of swaps. Supports 20-character UTI prefixes. | String(20) |
| 9379 | UTIFarPrefix | N | — | Unique code for the code issuing authority for far leg of swaps. Supports 20-character UTI prefixes. | String(20) |
| 9380 | UTI | N | — | Unique code for single-leg trade, near leg of swaps, and each leg of multi-leg trades. | String(52) |
| 9381 | UTIFar | N | — | Unique code for far leg of swaps. | String(52) |


## Session rejection reasons

The following table lists the rejection reasons returned by FIX STP in a Session-level Reject message when a message fails session-level validation.

**Table A‑1** Session rejection reasons

| Error code | Text explanation of error code |
|  --- | --- |
| 0 | Invalid tag number. |
| 1 | Required tag missing. |
| 2 | Tag not defined for message type. |
| 3 | Undefined Tag. |
| 4 | Tag specified without a value. |
| 5 | Value is incorrect (out of range) for this tag. |
| 6 | Incorrect data format for value. |
| 7 | Decryption problem. |
| 8 | Signature problem. |
| 9 | CompID problem. |
| 10 | `SendingTime` (#52) accuracy problem. |
| 11 | Invalid `MsgType` (#35). |
| 12 | XML Validation error. |
| 13 | Tag appears more than once. |
| 14 | Tag specified out of required order. |
| 15 | Repeating group fields out of order. |
| 16 | Incorrect number in group count for repeating group. |
| 17 | Non “data” value includes field delimiter (SOH character). |
| 99 | Other. |


Appendix B

## Changes

The following table lists API changes and significant changes to this document in chronological order from newest to oldest.

API and document changes  

| Date (document version) | Changes |
|  --- | --- |
| June 2026 (1.0v25) | Added `CoverRiskManagementType` (#9710) and `WarehouseBookName` (#9711) to [Trade Capture Report](#trade-capture-report) to capture the cover risk management type and Yield Manager book name in direct trades and component trades of synthetic cross trades. |
| March 2026 (1.0v24) | Added `NoLegs` (#555) repeating group to [Trade Capture Report](#trade-capture-report) to capture the trades in component currency pairs for a trade done in a synthetic cross currency pair. |
| February 2026 (1.0v22) | Corrected format for `SettlDate` (#64) and `SettlDate2` (#193) to *YYYYMMDD* in [Trade Capture Report].(#trade-capture-report) |
| October 2025
(1.0v21) | Added support for deliverable and non-deliverable instruments on a request-by-request basis to `SecurityType` (#167) on [Trade Capture Report](#trade-capture-report):* FOR: Foreign Exchange Contract. By default, for a given instrument, quote convention settings on the server automatically determine the trade type.

Contact your Integral Technical Account Manager to configure specific instruments if you need to specify the trade type on a request-by-request basis.
When the system is configured to accept both deliverable and non-deliverable trade types for specific instruments, the following values indicate the requested trade type:* FXNDF: non-deliverable forward.
* FXFWD: deliverable forward.
* FXNDS: non-deliverable swap.
* FXSWAP: deliverable swap.

 |
| September 2025
(1.0v19) | Corrected list of tenors in `SettlDate2` (#193) of [Trade Capture Report](#trade-capture-report). |
| March 2025
(1.0v18) | Added `OnBehalfOfCompID` (#115):* [Trade Capture Report Ack](#trade-capture-report-ack) message format
* [Trade Capture Report Ack](/developer-portal/fix-examples#trade-capture-report-ack-back-office-id) example

 |
| March 2025
(1.0v15) | * Corrected descriptions in [Supported business messages](#supported-business-messages)
* Added Trade Capture Report Ack message:
  * [Trade Capture Report Ack](#trade-capture-report-ack) message format
  * [Supported business messages](#supported-business-messages)
  * [Trade Capture Report Ack](/developer-portal/fix-examples#trade-capture-report-ack-back-office-id) example

 |
| October 2024
(1.0v11) | Deprecated `CoverExecID` (#7601) in [Trade Capture Report](#trade-capture-report). The field contains a maximum of six (6) cover trade IDs. Use `CoveredExecID` (#7602) on downloaded cover trades instead to find all cover trades for an originating trade. |
| July 2024
(1.0v10) | Added MaturityDate2`` (#8541) to [Trade Capture Report](#trade-capture-report) to support NDF swaps. |
| May 2024
(1.0v8) | * Added sections:
  * [Implementation details](#implementation-details)
  * [Administrative messages](#administrative-messages)
  * [Session rejection reasons](#session-rejection-reasons)
* Expanded [Trade Capture Report](#trade-capture-report) with outright trade, multi-leg trade and batch trade fields.
* Added [Regulatory data (MiFID, EMIR, CFTC)](#regulatory-data-mifid-emir-cftc).

 |
| November 2020
(1.0v5) | Added values to `SecurityType` (#167) on [Trade Capture Report](#trade-capture-report).
Instrument type based on traded currency pair classification:* FOR=Foreign Exchange Contract (CURRENCY)
* CFD=Contract for difference (INDEX)
* ETC=Exchange traded commodity (METAL and ENERGY)
* CRYP=Cryptocurrency (custom value, not defined by the FIX protocol)

 |
| November 2020
(1.0v4) | Added:* [Message reliability and reconciliation](#message-reliability-and-reconciliation)
* [Trade Capture Report Request](#trade-capture-report-request)

 |
| January 2020
(1.0v2) | First distribution. |