Certification Checklist
Before you move to production, you and OpenYield meet to run a set of test scenarios against your FIX connections in the Test environment. Scenarios start simple and build up. Once every supported scenario passes, your connections are certified and OpenYield starts production onboarding.
We recommend running every scenario that applies to you on your own in the Test environment before the call.
Scenario Groups
Only the scenarios for the flows and sessions you support are run.
| Group | Scenarios | Run if you… |
|---|---|---|
| Trade Maker Direct | 11 | Place limit orders or quotes |
| Trade Maker Cross | 3 | Place limit orders or quotes |
| Trade Maker Other | 8 | Place limit orders or quotes |
| Trade Taker | 4 | Place market orders |
| Ping for Liquidity Responder | 6 | Respond to indicative RFO requests |
| Ping for Liquidity Issuer | 3 | Send indicative RFO requests |
| Request for Quote Responder | 6 | Respond to tradable RFQ requests |
| Request for Quote Issuer | 5 | Send tradable RFQ requests |
| Market Data | 5 | Connect the MD session |
| Other Scenarios | 7 | All subscribers (Security List is optional) |
Before the Call
- Your FIX sessions are connected to the Test environment and log on cleanly
- You can watch your FIX logs in real time
- You have a login to the OpenYield Test user interface
- You know which scenario groups apply to you
System Preparation
- OpenYield turns off the Test environment simulators so results and message flows are easy to observe.
- OpenYield logs in as a test user to act as your contra party.
- Together, we pick one supported bond and run all scenarios on it, unless a scenario says otherwise.
- Quantities are reasonable and prices are within compliance limits, unless a scenario says otherwise.
- After each scenario, both parties confirm the expected state in the user interface. OpenYield also checks its Operations UI. Both parties watch FIX logs in real time for errors.
Reading a Scenario
Each scenario has a Goal, a list of Steps and a list of Observations that show it passed.
Steps are performed by You unless marked OpenYield.
Each observation says where to look:
| Tag | Where to look |
|---|---|
| UI | The OpenYield user interface |
| Operations | OpenYield's internal Operations UI (checked by OpenYield) |
| FIX-TR | Your Trading session FIX log |
| FIX-MD | Your Market Data session FIX log |
| FIX-OB | Your Order Book session FIX log |
| FIX-DC | Your Drop Copy session FIX log |
| FIX-RQ | Your Request Quote session FIX log |
Checks for a session you do not connect are skipped. Observations already checked in an earlier scenario are not repeated in later ones, unless they are part of the story.
Single Message Check
On a random FIX message, OpenYield checks that:
- The FIX version is 4.4
- Security ID is an ISIN, IDSource is correct, and both fields 48 and 55 are set
- Quantity is in bonds, not notional
- The Parties block is correct. If you have multiple clearing firms, the clearing MPID is set.
- If you need sub-accounts, the Account party code is set
- Timestamps are in UTC
- Where needed, sequence numbers reset on reconnection
Special Care
OpenYield pays special attention to the places where FIX engines (based on QuickFIX defaults) commonly differ:
5 = Replacedis accepted on order updates- IOI messages carry a real quantity
- On reconnect, where sequences are not reset, missed messages are resent and not rejected
See QuickFIX Changes for the data dictionary fixes.
Certification
During the call, OpenYield documents the process and logs any issues.
- Certified: all required scenarios pass with no outstanding issues. The tested connections are certified and move to production.
- Fast follow: if some required scenarios fail or issues remain open, we schedule a short follow-up call to test just those scenarios. The same applies when you add a new connection later, for example a Drop Copy.
Not Tested
These are out of scope for certification:
- There is no snapshot on the OB (Order Book) depth of book feed on reconnect. Reset your internal caches when you reconnect.
- Compliance failures. The bad quantity test is the same, and also covers exposure limits.
- Canceling a market order (too fast to test)
- In-flight executions in parallel with Cancel All or disconnect
- Bad orders, such as side or security changes
- FIX sequences for each connection
- Volume and load
- Heartbeat timing