If this is the model, my concern is that in practice it will often be the case that there will be few intermediate exchanges. Particularly in the early stages of the system, there won't be that much to buy. Someone may accept epoints for payment but the first thing he will do is convert them to "real money". A typical transaction will start with someone buying epoints from the issuer using some identified payment system, spending them online, and then the recipient redeems them using an identified payment system. The issuer sees exactly who spent, how much they spent and where they spent it. The result is that in practice the system has no anonymity whatsoever. It is just another way of transferring value online.
That's a "merchant" business model. Typically, that's not how payment systems emerge. Mostly, they emerge by a p2p model, and then migrate to a merchant model over time. How they start is generally a varied question, and somewhat a part of the inspiration of the Issuer. According to the Issuer's design, he may try and force that migration faster or slower. In a more forced system, there is typically only one or a few exchange points and that is probably the Issuer himself. If the Issuer also pushes a merchant design, and a triangular flow evolves, the tracing of transactions is relatively easy regardless of the system because time and amount give it away. But, typically, if the Issuer has designs on merchant business, he generally doesn't care about the hyphed non-tracking capabilities of the software, and also prefer the tracking to be easy for support and segmentation purposes. A game that Issuers often play is to pretend or market a system as privacy protecting, but if their intention is the merchant model then that game stops when the numbers get serious. (I gather they discuss that in the Paypal book if you want a written example.) Either way, it is kind of tough to criticise a software system for that. It's the Issuer and the market that sets the tune there; not the software system. The ideal software system allows the Issuer to decide these paramaters, but it is also kind of tough to provide all such paramaters in a big dial, and keep the system small and tight. (I suppose on this note, this is a big difference between Daniel's system and mine. His is small and tight and he talks about being able to audit the 5 page long central server ... mine is relatively large and complex, but it can do bearer and it can do fully traceable, as well as be passably extended to imitate of his design.) Meanwhile, the Issuers who want to provide privacy with a bog standard double entry online accounts system still have a better record of doing that than any other Issuers that might have boasted mathematical blah blah, they just run theirs privately. e.g., your average Swiss bank. iang