After chatting with some data vault peoples, we agreed to include the child dependent key in the link (and therefore in the Link HashKey). Just remember this means the granularity is at a transaction level rather than just the unique relationship between account, product, and order.
I would suggest keeping the transaction ID (child dependent key) in the satellite along with the parent transaction ID. This makes it easier to determine the relationship between a transaction and its parent when querying the raw vault.
Slightly different approach but someone suggested calculating the Link HashKey of the parent transaction and storing it in the link satellite. It wouldn’t be used for loading the satellite but could help jump back to the parent transaction’s record in the transaction link. It’s not an approach I would have thought of, but it shows there are multiple ways to solve this.
There was a hearty discussion about modelling a dependent child here: Modeling a dependent child - Data Vault 2.0 - Data Vault User Group Forum