Some feel that you should show system actors only when they are the ones who need the use case. So if the system generates a file every night that is subsequently picked up by the Accounting System, then Accounting System is the relevant actor because it is the one that needs the file produced. Some feel that thinking of a system as an actor is the wrong focus. In the case of our example system, the actors would be the internal auditors of the company. All things considered, I lean toward option 3.
Use cases are all about externally-required functionality.
If the Accounting System needs a file, that is a requirement that needs to be satisfied. Accessing Reuters is important but not a user need. If you follow option 4, you end up analyzing the Accounting System, which is something you would probably rather not get into. That said, you should always question use cases with system actors, find out what the real user goals are, and consider alternative ways of meeting those goals. When I'm working with actors and use cases, I don't worry too much about what the exact relationships are among them.