My thoughts while doing that bit were twofold:
 * "it's going to be hard to express anything other than 'min/max/exactly x decimal places' unambiguously"
 * adding explicit guards against decimal places that aren't relevant to the currency seems like a good way to minimise room for rounding errors/using more dp than the currency's smallest subunit supports

If rules about particular currencies are too specific, perhaps we could try the slightly more ambiguous:

> This hashed representation **must** have exactly the number of decimal places required to represent its [smallest subunit](https://en.wikipedia.org/wiki/Denomination_%28currency%29#Subunit_and_super_unit).

Or, if you're happy that it doesn't leave room for mistakes, to reword your rule above:

> This hashed representation **must** be in the shortest possible form allowed by the regular expression without sacrificing any trailing non-zero digits, and must never use more decimal places than required to represent the currency's [smallest subunit](https://en.wikipedia.org/wiki/Denomination_%28currency%29#Subunit_and_super_unit).  Examples:
> * given 0, use `0`, not `0.0` or `0.000`
> * given 1.23 use `1.23`, not `1.230` or `1.23000000`

000 and 0001 wouldn't be allowed by the regex anyway.

I can foresee a possible problem with either of the above though: I'm pretty sure I've seen exchanges (BTC-e?) extend customer balances to e.g. 10dp (not just for Bitcoin either --- for fiat with 2dp subunits too) even though there's no way to ever pay the customer the excess fractions.  We'd have to decide whether to just allow that (and make no attempt to constrain to subunits) or give a rule for rounding (e.g. always [round up](http://docs.oracle.com/javase/6/docs/api/java/math/RoundingMode.html#UP) to the nearest real subunit).