Let me feed back what I see, not from your words, but from your structure. That may give you insight as to what you built. Then you can decide if that was what you wanted to build.
You appear to have four sources of income: Rentals, Interest, Equities, and Dividends. You have a "native" ID for each transaction source (I.e. RentalID, EquityID, InterestID, DividendID). You roll these up into a single table, Transactions, where there is another ID local to that table and a foreign key for which you have potentially four contributors (your four income type tables). The rest of your tables provide details subsidiary to each type of income source.
Now, a couple of comments:
1. On the right side of your diagram you have a path leading from Transactions to Equities to Equity Name. You also have a path leading from Transactions to Dividends to Equity Name. This is a "split path" situation (i.e. two different routes from point A to point B) that will drive Access bonkers when it tries to build detailed queries. The query wizard should balk at that. You might be able to manually build the right SQL, but that structure is going to eat your socks any time the query wizard comes into play.
EDITED next item after a second look:
2. You have a four-way split on what the foreign key TransactionID references. Even if the arrow points the other way, it is impossible to gather records from four parallel sources that way. It is a normalization violation in that the content of that field doesn't reference a uniquely located child. This is in the same vein as Namliam's comments about "rows vs. columns" but with a different focus.
3. Somehow I'm missing something, but if this is a "normal" Interest table, it ALSO should have a bank account ID. I see no relationship from the bank accounts to the interest table. Is that intentional? Is the interest NOT from a bank account or is what I see just a result of a "work in progress"?
What I might do differently is dump the transaction table completely, in favor of a four-way UNION query that you can construct from the four basoc sources - except that I would also collapse your Dividend and Equity tables to a single table if that is possible and have two types of transactions in it, both stemming from a single source (either a dividend from an equity item, or a sale or purchase of an equity item), which then means three-way UNION query for transactions. You can use UNION queries as recordsources, so reports will work OK. But you are trying to squish disparate items into a single item in way that might "eat your socks" down the road. Dumping the transaction table dumps the split path problem.
There might be more to consider but that right there is enough to get you at least thinking.