If you go to this transaction page on etherscan, scroll down to the Input Data section and click the Decode Input Data button- it gives you nothing, which I can only assume means that etherscan was unable to decode the input data given the ABI for that contract.
My question is, why? What is special about that contract/ABI (or really any contract like this one) that would prevent the transaction from being decoded?
The called function signagure is 0xfaa916d3, the rest of the data are arguments. The contract ABI doesn't define any function that would translate to the 0xfaa916d3 signature. Which means that the fallback function was called.
In this case, the fallback function acts as a proxy, creates an internal transaction and delegates the call to the target contract (which can theretically do the same or create multiple other internal transactions, etc.)
However, Etherscan currently only compares the signature to the ABI of the root transaction recipient and ignores the internal transactions recipients' ABIs in the "Decode input data" feature.
Why? My guess is that it's easier to scan just one level, and not that high priority to implement and account for all the edge cases such as multiple internal calls with the same signature. But you'd need to ask them for the real reason. :)