ISO 3531-3:2022

Financial services — Financial information eXchange session layer — Part 3: FIX session layer test cases

This document provides a set of mandatory and optional conformity tests applicable to all versions of the FIX session layer standard.

Titre manque — Partie 3: Titre manque

General Information

• Status: Published
• Publication Date: 11-Apr-2022
• ICS: 03.060 - Finances. Banking. Monetary systems. Insurance
• Technical Committee: ISO/TC 68/SC 9 - Information exchange for financial services
• Drafting Committee: ISO/TC 68/SC 9 - Information exchange for financial services
• Current Stage: 6060 - International Standard published
• Start Date: 12-Apr-2022
• Due Date: 24-Jul-2022
• Completion Date: 12-Apr-2022

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 3531-3
First edition
2022-04
Financial services — Financial
information eXchange session layer —
Part 3:
FIX session layer test cases
Reference number
ISO 3531-3:2022(E)
© ISO 2022

---------------------- Page: 1 ----------------------
ISO 3531-3:2022(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2022
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
  © ISO 2022 – All rights reserved

---------------------- Page: 2 ----------------------
ISO 3531-3:2022(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 FIX session layer test cases . 1
4.1 Applicability . 1
4.2 Test cases . 1
4.3 Buyside-oriented (session initiator) Logon and session initiation test case . . 1
4.3.1 Scenario 1B Connect and Send Logon message . 1
4.4 Sellside-oriented (session acceptor) Logon and session initiation test case . 2
4.4.1 Scenario 1S Receive Logon message . 2
4.4.2 Scenario 2S. Receive any message other than a Logon message . 3
4.5 Test cases applicable to all FIX systems . 3
4.5.1 Scenario 2 Receive Message Standard Header . 3
4.5.2 Scenario 3 Receive Message Standard Trailer . 5
4.5.3 Scenario 4 Send Heartbeat message . 6
4.5.4 Scenario 5 Receive Heartbeat message . 6
4.5.5 Scenario 6 Send Test Request . 6
4.5.6 Scenario 7 Receive Reject message . 6
4.5.7 Scenario 8 Receive Resend Request message . 7
4.5.8 Scenario 9 Synchronize sequence numbers . 7
4.5.9 Scenario 10 Receive Sequence Reset (Gap Fill) . 7
4.5.10 Scenario 11 Receive Sequence Reset (Reset) . 8
4.5.11 Scenario 12 Initiate logout process . 8
4.5.12 Scenario 13 Receive Logout message . 9
4.5.13 Scenario 14 Receive application or session layer message . 9
4.5.14 Scenario 15 Send application or session layer messages to test normal and
abnormal behaviour/response . 11
4.5.15 Scenario 16 Queue outgoing messages . 11
4.5.16 Scenario 17 Support encryption .12
4.5.17 Scenario 18 Support third party addressing . .13
4.5.18 Scenario 19 Test PossResend handling . 14
4.5.19 Scenario 20 Simultaneous Resend request test . 14
Bibliography .15
iii
© ISO 2022 – All rights reserved

---------------------- Page: 3 ----------------------
ISO 3531-3:2022(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by FIX Trading Community (as FIX Session Layer Technical Specification)
and drafted in accordance with its editorial rules. It was assigned to Technical Committee ISO/TC 68,
Financial services, Subcommittee SC 9, Information exchange for financial services, and adopted under
the “fast-track procedure”.
A list of all parts in the ISO 3531 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
  © ISO 2022 – All rights reserved

---------------------- Page: 4 ----------------------
ISO 3531-3:2022(E)
Introduction
FIX session protocol was written to be independent of any specific communications protocol (e.g. X.25,
async, TCP/IP) or physical medium (e.g. copper, fibre, satellite) chosen for electronic data delivery. It
offers a reliable stream where a message is delivered once and in order. The FIX session layer is designed
to survive and resume operation in the event of the loss of transport level connections caused by any
type of failure, including network outage, application failure or computer hardware failures.
The session layer is concerned with the ordered delivery of data while the application level defines
business-related data content. This document focuses on the ordered delivery of data using the “FIX
session protocol”.
The FIX session protocol is implemented using the FIX tagvalue encoding syntax for the standard
header, standard trailer and the session level messages which make up the FIX session protocol. It is
possible to send messages using other FIX-defined encodings (e.g. FIXML, SBE, JSON, GPB, ASN.1) or
other non-FIX defined encodings (e.g. XML, FpML, ISO 20022 XML, JSON).
v
© ISO 2022 – All rights reserved

---------------------- Page: 5 ----------------------
INTERNATIONAL STANDARD ISO 3531-3:2022(E)
Financial services — Financial information eXchange
session layer —
Part 3:
FIX session layer test cases
1 Scope
This document provides a set of mandatory and optional conformity tests applicable to all versions of
the FIX session layer standard.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 11404, Information technology — General-Purpose Datatypes (GPD)
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 11404 apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
4 FIX session layer test cases
4.1 Applicability
This document was last revised September 20, 2002 at which time FIX version 4.3 with Errata 20020930
was the latest version of the FIX Protocol. Note that future amendments to this document can be found
on the FIX website and any version of this document published on a later date takes precedence over
this version of the document. This document is applicable to all supported versions of the FIX session
layer (4.2, 4.4, FIXT) except where explicitly indicated.
4.2 Test cases
These test cases are from the perspective of the FIX system being tested. The FIX system receives the
“condition/stimulus” and is expected to take the appropriate action as defined by “expected behaviour”.
4.3 Buyside-oriented (session initiator) Logon and session initiation test case
4.3.1 Scenario 1B Connect and Send Logon message
Mandatory
1
© ISO 2022 – All rights reserved

---------------------- Page: 6 ----------------------
ISO 3531-3:2022(E)
Condition/stimulus Expected behaviour
a. Establish transport layer connec- Successfully established transport layer connection with peer.
tion.
b. Send Logon(35=A) request mes- Logon(35=A) acknowledgement message sent by peer.
sage.
c. Valid Logon(35=A) acknowledge- If MsgSeqNum(34) is too high, send ResendRequest(35=2).
ment message received.
d. Invalid Logon(35=A) acknowl- 1. Generate an error condition in test output.
edgement message received.
2. (Optional) Send Reject(35=3) message with RefSeqNum(45)
identifying Logon(35=A) message’s MsgSeqNum(34) and Text(58)
referencing error condition.
3. Send Logout(35=5) message with Text(58) referencing error
condition.
4. Disconnect.
e. Receive any message other than a 1. Log an error “first message not a logon”.
Logon(35=A) message.
2. (Optional) Send Reject(35=3) message with RefSeqNum(45)
identifying message’s MsgSeqNum(34) and Text(58) referencing
error condition.
3. (Optional) Send Logout(35=5) message with Text(58) referenceing
error condition.
4. Disconnect.
4.4 Sellside-oriented (session acceptor) Logon and session initiation test case
4.4.1 Scenario 1S Receive Logon message
Mandatory
Condition/stimulus Expected behaviour
a. Valid Logon(35=A) request message received. 1. Respond with Logon(35=A) acknowledgement
message.
2. If MsgSeqNum(34) > NextNumIn send
ResendRequest(35=2).
b. Logon(35=A) message received with duplicate 1. Generate an error condition in test output.
identity (e.g. same IP, port, SenderCompID(49), Tar-
2. Disconnect without sending a message (Note:
getCompID(56), etc. as existing connection).
sending a Reject or Logout(35=5) would consume a
MsgSeqNum(34)).
c. Logon(35=A) message received with unauthenti- 1. Generate an error condition in test output.
cated/non-configured identity (e.g. invalid Sender-
2. Disconnect without sending a message (Note:
CompID(49), invalid TargetCompID(56), invalid
sending a Reject or Logout(35=5) would consume a
source IP address, etc. vs. system configuration).
MsgSeqNum(34)).
2
  © ISO 2022 – All rights reserved

---------------------- Page: 7 ----------------------
ISO 3531-3:2022(E)
Condition/stimulus Expected behaviour
d. Invalid Logon(35=A) message. 1. Generate an error condition > in test output.
2. (Optional) Send > Reject(35=3) message > with
RefSeqNum(45) > identifying Logon(35=A) >
message’s MsgSeqNum(34) > with Text(58)
referencing > error condition.
3. Send Logout(35=5) message > with Text(58)
referencing > error condition.
4. Disconnect.
4.4.2 Scenario 2S. Receive any message other than a Logon message
Mandatory
Condition/stimulus Expected behaviour
First message received is not a Logon(35=A) message. 1. Log an error “First message not a logon”.
2. Disconnect.
4.5 Test cases applicable to all FIX systems
4.5.1 Scenario 2 Receive Message Standard Header
Mandatory
Condition/stimulus Expected behaviour
a. MsgSeqNum(34) received as expected. Accept MsgSeqNum(34) for the message.
b. MsgSeqNum(34) higher than expected. Respond with ResendRequest(35=2) message.
c. MsgSeqNum(34) lower than expected without 1. Whenever possible it is recommended that FIX engine
PossDupFlag(43) set to Y. attempt to send a Logout(35=5) message with a text
message of “MsgSeqNum too low, expecting X but
Exception: SequenceReset(35=4).
received Y”.
2. (Optional) Wait for Logout(35=5) message response
(Note: likely will have inaccurate MsgSeqNum(34)) or
wait 2 seconds, whichever comes first.
3. Disconnect.
4. Generate an error condition in test output.
d. Garbled message received. 1. Consider garbled and ignore message (do not increment
NextNumIn) and continue accepting messages.
2. Generate a warning condition in test output.
e. PossDupFlag(43) set to Y; OrigSending- 1. Check to see if MsgSeqNum(34) has already been
Time(122) specified is less than or equal to received.
SendingTime(52) and MsgSeqNum(34) lower
2. If already received then ignore the message, otherwise
than expected.
accept and process the message.
Note: OrigSendingTime(122) should be earli-
er than SendingTime(52) unless the message
is being resent within the same second during
which it was sent.
3
© ISO 2022 – All rights reserved

---------------------- Page: 8 ----------------------
ISO 3531-3:2022(E)
Condition/stimulus Expected behaviour
f. PossDupFlag(43) set to Y; OrigSending- 1. Send Reject(35=3) message with
Time(122) specified is greater than Sending- SessionRejectReason(373) set to 10 (SendingTime
Time(52) and MsgSeqNum(34) as expected. accuracy problem).
Note: OrigSendingTime(122) should be earli-
2. Increment NextNumIn.
er than SendingTime(52) unless the message
is being resent within the same second during
3. Optional:
which it was sent.
• Send Logout(35=5) message referencing
inaccurate SendingTime(52) value.
• (Optional) Wait for Logout(35=5) message
response (Note: likely will have inaccurate
SendingTime(52)) or wait 2 seconds, whichever
comes first.
• Disconnect.


Generate an error condition in test output.
g. PossDupFlag(43) set to Y and OrigSending- 1. Send Reject(35=3) message with
Time(122) not specified. SessionRejectReason(373) set to 1 (Required tag
missing).
Note: Always set OrigSendingTime(122) to the
time when the message was originally sent-not
2. Increment NextNumIn.
the present SendingTime(52) and set PossDup-
Flag(43)=Y when responding to a ResendRe-
quest(35=2).
h. BeginString(8) value received as expected and Accept BeginString(8) for the message.
specified in testing profile and matches Begin-
String(8) on outbound messages.
i. BeginString(8) value received did not match 1. Send Logout(35=5) message referencing incorrect
value expected and specified in testing profile BeginString(8) value.
or does not match BeginString(8) on outbound
2. (Optional) Wait for Logout(35=5) message response
messages.
(Note: likely will have incorrect BeginString(8)) or wait
LogoutAckThreshold seconds, whichever comes first.
3. Disconnect.
4. Generate an error condition in test output.
j. SenderCompID(49) and TargetCompID(56) val- Accept SenderCompID(49) and TargetCompID(56) for the
ues received as expected and specified in testing message.
profile.
k. SenderCompID(49) and TargetCompID(56) val- 1. Send Reject(35=3) message with RefTagID(371)
ues received did not match values expected and to identify field with mismatched value, and
specified in testing profile. SessionRejectReason(373) set to 9 (CompID problem).
2. Increment NextNumIn.
3. Send Logout(35=5) message referencing incorrect
SenderCompID(49) or TargetCompID(56) value.
4. (Optional) Wait for Logout(35=5) message response
(Note: likely will have incorrect SenderCompID(49)
or TargetCompID(56)) or wait 2 seconds, whichever
comes first.
5. Disconnect.
6. Generate an error condition in test output.
4
  © ISO 2022 – All rights reserved

---------------------- Page: 9 ----------------------
ISO 3531-3:2022(E)
Condition/stimulus Expected behaviour
l. BodyLength(9) value received is correct. Accept BodyLength(9) for the message.
m. BodyLength(9) value received is not correct. 1. Consider garbled and ignore message (do not increment
NextNumIn) and continue accepting messages.
2. Generate a warning condition in test output.
n. SendingTime(52) value received is specified in Accept SendingTime(52) for the message.
UTC (Universal Time Coordinated) also known
as GMT) or is not within SendingTimeThreshold
seconds of a synchronized time source.
o. SendingTime(52) value received is either not 1. Send Reject(35=3) message with
specified in UTC (Universal Time Coordinated) or SessionRejectReason(373) set to 10 (SendingTime
is not GMT) or is not within a within SendingTime- accuracy problem).
Threshold seconds of a synchronized time source.
2. Increment NextNumIn.
Rationale:
3. Send Logout(35=5) message referencing inaccurate
Verify system clocks on both sides are in sync and
SendingTime(52) value.
that SendingTime(52) is current time.
4. (Optional) Wait for Logout(35=5) message response
(Note: likely will have inaccurate SendingTime(
...