Is it possible to require authentication without a federation server?

Question

According to Compliance protocol is it possibile to handle a completely regulated "AntiMoney-laundring" flow.

The Compliance Protocol is an additional step after federation. In this step the sending FI contacts the receiving FI to get permission to send the transaction. To do this the receiving FI creates an AUTH_SERVER and adds its location to the stellar.toml of the FI.

This means that if I want to send lumens (or any other asset) to a federated address, I should (and not "must") contact the authentication server to start the regulated flow.

Furthermore a federation server is strictly required.

Said this, I've some doubts

1. How an anchor should behave for accounts receiving lumens without a regulated flow (lumens sent directly to a public address)?
2. There is a way (maybe an account flag handled by the stellar-core itself) for block transactions not authenticated by an authentication server?
3. Are the authentication request/response stored somewhere into the ledger? (Useful for regulatory audit)

Thanks in advance

EDITED

About point 1: what if federation server is exposing the customer public address directly? So not using a unique receiving address with memos for customer.

Answer 1

Stellar provides standard way of handling compliance, but it's not part of the core protocol, because it is not required for all transactions on the network.

Works as a second layer basically, using core protocol primitives. And now to your questions:

1. It can simply refund all unknown / unauthorized payments.
2. Not for XLM. For assets anchor can control who can hold / transact with their asset by setting auth_required flag
3. Not by default, we don't want to bloat ledger with logs. However if you need that you could store it somewhere in IPFS (or other) and save hashes to Stellar (data or memo fields) for timestamping and proof-of-immutability purposes

You can get around federation server by building some non-standard layer2 logic to authorise users, but why would you do that?