How to avoid index scans
As Aaron points out, you have three Index Seek operations that generate at least 26Mb of IO each, and one of them generates over 45Mb of IO. That's a pretty large amount. Two of those appear to have residual IO warnings as well. (There are other residual IO warnings on other smaller index operations as well). Read Rob Farley's article on the topic HERE to see why these residual predicates are such a big deal. TL;DR – After SQL Server returns the result set of the join, it still has to scan every row remaining (i.e. the residual) in that result set to find the precise rows needed. That's why those index seeks seem like a good thing, but are not because they are in fact doing tons of IO work.
Hope this helps,
here is one more thing to consider – the more tables and conditions involved into one single query the less chances you have that optimiser finds a perfect plan for you.
Try to split your query to a few small ones saving data in temp tables then join them (and index them if needed) – this may help too.
The high compilation time is not terribly unusual for a query with a moderate number of joins over partitioned tables with many predicates. To give an example, the IN predicates result in 30 separate partitioned seeking operations on the Status table, with a residual predicate for a NOT IN as well. There are heaps of possibilities for index matching and such, so optimization has lots to think about, and eventually times out.
Given the small size of the tables, I would be reviewing the need for partitioning – unless there is a compelling maintenance reason, or maybe if the database is a much smaller sample of the real data set. Without partitioning, compilation time would almost certainly be very significantly reduced.
The NOT IN clauses all result in residual predicates being applied, whether the plan icon happens to be a scan or a seek. Residuals are a scan-type operation as others have mentioned already, so there's not much value in trying to get a different display icon if the underlying operation remains unchanged.
If you want to explore removing these residuals, a filtered index might be the way to go. For example, Column NOT IN (a, b, c) needs a filtered index WHERE Column <> a AND Column <> b AND Column <> c.
The initial seek on SSI is a bit of a worry. Despite the parallelism icon, the round robin exchange with a single row input above it means all 3,267,898 rows are read on the same thread. The operation is therefore serial, whatever the icon says. You might avoid this by executing the subquery SELECT SettlementDate FROM dbo.Ssi WITH (NOLOCK) WHERE DealId = @PendingMoreThanOneWeek) separately and storing the result in a local variable.
Finally, if you really need read uncommitted isolation semantics, consider setting it explicitly rather than hinting every table. It's not affecting performance as far as I can tell, but it detracts from what is otherwise a pretty nice query and execution plan, with a decent schema design behind it (partitioning notwithstanding).
You might also consider columnstore.