{"_id":"56b377b053da320d00c29742","category":{"_id":"56b2615b147e900d00d64995","pages":["56b36e000551d31900cec0ab","56b36e0cb008aa1900ab16f1","56b36e1670b0d22100be6512","56b3773f78a1212100900705","56b3778940438c1900004796","56b377b053da320d00c29742","56b377c5023ef30d009b2b82","56b3788453da320d00c29744"],"project":"569407ac73f48f0d0075c9c9","__v":8,"version":"569407ad73f48f0d0075c9cc","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-02-03T20:21:47.739Z","from_sync":false,"order":9999,"slug":"sessions","title":"Sessions"},"githubsync":"","project":"569407ac73f48f0d0075c9c9","version":{"_id":"569407ad73f48f0d0075c9cc","project":"569407ac73f48f0d0075c9c9","__v":4,"createdAt":"2016-01-11T19:51:09.439Z","releaseDate":"2016-01-11T19:51:09.439Z","categories":["569407ae73f48f0d0075c9cd","56b25e4794ab060d00067421","56b2615b147e900d00d64995","56b3788d78a1212100900709"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1"},"user":"563cc6fa8894d20d00014ea3","__v":6,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-02-04T16:09:20.034Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":999,"body":"[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"8=FIX.4.2\\n9=107\\n34=1920\\n35=3\\n45=2371\\n49=TEST1\\n52=20160203-14:31:52.235\\n56=DWFIX01\\n58=Invalid tag number\\n371=8005\\n372=8\\n373=0\\n10=224\",\n      \"language\": \"text\",\n      \"name\": \"Reject\"\n    }\n  ],\n  \"sidebar\": true\n}\n[/block]\nThe `Reject <3>` message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data (e.g. `MsgType <35>=&`) which successfully passes de-encryption, `CheckSum <10>` and `BodyLength <9>` checks. As a rule, messages should be forwarded to the trading application for business level rejections whenever possible.\n\nRejected messages should be logged and the incoming sequence number incremented.\n\nNote: The receiving application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence gap and a `Resend Request <2>` will be generated. Logic should be included in the FIX engine to recognize the possible infinite resend loop, which may be encountered in this situation.\n\nGeneration and receipt of a `Reject <3>` message indicates a serious error that may be the result of faulty logic in either the sending or receiving application.\n\nIf the sending application chooses to retransmit the rejected message, it should be assigned a new sequence number and sent with `PossResend <97>=Y`.\n\nWhenever possible, it is strongly recommended that the cause of the failure be described in the `Text <58>` field (e.g. `INVALID DATA - FIELD 35`).\n\nIf an application-level message received fulfills session-level rules, it should then be processed at a business message-level. If this processing detects a rule violation, a business-level reject should be issued. Many business-level messages have specific \"reject\" messages, which should be used. All others can be rejected at a business-level via the `Business Message Reject <j>` message. See the `Business Message Reject <j>` message\n\nNote that in the event a business message is received, fulfills session-level rules, however, the message cannot be communicated to the business-level processing system, a `Business Message Reject <j>` with `BusinessRejectReason <380>` = \"Application not available at this time\" should be issued.\n\nScenarios for session-level `Reject <3>`:\n\n`SessionRejectReason <373>`\n\n`0` - Invalid tag number\n`1` - Required tag missing\n`2` - Tag not defined for this message type\n`3` - Undefined Tag\n`4` - Tag specified without a value\n`5` - Value is incorrect (out of range) for this tag\n`6` - Incorrect data format for value\n`7` - Decryption problem\n`8` - Signature <89> problem\n`9` - CompID problem\n`10` - SendingTime <52> accuracy problem\n`11` - Invalid MsgType <35>\n\n(Note other session-level rule violations may exist in which case `SessionRejectReason <373>` is not specified)\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Tag\",\n    \"h-1\": \"Tag Description\",\n    \"h-2\": \"Value\",\n    \"h-3\": \"Value Description\",\n    \"0-0\": \"`8`\",\n    \"0-1\": \"BeginString\",\n    \"0-2\": \"`FIX.4.2`\",\n    \"0-3\": \"FIX Version\",\n    \"h-4\": \"Required\",\n    \"3-0\": \"`35`\",\n    \"3-1\": \"MsgType\",\n    \"3-2\": \"`3`\",\n    \"3-3\": \"Reject Message\",\n    \"0-4\": \"**Yes**\",\n    \"1-0\": \"`9`\",\n    \"1-1\": \"BodyLength\",\n    \"1-2\": \"`63`\",\n    \"1-3\": \"Length of message\",\n    \"1-4\": \"**Yes**\",\n    \"3-4\": \"**Yes**\",\n    \"12-0\": \"`10`\",\n    \"12-1\": \"CheckSum\",\n    \"12-2\": \"`224`\",\n    \"12-3\": \"Checksum of message\",\n    \"12-4\": \"**Yes**\",\n    \"5-0\": \"`49`\",\n    \"5-1\": \"SenderCompID\",\n    \"5-2\": \"`TEST1`\",\n    \"5-3\": \"Sender ID\",\n    \"5-4\": \"**Yes**\",\n    \"7-0\": \"`56`\",\n    \"7-1\": \"TargetCompID\",\n    \"7-2\": \"`DWFIX01`\",\n    \"7-3\": \"Target ID\",\n    \"6-0\": \"`52`\",\n    \"6-1\": \"SendingTime\",\n    \"6-2\": \"`20160203-14:31:52.235`\",\n    \"6-3\": \"Sending timestamp\",\n    \"6-4\": \"**Yes**\",\n    \"7-4\": \"**Yes**\",\n    \"2-0\": \"`34`\",\n    \"2-1\": \"MsgSeqNum\",\n    \"2-2\": \"`1920`\",\n    \"2-3\": \"Message sequence number\",\n    \"2-4\": \"**Yes**\",\n    \"4-0\": \"`45`\",\n    \"4-1\": \"RefSeqNum\",\n    \"4-2\": \"2371\",\n    \"4-3\": \"Reference message sequence number\",\n    \"4-4\": \"**Yes**\",\n    \"8-0\": \"`58`\",\n    \"8-1\": \"Text\",\n    \"8-2\": \"`Invalid tag number`\",\n    \"8-3\": \"Rejection message\",\n    \"8-4\": \"**Yes**\",\n    \"9-0\": \"`371`\",\n    \"9-1\": \"RefTagID\",\n    \"9-2\": \"`8005`\",\n    \"9-3\": \"The tag number of the FIX field being referenced\",\n    \"9-4\": \"**Yes**\",\n    \"10-0\": \"`372`\",\n    \"10-1\": \"RefMsgType\",\n    \"10-2\": \"`8`\",\n    \"10-3\": \"The `MsgType` of the FIX message being referenced.\",\n    \"10-4\": \"**Yes**\",\n    \"11-0\": \"`373`\",\n    \"11-1\": \"SessionRejectReason\",\n    \"11-2\": \"0\",\n    \"11-3\": \"Code to identify reason for a session-level Reject message.\",\n    \"11-4\": \"**Yes**\"\n  },\n  \"cols\": 5,\n  \"rows\": 13\n}\n[/block]","excerpt":"","slug":"reject-message","type":"basic","title":"Reject"}
[block:code] { "codes": [ { "code": "8=FIX.4.2\n9=107\n34=1920\n35=3\n45=2371\n49=TEST1\n52=20160203-14:31:52.235\n56=DWFIX01\n58=Invalid tag number\n371=8005\n372=8\n373=0\n10=224", "language": "text", "name": "Reject" } ], "sidebar": true } [/block] The `Reject <3>` message should be issued when a message is received but cannot be properly processed due to a session-level rule violation. An example of when a reject may be appropriate would be the receipt of a message with invalid basic data (e.g. `MsgType <35>=&`) which successfully passes de-encryption, `CheckSum <10>` and `BodyLength <9>` checks. As a rule, messages should be forwarded to the trading application for business level rejections whenever possible. Rejected messages should be logged and the incoming sequence number incremented. Note: The receiving application should disregard any message that is garbled, cannot be parsed or fails a data integrity check. Processing of the next valid FIX message will cause detection of a sequence gap and a `Resend Request <2>` will be generated. Logic should be included in the FIX engine to recognize the possible infinite resend loop, which may be encountered in this situation. Generation and receipt of a `Reject <3>` message indicates a serious error that may be the result of faulty logic in either the sending or receiving application. If the sending application chooses to retransmit the rejected message, it should be assigned a new sequence number and sent with `PossResend <97>=Y`. Whenever possible, it is strongly recommended that the cause of the failure be described in the `Text <58>` field (e.g. `INVALID DATA - FIELD 35`). If an application-level message received fulfills session-level rules, it should then be processed at a business message-level. If this processing detects a rule violation, a business-level reject should be issued. Many business-level messages have specific "reject" messages, which should be used. All others can be rejected at a business-level via the `Business Message Reject <j>` message. See the `Business Message Reject <j>` message Note that in the event a business message is received, fulfills session-level rules, however, the message cannot be communicated to the business-level processing system, a `Business Message Reject <j>` with `BusinessRejectReason <380>` = "Application not available at this time" should be issued. Scenarios for session-level `Reject <3>`: `SessionRejectReason <373>` `0` - Invalid tag number `1` - Required tag missing `2` - Tag not defined for this 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 <89> problem `9` - CompID problem `10` - SendingTime <52> accuracy problem `11` - Invalid MsgType <35> (Note other session-level rule violations may exist in which case `SessionRejectReason <373>` is not specified) [block:parameters] { "data": { "h-0": "Tag", "h-1": "Tag Description", "h-2": "Value", "h-3": "Value Description", "0-0": "`8`", "0-1": "BeginString", "0-2": "`FIX.4.2`", "0-3": "FIX Version", "h-4": "Required", "3-0": "`35`", "3-1": "MsgType", "3-2": "`3`", "3-3": "Reject Message", "0-4": "**Yes**", "1-0": "`9`", "1-1": "BodyLength", "1-2": "`63`", "1-3": "Length of message", "1-4": "**Yes**", "3-4": "**Yes**", "12-0": "`10`", "12-1": "CheckSum", "12-2": "`224`", "12-3": "Checksum of message", "12-4": "**Yes**", "5-0": "`49`", "5-1": "SenderCompID", "5-2": "`TEST1`", "5-3": "Sender ID", "5-4": "**Yes**", "7-0": "`56`", "7-1": "TargetCompID", "7-2": "`DWFIX01`", "7-3": "Target ID", "6-0": "`52`", "6-1": "SendingTime", "6-2": "`20160203-14:31:52.235`", "6-3": "Sending timestamp", "6-4": "**Yes**", "7-4": "**Yes**", "2-0": "`34`", "2-1": "MsgSeqNum", "2-2": "`1920`", "2-3": "Message sequence number", "2-4": "**Yes**", "4-0": "`45`", "4-1": "RefSeqNum", "4-2": "2371", "4-3": "Reference message sequence number", "4-4": "**Yes**", "8-0": "`58`", "8-1": "Text", "8-2": "`Invalid tag number`", "8-3": "Rejection message", "8-4": "**Yes**", "9-0": "`371`", "9-1": "RefTagID", "9-2": "`8005`", "9-3": "The tag number of the FIX field being referenced", "9-4": "**Yes**", "10-0": "`372`", "10-1": "RefMsgType", "10-2": "`8`", "10-3": "The `MsgType` of the FIX message being referenced.", "10-4": "**Yes**", "11-0": "`373`", "11-1": "SessionRejectReason", "11-2": "0", "11-3": "Code to identify reason for a session-level Reject message.", "11-4": "**Yes**" }, "cols": 5, "rows": 13 } [/block]