Yeah, all those table scans are not doing you any favors whatsoever.

The query plan is timing out too, which means it's unstable. Run it on another day when there's a little more memory or CPU cycles available and you may see a different plan.

You're returning an estimated 600 rows, but some of the table scans are for 45000.

Personally, this query is too complex. I would tear it down into it's most basic parts and rebuild it slowly. There's way too much formatting logic in the SELECT criteria. That's the kind of thing best done on the front end. You have calculations running on columns, ((I1.MS_UniquePenID + 1), in your JOIN criteria. Even if you have good indexes, and indexing 9 columns (if I counted correctly on the dbo.Tab_Immediate_Pension_Data table) for some of the JOIN criteria is going to be a bit problematic, that's going to lead to scans all by itself. Personally, this is a place where an artificial key is likely to be preferable to natural keys, just to get the performance needed. Also, the sub-select is using MIN without any other grouping or ordering. A TOP 1 with an ORDER BY desc might work better there, assuming you can get an 8 column index to work.

To tune the query, ditch the SELECT criteria for now. Concentrate on the JOIN and WHERE clauses to ensure you can eliminate all those table scans. You'll have to put indexes in place. Once all that is done, slowly rebuild the SELECT criteria to ensure you're still able to retrieve the data you need.