If the loaded SWF is outside the application directory, then it will be loaded into a different security sandbox and will not have access to the file system APIs -- hence the security error. (It works when both SWFs are in the same directory because both SWFs are then in the application security sandbox.) Note that loading a SWF in an application subdirectory should work without a security error.
The most secure way to solve the problem is to use the parentSandboxBridge property of the LoaderInfo object associated with the loaded SWF. You can make a function for creating and writing data to the new file available to the loaded SWF. This technique allows you to control exactly what functions the loaded SWF has access to.
You can also "import" a non-application SWF into the application security domain by loading it with the Loader.loadBytes() method while setting the allowCodeImport property of the passed in LoaderContext object to true. Be sure to consider the security implications of doing so, however, since this SWF is essentially running with the same privileges and permissions as your main application -- and can access any information stored by the app in memory or on "disk". Since you are most often loading a SWF in this way that is either remote or in a filesystem location that can be accessed by other apps, the possibility that the SWF has been modified by a malicious entity is a real threat that you should take very seriously.