Storing parent reference vs ID in business objects

Our development team is discussing the pros and cons of storing hierarchical information in business classes. Let's use a banking system as an example.

Is there any cons to storing a reference to the parent object in child objects (for example, storing a reference to the account in each transaction) Now, we don't want to make it mandatory. For example, when getting a specific transaction based on some ID value, the Account property that references to the account this transaction is in will be set to null. If we want to get that account, we can call some business method on the Transaction object. Alternatively, if I want to get a specific transaction that I know belongs to an account that I already have in memory, we'll have some business method to reflect that. For example:

public Transaction GetTransaction(int transactionId) // Account parent property set to null
public Transaction GetTransaction(int transactionId, Account parentAccount) // Account parent property set to passed in value
public Transaction GetTransaction(int transactionId, List<Account> accounts) // Looks in the list for the account that the transaction belongs to and sets it to that.

I'm looking for input as to how this problem is solved in larger applications. In the environment I'm developing for, database performance is not a high priority because the server is so fast and local.

Thanks