Maybe the AccountId is really more related to the business logic of your
service than the infrastructure (which username/password supposedly belongs
to)?

If this is the case you may consider putting the accountId in your message
rather than in the headers, which are normally reserved for more
infrastructure related stuff (security, addressing, attachments, ...).  

But if you choose to stick it in the header (and I dont thing the
UsernameToken has room for it), it must be because you want to have the
framework do the authorization before reaching your Web method, and in that
case there is no way around writing your own policy assertion.

Just a few thoughts, but if you need examples of writing your own assertions
they are becoming available in may places.

Niels