The presence of a type attribute is a bit of a concern for me. The fact that there can be different types of Instruments implies that there should be an abstract Instrument interface, with common methods declared, and multiple concrete implementations (stock, bond, etc.). The forex/rate type may fall into this category, or it may not. I don't know enough about financial instruments to make a good choice here. Perhaps the question was really seeking to prompt you to ask more about the domain?
In general, giving objects type attributes is something I try to avoid. If you put them in, then you presumably will have code outside the class that behaves differently depending on the type of the object being used. This violates the idea that in OOD you let the object do the work (passing in any extra information needed), not the code that uses the object. In other words, type attributes defeat the purpose of polymorphism. In any event, the compiler usually provides type information automatically for all objects. Can you use that?
Sometimes type attributes make sense, for example if you want to gather some statistics on a collection of polymorphic objects (20% stocks, 35% bonds, 40% forex, 10% rate, etc.).
Not knowing much about what a "notional" is, I think your solution to have a class with a double and optional array is a reasonable choice. I see no reason why the degenerate case of a notional with an empty array is any less valid than one with a nonempty array.
If you absolutely have to have a type attribute for forex and rate, I would go with an enum. First, just because it can only be one of two things now does not mean that more things won't be needed later (what about options, derivatives, credit default swaps, etc.?). Second, if you go with a boolean, where true means forex and false means rate, then you are implicitly saying that an Instrument which is "not forex" is a rate Instrument. This is not quite the same thing as explicitly saying an Instrument is a rate Instrument. By conflating "not forex" and rate, you prevent the concepts from being separate in the future.
The conclusion I am coming to is that the overarching Instrument class should be a weak one. There is so much variation in the specializations of it that it makes little sense to push much functionality and attributes into the superclass. It's kind of like putting cars, planes, boats, and trains into a Vehicle class. There's not much you can put there beyond carrying capacity and weight, and the fact that instances of each are all Vehicles. Better to let the individual Instrument types stand on their own, loosely collected under the Instrument class.
