Можно попробовать такой вариант (правда я не уверен, что он будет работать в разных версиях SQL - у меня 7.0):
В триггере, где надо откатить напишите
ROLLBACK TRANSACTION T_INSERT_MyTable -- Или другое название, как захотите

А перед вставкой записей добавьте
SAVE TRANSACTION T_INSERT_MyTable -- название сохраняемой точки отката, как в триггере

Всё.

Глеб Уфимцев, зачем так строго
Транзакция "единой-неделимой по-определению" является только для внешнего мира, да и то только в отношении завершения-отката. А внутри же самой транзакции она очень даже делимая, для того и существуют "Transaction Savepoints". Поэтому внутри транзакции можно делать частичные откаты при том, что вся транзакция завершена. Т.е.: делаем шаги 1, 2, 3, отменяем до начала шага 2, делаем шаг 4.
BEGIN TRANSACTION T
--делаем шаг 1
SAVE TRANSACTION T1
--делаем шаг 2
...
--делаем шаг 3
ROLLBACK TRANSACTION T1
--делаем шаг 4
COMMIT TRANSACTION T

Результат: шаг 1, шаг 4.
Это нормальная ситуация.
А вопрос в том, может ли откат к T1 быть произведён из триггера. По моему мнению - да. Формально этому препятствий нет.

Так и я, чтобы помочь, и тоже не из злобы .
Поскольку никто, кроме самого автора вопроса, не знает всех обстоятельств проблемы, а они, обстоятельства, могут быть достаточно сложны, чтобы их расписывать в вопросе, то можно или их домысливать, или принимать вопрос как он есть.
Я, ставя себя на место вопрошающего, предпочёл бы услышать хотя бы один (а лучше несколько) из вариантов решения моей проблемы. Или убедиться, что проблема, как она есть, нерешаема. А если же на мой вопрос будет много ответов, но исходящих из собственных домыслов отвечающих, меня бы это не обрадовало. Это всё равно что на вопрос "сколько времени", мне все рядом стоящие начнут рассказывать, какие существуют способы решить мою проблему раз и навсегда. Так я и сам знаю, что лучший способ - иметь при себе часы .

Вынужден повториться.
При выполнении ROLLBACK TRANSACTION ABCD, ВСЯ внешняя транзакция откатится ТОЛЬКО если не было
SAVE TRANSACTION ABCD.
Иначе откат произойдёт то точки ABCD, но внешняя транзакция НЕ откатится и выполнение BATCH-а будет продолжено.

Instead-триггер - вещь безусловно полезная, но это не панацея от всех проблем.
Например: производятся изменения в таблице Т1. При этом, для реализации логики, триггер на Т1 производит изменение в Т2. Но у Т2 тоже есть триггер, производящий изменения, возможно довольно сложные. Но данные в Т2 связаны с Т1, их нельзя изменить, не изменив предварительно Т1. А в триггере Т1 проверяется результат изменений в Т2, и в случае невыполнения каких либо условий - откат.
Так вот, для реализации подобной логики в Instead-триггере придётся в него поместить не изменение Т2 с последующей проверкой, а сымитировать весь процесс изменений Т1 и Т2, включая логику триггера Т2, проанализировать результаты и принимать решение. В результате, для подобных случаев, применение Instead-триггера может потребовать значительных усилий по переделке и усложнению логики, и станет нецелесообразным.
Когда-же ситуация проще и корректность изменений легко определяется до их внесения, лучше, разумеется, применить Instead-триггер.
Какова ситуация у Дмитрия Русановского неизвестно, поэтому только он (Дмитрий Русановский) может решить, какой вариант для него лучше.