I am trying to use this ECDSA implementation in Haskell, if you look at line 15, you will see that the k value uses randomRIO which uses the global random number generator the getter of which uses the theStdGen which uses mkStdRNG which makes the seed by:
(current seconds on the wall clock) * 12345 + (current picoseconds on the wall clock) + (the number of picoseconds of CPU time used by the current program)
Is this good enough for signing data which is worth billions of US dollars?
In general, the answer would be no. If you are considering the use case the only real option is to use a FIPS or Common Criteria certified HSM. The FIPS and CC-evaluation must be of a recent date, and must be valid for ECDSA. Only an expert should be allowed create the key management protocol around it. Another expert should validate this protocol and the usability of the HSM. The choice of named parameters of ECDSA should be part of the protocol and should not be taken lightly.
Now for your Haskell RNG. You should not be using the current implementation as the random number generator certainly is not up to par. It may use insecure seeds (as you may already have found) and seems to keep insufficient state (anything that says, use Integers, why not, in the comments should not be trusted). I don't see any hash or HMAC being used to generate new random numbers or state either, so I don't see how this implementation generates secure random numbers at all.
A quick look on the internet has strengthened my suspicions:
http://tommd.wordpress.com/2010/09/02/a-better-foundation-for-random-values-in-haskell/
Notice the experimental tag at the time of writing:
http://hackage.haskell.org/package/crypto-random-api-0.2.0/docs/Crypto-Random-API.html
Now if you are really developing signing for something worth billions of dollars, please make yourself manager and hire an expert (& listen to the expert).