This question suggests some misconceptions about how FIX works in practice. Here is my best attempt to clear that up.
When a venue offers a FIX interface, they get to set the rules. If you have a client app and you want to connect it to a server at some venue, you need to tailor your app for that venue's message definitions and configurations. Any other venue's definitions or configs are irrelevant.
If you want to connect a client to two different venues, you cannot assume any commonality in their interfaces. Even if they are both the same FIX version (e.g. both FIX 4.4), there will be differences. You'll have to pore over each venue's documentation and implement your client's different connection logics accordingly.
So, in your example, a user of Venue 2 must send a SecurityStatusRequest message if they want to get a status, and there's no way around it. You need to decide how to implement it. Venue 2 sets their rules, and they don't care how Venue 1 does things.
Possible implementation: Once you've received the list of securities, if you're on Venue 2, loop through it and send an SSR for each one. If your two venue handlers share logic, then you'd put it in a if(current_venue==venue2)
-type block.