If you turn on 'idempotency' for the historized attributes, the triggers will silently ignore any attempt to update a value to the same value again. And 200 attributes should be no problem at all for the triggers. They are only limited by the maximum code size in SQL Server, which is at several megabytes of SQL code.
Exactly which limit did you hit? I can investigate and see if there are other workarounds or if it can be avoided completely.
As for financial trading systems, there are none that I am aware of. I have implemented a lifetime value system in the financial industry based on AM, and I do now a fair bit about trading, having daytraded myself. If you let me know what you need help with I may be able to answer some of it or find someone else who knows. You can mail me if you'd rather take such a discussion there instead: firstname.lastname@example.org.
The problem is caused by SQL Server running out of RAM, so if you have very little RAM memory in your server it can't execute long SQL statements. Other reports say that turning off the "Resource Governor" in the database made the problem go away. This governor can limit the amount of memory available for execution even if you have lots of RAM. You can read more about the governor here:
Also, if you are on a 32-bit platform, some people also had to double the MemToLeave parameter. It is a startup parameter specified with -g512 (double the normal 256MB). The size of executable SQL statements has to fit in this memory on 32-bit platforms. How to set startup parameters can be found here:
If you have a lower compatibility mode set on your database than the default, this may also cause the problem, as that database sort of becomes "sandboxed" and gets resource limits different from what is stated for the version you are running.