Can the issuer limit/approve the counter asset that can be traded against

Question

Can the issuer limit/approve the counter asset that can be traded against? To make sure the asset you issue does not become part of a money laundering scheme..

Or does this require a federated approach? From what I understood going 'the federated way' will mean that all transactions have to be created 'within the client environment' of the issuer/anchor. Does that mean there will be no interoperability with wallets & StellarTerm?

In the development guide (https://www.stellar.org/developers/guides/anchor/index.html) it says about federated vs customer managed accounts: "You can also create your own variations on the two approaches."

Is it possible to design a solution where asset holders manage their own account; simple transfers they can sign themselves, trade offers require a validation by an 'compliance server'.

Answer 1

I'll attempt to answer your many questions one-by-one.

Can the issuer limit/approve the counter asset that can be traded against? To make sure the asset you issue does not become part of a money laundering scheme..

Or does this require a federated approach?

Federation is a separate concept from asset issuance -- not all anchors run federation servers. An anchor is defined as anyone who issues an asset on the Stellar network. To hold this asset, the receiver must have a trustline open with the issuing account.

The issuer of an asset can revoke an account's access to an asset at any time. When this happens, the asset is frozen and the user of the revoked asset can no longer receive or send that asset.

So in theory, if you saw someone creating an offer for something you don't approve of, then you may be able to revoke that account's access to that asset. But, I have never tried this and cannot comment on whether or not this will work as intended.

From what I understood going 'the federated way' will mean that all transactions have to be created 'within the client environment' of the issuer/anchor. Does that mean there will be no interoperability with wallets & StellarTerm?

Federation works in two ways:

1. Mapping Approach: here, essentially the federation server maps a federation username such as jed*stellar.org to a account id such as GD6WU64OEP5C4LRBH6NK3MHYIA2ADN6K6II6EXPNVUR3ERBXT4AN4ACD.Thus, the company that offers federation services will need to operate a database to keep track of this mapping.
2. Single Account Approach: here the federation server only has a single account and uses the memo field to dictate which internal account should receive/send funds.

If the federation server is using the Mapping Approach and the user has access to their keypair, then they can use any wallet and StellarTerm. If the federation server uses the Single Account Approach, the user won't technically have an account and thus won't be able to use wallets or StellarTerm.

Is it possible to design a solution where asset holders manage their own account; simple transfers they can sign themselves, trade offers require a validation by an 'compliance server'.

This may be possible via a full stack of a Bridge Server, a Federation Server, and a Compliance Server. As it says in on the Compliance Server page Your bridge server contacts your compliance server in order to authorize a transaction before sending it. This makes me believe the scenario you have described may be feasible. Nevertheless, take this with a grain of salt.

These are simply my conclusions after doing my own research -- I have not actually tried to implement any of this.