ISO 4217 works well for display purposes but doesn't work for all financial applications. Consider, for example, scenarios involving tax or a product billed based on usage. By rounding off at each processing step, the company could be losing substantial amounts of money. The last two companies I've worked have used varying types of mechanisms for tracking fractions of pennies. In some circumstances, it makes sense to store everything as integers with a separate column to represent precision, but I would probably not do this unless you have a specific use. It's a lot of noise and mucks up the source code worse than, say, a BigDecimal or Decimal type. At the current job, we store everything with 6 digits of precision because of the nature of our billing and use Decimal as a reserved type for only money.
To be honest, if you have an accounting department you probably want to involve them in these discussions because rounding decisions can have impact on your financial statements and, potentially, any audits that may occur in the future. I've worked on two financially focused applications so far and I would strongly suggest that you build out a very defined and clear way to manipulate money for rounding purposes. Building out those processes in a standardized and well-defined way makes for easy unit tests and also helps those who come in the future understand the decisions made.
[1]: http://www.mint.ca/store/mint/about-the-mint/rounding-690000...