Can I get details related FTP client Data Connection Failures with an AS400 FTP server?

This usually occurs when high level (ephemeral) ports are closed by a firewall.

Sounds like the FTP server job is outside the AS400 LAN? Unless you have full control over the data ports (like Filezilla Server can), you can't forward the correct ports to the FTP server as well (there are actually people who will open up EVERYTHING just to get FTP working).
In this case, to be on the safe side, have the FTP server job work INSIDE the LAN, and then transfer it out of the LAN through some other way (FTP push, HTTP pull, whatever you wish).
If you want the second step to still be FTP, use Filezilla Server, assign 10 dynamic ports, and have those NATted (along side the usual FTP port obviously) and firewall whitelisted.

425 is usually caused by a firewall or port restriction somewhere between your FTP client and the FTP server.  FTP is a complicated protocol, and requires specific application-layer support in a firewall.  This is probably why you aren't seeing the connection attempt in your FTP logs.

425 could also possibly occur if the IBM i FTP service isn't started, but I'm sure you've probably checked that.

Can you access the FTP server locally from another system on the same network?  Is there a firewall or proxy server between your IBM Integration Bus server and the IBM i FTP server?  If so, you'll need to contact the network administrator and see about getting FTP opened inbound to the IBM i.

Expanding my comment above, the fix, as Gary suggested, open all access through high numbered ephemeral ports in your firewall.

I have to respectfully disagree, at least in principle, with David:  

This is a legacy strategy that is only appropriate for older, limited capability firewalls that don't offer stateful inspection. Opening large static ranges of ports generally isn't appropriate, secure, or even necessary with modern enterprise-grade firewalls. Enterprise grade firewalls are generally capable of stateful inspection, which means (in hte case of FTP) that the firewall can make dynamic decisions on what ports to temporarily open based on port selection negotiated by the FTP protocol for a given connection.  This mechanism is equally appropriate for external connections, and also for most inbound connections from a DMZ network to a private network.

Specific solution may vary depending on your firewall, network architecture, security rules, etc.  But your firewall administrator should be able to understand and implement a request to "open up FTP between the IBM Integration Bus server (FTP client) to the IBM i (FTP server)".

Just a side note:  sFTP (ssh File Transfer Protocol) is a superior file transfer protocol in terms of firewall and proxy server simplicity and overall security.  sFTP is supported on IBM i.  If I was setting up a new connection between two servers who both can handle handle sFTP, I'd use it.

If it turns out that there is no firewall, or no firewall rule prohibiting inbound FTP, you should also be aware that IBM i FTP connectivity could also be limited by IP port restrictions configured on the the IBM i, or by FTP Exit Point programs.

The AS400 and IIB servers are on the same subnet/vlan with no Fireall between them, and we had dozens of other successfully FTP session between the same two servers within the same 10 minute period. So I am afraid the only evidence of this error in the future may need to be captured in a connection trace. The trace was not running will this failure occurred, but is running in WRAP on FULL mode now.

Thanks for all your input,

We had another failure today, but I miss keyed the TRCCNN command by not entering a "\" before my directory (see below), any hope of finding the .pcap file in the IFS?
TRCCNN SET(*OFF) TRCTBL(IIB_FTP_SSH) OUTPUT(*STMF) TOSTMF('IIB_FTP_SSH\06_Apr_2021_15_42_01.pcap')  

Trace data is my default IFS directory using name I specified