It's an estimated plan - the actual plan for one of the queries would be much more informative. However, the following points spring to mind.
Statistics appear to be out of date. Update statistics on the tables involved before running the stored procedure.
The existing indexes on both source and target are not helping. I'd recommend clustering each of the source tables using the columns used for joins to the merge target. The result is a fully-covering index - except it's the table.
If the target clustered index isn't suitable to assist in the joins, then create a non-clustered index which is a better fit than TSV_IX_1. This index is very expensive to maintain and is used in only one of the four merge statements.
When changing this amount of data, you may wish to rebuild rather than reorganize the indexes after the merge operation.
For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden